PfSense как прокси (squid) - проблемы с стабильностью ICQ



  • Добрый день всем.
    Собственно имеем небольшую схему - модем к провайдеру, от него прямой кабель в машину с pfSense, она настроена как прокси-сервер с запретом маршрутизации. Все в целом работает, но ICQ клиенты (конкретно qip) у всех пользователей (около 10 человек) периодически сбоят. Причем сбой внешне не виден - статус горит онлайн, сообщения якобы отправляются, но они не доходят и ничего в таком состоянии клиент не принимает. Минут через 5-10 вылетает в оффлайн и снова подключается и все ОК на какое-то время. Сколько не меняю настроек, победить не получается. Сначала подозревал кэш прокси, уменьшил как мог - не помогает. Поставил Stiky connection, все равно падает. Но чуть реже. Есть какие-то рекомендации, что и как настроить? ICQ клиент работает тоже через squid по HTTP.



  • @Stirlitz:

    Добрый день всем.
    Собственно имеем небольшую схему - модем к провайдеру, от него прямой кабель в машину с pfSense, она настроена как прокси-сервер с запретом маршрутизации. Все в целом работает, но ICQ клиенты (конкретно qip) у всех пользователей (около 10 человек) периодически сбоят. Причем сбой внешне не виден - статус горит онлайн, сообщения якобы отправляются, но они не доходят и ничего в таком состоянии клиент не принимает. Минут через 5-10 вылетает в оффлайн и снова подключается и все ОК на какое-то время. Сколько не меняю настроек, победить не получается. Сначала подозревал кэш прокси, уменьшил как мог - не помогает. Поставил Stiky connection, все равно падает. Но чуть реже. Есть какие-то рекомендации, что и как настроить? ICQ клиент работает тоже через squid по HTTP.

    А натом асю не пробовали делать? на хттп может сбоить, и сбоит..



  • проблемы с стабильностью ICQ = ICQ с стабильностью проблемы.

    Офис из 10 дев .. менеджеров . Работа построена на "Интернете".
      pfSense > 3 лет. SQUID + Lightsquid, QIP (http/s), почта (portmaping, WEB)

    Работа с ICQ через QIP с самого начала.

    Проблемы были с ICQ:

    1. Кол-во единовременных подключений с одного IP.
    2. Провайдер (ну как без "них").
    3. Изменения в сервисах ICQ.

    Но, таких как у Вас проблем вроде неприпоминаю.

    Способы решения:

    1. www.jabber.ru + PSI + Шлюз на AIM и другие.
    2. Где то pkg pfSense был прокси на этот протокол.
    3. И правильное предложение выше.



  • прокси зовется imspector ;)



  • Через NAT нереально по структуре сети, т.к. это не основной гейт. Если только настроить pfSense как адрес для подключения, а он будет пересылать на сервер ICQ. Но что-то я не уверен в такой возможности.

    Я так понимаю, что где-то что-то в настройках прокси. Т.к. через ту же вроде бы версию squid в другом месте без проблем работало. Но не на FreeBSD. Firewall и прокси настроено так, чтобы ничего никуда не ходило между сетками, чтобы только прокси принимал подключения и мог выходить в инет.

    Странный глюк вообще.



  • Действительно - попробуйте Imspector. Броузинг по http не так требователен к стабильности, как другие протоколы. К тому-же на pfSense есть определенные проблемы с быстродействием squid.



  • Попробую. Может собака зарыта в подключении к инету… Оно очень нестабильно и может "зависать" на несколько секунд. Т.к. по воздуху. :) Только ладно бы отключался клиент. А он упорно висит в онлайн и отправляет сообщения в пустоту. :)



  • 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 указать адреса аси
    чтобы он не кэшировал их



  • @storma:

    В зависимости от настойки в System: Advanced functions "запретил вообще все входящие из WAN" не инициализированные от Lan соединения - Правило действует по #Умолчанию#.

    • Не издеваюсь, пытаюсь понять.

    Я там не нашел ничего похожего… Плюс по умолчанию у меня создались три правила для WAN. После скрытия локальных сетей и блокировки bogon сетей было правило разрешить все от всех и для всех. Т.е. все звездочки. Я его просто отключил. Может оно из-за конфига для виртуальных машин появилось - первая прокся работала под VMware, сейчас отдельная машина стоит. Правило именовалось: Default allow all on WAN in VM

    кэширование попробую отключить, только если там https, разве он кэширует соединения? По идее кэш должен быть объектов. Плюс у меня народ ломится на разные серверы авторизаци...



  • С отключенным кэшированием пока глюков с непосылкой сообщений не было… Любопытно это все...



  • @Stirlitz:

    С отключенным кэшированием пока глюков с непосылкой сообщений не было… Любопытно это все...

    Ну со сквидом всегда так - сначала отключаем кэширование а потом все остальное.



  • так там полностью отключить кэш не получается, если через веб настраивать… Размер кэша в памяти все равно хоть какой-то, но должен быть.



  • @Stirlitz:

    так там полностью отключить кэш не получается, если через веб настраивать… Размер кэша в памяти все равно хоть какой-то, но должен быть.

    Отключить кэш в сквиде вообще невозможно на сколько я в курсе. Но есть опция 'не кэшировать' для указанных условий. Если задаться целью, можно прописать чтобы весь трафик пропускало без кэша. (регекс или урл по маске какой сделать)



  • ну да, можно попробовать масками.
    Впрочем полностью проблема не устранилась, т.к. перезагрузка модема не вызывает разрыва соединения. Зато (!) после восстановления связи уходит старое сообщение. Более-менее устаканилось все.


Log in to reply