PfSense как прокси (squid) - проблемы с стабильностью ICQ
-
Попробую. Может собака зарыта в подключении к инету… Оно очень нестабильно и может "зависать" на несколько секунд. Т.к. по воздуху. :) Только ладно бы отключался клиент. А он упорно висит в онлайн и отправляет сообщения в пустоту. :)
-
IMSpector это прозрачный прокси… Как я понимаю он работает, если мы стучимся через прокси по адресу aol.com, когда прокси выступает и как гейт для этого подключения... И порт открывает для этого 16667. А выступать как отдельный прокси, через который можно настроить подключение, нельзя...
-
IMSpector это прозрачный прокси…
Насколько "прозрачный ...." не знаю, честно. Но, зачем то его придумали.
-
написано transparent
Он позволяет фильтровать и вести логи переписки по этим протоколам… Т.е. блокировать по каким-то словам или реагировать как-то еще...Может я еще правила слишком жесткие указал... я запретил вообще все входящие из WAN.
-
… Я запретил вообще все входящие из WAN.
В зависимости от настойки в System: Advanced functions "запретил вообще все входящие из WAN" не инициализированные от Lan соединения - Правило действует по #Умолчанию#.
- Не издеваюсь, пытаюсь понять.
-
А если напрямую пустить 5190 порт из локалки во внешку - тоже сбоит? В конце концов можно коннектить ICQ по 443 порту.
-
Чтобы пустить напрямую, нужно чтобы прокся была роутером в сети. Она не гейт основной. Прописывать маршрут у локальных пользователей для одного адреса не очень хочется.
PS: и так соединяется по 443 порту, qip не хочет через HTTP-прокси работать. Почему-то только HTTPS проходит.
-
В общем видимые результаты причины такого поведения я вижу. Соединение между squid и сервером icq считается нормальным (установленным), даже когда я перезапускаю модем, выходящий в интернет. Даже когда он перезапустился соединения какое-то время висят как установленные. Соответственно попытка QIP что-то узнать/отправить подтверждается squid'ом, а дальше никуда не идет… И странно, что соединение не рвется!
-
Попробуй в кэше/Do not cache указать адреса аси
чтобы он не кэшировал их -
В зависимости от настойки в System: Advanced functions "запретил вообще все входящие из WAN" не инициализированные от Lan соединения - Правило действует по #Умолчанию#.
- Не издеваюсь, пытаюсь понять.
Я там не нашел ничего похожего… Плюс по умолчанию у меня создались три правила для WAN. После скрытия локальных сетей и блокировки bogon сетей было правило разрешить все от всех и для всех. Т.е. все звездочки. Я его просто отключил. Может оно из-за конфига для виртуальных машин появилось - первая прокся работала под VMware, сейчас отдельная машина стоит. Правило именовалось: Default allow all on WAN in VM
кэширование попробую отключить, только если там https, разве он кэширует соединения? По идее кэш должен быть объектов. Плюс у меня народ ломится на разные серверы авторизаци...
-
С отключенным кэшированием пока глюков с непосылкой сообщений не было… Любопытно это все...
-
С отключенным кэшированием пока глюков с непосылкой сообщений не было… Любопытно это все...
Ну со сквидом всегда так - сначала отключаем кэширование а потом все остальное.
-
так там полностью отключить кэш не получается, если через веб настраивать… Размер кэша в памяти все равно хоть какой-то, но должен быть.
-
так там полностью отключить кэш не получается, если через веб настраивать… Размер кэша в памяти все равно хоть какой-то, но должен быть.
Отключить кэш в сквиде вообще невозможно на сколько я в курсе. Но есть опция 'не кэшировать' для указанных условий. Если задаться целью, можно прописать чтобы весь трафик пропускало без кэша. (регекс или урл по маске какой сделать)
-
ну да, можно попробовать масками.
Впрочем полностью проблема не устранилась, т.к. перезагрузка модема не вызывает разрыва соединения. Зато (!) после восстановления связи уходит старое сообщение. Более-менее устаканилось все.