Мобильные клиенты WiFi через прокси Squid



  • Добрый день.
    Возникла очередная загвозка. Задача: необходимо пустить мобильных юзеров по WiFI прозрачно через прокси сервер сквид (версия 2.7), не прописывая параметры прокси сервера в настройки браузера. Причем сквид поднят с авторизацией по kerberos для локальных сетей и вполне достойно работает.
    Теперь распишу, что было сделано.
    На PFS добавлен интерфейс WIFI_WAN (222.222.222.0/24 сеть), на котором крутится WiFi сеть. Прописаны шлюз, маршрут, правила файрвола и nat, шейпер для этого интерфейса. Все работает как надо. Но появилась необходимость наблюдения и учета Web-трафика у мобильных пользователей, соотвественно, нужно пустить определенный трафик через сквид прозрачно без аутентификации. Для этого в Firewall: NAT: Port Forward сделал проброс 80 порта на интерфейсе WIFI_WAN на локальный адрес и порт сквида (172.16.0.132:81), автоматом создалось правило файрвола для интерфейса WIFI_WAN. Включил на этом правиле лог. С мобильного клиента по WIFI захожу, например, на яндекс и вываливается ошибка:


    ОШИБКА
    Запрошенный URL не может быть доставлен.

    Во время обработки запроса:
    GET /?clid=46143 HTTP/1.1
    User-Agent: Opera/9.80 (S60; SymbOS; Opera Mobi/SYB-1204232254; U; ru) Presto/2.10.254 Version/12.00
    Host: www.yandex.ru
    Accept: text/html, application/xml;q=0.9, application/xhtml+xml, multipart/mixed, image/png, image/webp, image/jpeg, image/gif, image/x-xbitmap, /;q=0.1
    Accept-Language: ru-RU,ru;q=0.9,en;q=0.8
    Accept-Encoding: gzip, deflate
    Cookie: yandexuid=1394582561316531546
    Connection: Keep-Alive
    X-EBO-UA: BID=1.3.0, BCReq=69C76015BAD50D3543F943ABAED370FE

    Произошла следующая ошибка:
    Неверный запрос.

    Некоторые аспекты HTTP запроса неправильны. Возможные проблемы:
    Отсутствует либо неизвестен метод запроса (GET, POST)
    Отсутствует URL
    Отсутствует HTTP идентификатор (HTTP/1.0)
    Запрос слишком велик
    Не указан Content-Length для запросов POST или PUT
    Недопустимый символ в имени сервера; подчеркивания недопустимы

    Generated Wed, 30 May 2012 03:11:29 GMT by pfsense (squid/2.7.STABLE9)


    В логах файрвола видно, что проброс сработал и файрвол пустил это соединение.

    Выкладываю конфиг сквида: В фалике unrestricted_hosts.acl прописан адрес WiFi шлюза, через который ходят мобильные юзеры 222.222.222.2.


    http_port 172.16.0.132:81
    icp_port 0

    pid_filename /var/run/squid.pid
    cache_effective_user proxy
    cache_effective_group proxy
    error_directory /usr/local/etc/squid/errors/Russian-1251
    icon_directory /usr/local/etc/squid/icons
    visible_hostname pfsense
    access_log /var/squid/logs/access.log
    cache_log /var/squid/logs/cache.log
    cache_store_log none
    logfile_rotate 30
    shutdown_lifetime 3 seconds

    acl localnet src 172.16.0.0/255.255.255.0
    acl localnet src 172.16.1.0/255.255.255.0
    acl localnet src 192.168.0.0/255.255.255.0
    acl localnet src 192.168.25.0/255.255.255.0
    acl localnet src 222.222.222.0/255.255.255.0

    uri_whitespace strip

    cache_mem 100 MB
    maximum_object_size_in_memory 32 KB
    memory_replacement_policy heap GDSF
    cache_replacement_policy heap LFUDA
    cache_dir ufs /var/squid/cache 500 16 256
    minimum_object_size 0 KB
    maximum_object_size 4 KB
    offline_mode off
    cache_swap_low 90
    cache_swap_high 95

    acl all src 0/0
    acl localhost src 127.0.0.1/255.255.255.255
    acl webserver src 172.16.0.132/255.255.255.255
    acl safeports port 20 21 70 80 210 280 443 488 563 591 631 777 901 3128 1025-65535
    acl sslports port 20 21 443 563
    acl manager proto cache_object
    acl purge method PURGE
    acl connect method CONNECT                                                                                                                    
    acl dynamic urlpath_regex cgi-bin ?
    acl blacklist dstdom_regex -i "/var/squid/acl/blacklist.acl"
    acl whitelist dstdom_regex -i "/var/squid/acl/whitelist.acl"
    cache deny dynamic

    acl allow_hosts src "/var/squid/acl/unrestricted_hosts.acl"
    http_access allow allow_hosts

    acl FTPclient proto FTP
    acl FTP_port port 60000-61000
    http_access allow FTPclient
    http_access allow CONNECT FTP_port

    http_access allow manager webserver
    http_access deny webserver
    http_access deny manager
    http_access allow purge localhost
    http_access deny purge
    http_access deny !safeports
    http_access deny CONNECT !sslports
    http_access allow localhost
    http_access allow whitelist
    tcp_outgoing_address 127.0.0.1
    auth_param negotiate program /usr/local/libexec/squid/squid_kerb_auth -d -s HTTP/pfsense.green.local
    auth_param negotiate children 30
    auth_param negotiate keep_alive on
    acl auth_users proxy_auth REQUIRED  
    external_acl_type domain_users %LOGIN /usr/local/libexec/squid/squid_ldap_group -R -b "dc=green,dc=local" -f "(&(sAMAccountName=%v)(memberOf=CN=%a,CN=Builtin,DC=green,DC=local))" -D el2@green.local -w 16312352 -K go-srv

    acl Avtomat external domain_users Internet-Avtomat
    acl InetUsers external domain_users Internet-Users
    acl OSB external domain_users Internet-OSB
    acl Unlimit external domain_users Internet-Unlimit
    acl Mail external domain_users Internet-Mail

    request_body_max_size 0 KB
    reply_body_max_size 0 deny all

    delay_pools 1
    delay_class 1 2
    delay_parameters 1 250000/250000 100000/100000
    delay_access 1 allow InetUsers
    delay_access 1 allow OSB
    delay_access 1 allow Mail
    delay_access 1 allow Avtomat
    delay_access 1 allow Unlimit

    http_access deny Avtomat blacklist
    http_access allow Avtomat
    http_access deny InetUsers blacklist
    http_access allow InetUsers
    http_access deny OSB blacklist
    http_access allow OSB
    http_access deny Unlimit blacklist
    http_access allow Unlimit
    http_access deny MoneyOrders blacklist
    http_access allow MoneyOrders
    http_access deny Mail blacklist
    http_access allow Mail
    http_access deny !Avtomat
    http_access deny localnet
    http_access deny all


    Подскажите, плиз, как мне пустить прозрачно мобильных юзеров через рабочий прокси сквид?



  • Если доступ беспроводных клиентов к локальной сети (LAN ) не ограничивается, то смею предложить давать подключающимся ви-фи клиентам адреса из локальной сети (по dchp), переведя сам беспроводной интерфейс в режим точки доступа (Access point) , т.е. этакого свитча-без-проводов. И тогда в Сеть "прозрачно" через сквид они точно будут бегать.

    Имхо, это как вариант :)

    P.s. А telnet на 172.16.0.132 и 81 порт с мобильных клиентов идет? А если так попробовать ?




  • У меня так не получится. Дело в том, что вай-фай клиенты сидят за вай-фай роутером в отдельной сети (10.10.10.0/24) и вай-фай роутер по DHCP раздает им ip адреса. А уже от вай-фай роутера от его WAN интерфейса (222.222.222.2) прокинут шнурок к моему PFS, на котором заведен отдельный интерфейс WIFI_WAN (222.222.222.1). Все мобильные клиенты ходят в инет и другие локальные сети через шлюз 222.222.222.2.

    Насчет telnet попробую проверить, только надо найти телнет-клиент на свой смартфон.



  • @sundoom:

    У меня так не получится. Дело в том, что вай-фай клиенты сидят за вай-фай роутером в отдельной сети (10.10.10.0/24) и вай-фай роутер по DHCP раздает им ip адреса. А уже от вай-фай роутера от его WAN интерфейса (222.222.222.2) прокинут шнурок к моему PFS, на котором заведен отдельный интерфейс WIFI_WAN (222.222.222.1). Все мобильные клиенты ходят в инет и другие локальные сети через шлюз 222.222.222.2.

    Насчет telnet попробую проверить, только надо найти телнет-клиент на свой смартфон.

    Во как закручено  ??? Может стоит по-другому с роутером поступить и это не единственное решение вашей задачи?
    Схему, пож-та, для наглядности .

    P.s. Как вариант, роутер перевести в режим ТД . Из него (ВАН-ифейс) кабель до pf и на ифейсе, в к-ый входит шнурок от роутера, поднять DHCP с раздачей свободных адресов как у подсети ЛАН. У меня так роутер от д-линка (дир-615) работает и уже довольно давно. Или попробовать объединить WAN_WIFI и LAN в бридж.

    P.s.s. У вас на WIFI_WAN -  белый IP (222.222.222.x)? Вы из Китая - http://bgp.he.net/ip/222.222.222.1#_ipinfo ? Если нет - смените адрес на что-то более вменяемое для локальных (серых) сетей.



  • Понимаете, не мной это было настроено и к тому же все перестраивать - ну просто не вариант, да и времени нет.
    Вот сильно упрощенная схемка моей сетки.

    По схеме видно, что вай-фай клиенты идут через вай-фай роутер и пфсенс в инет (проходят через 2 роутера). Соответственно, ip вай-фай клиентов подставляется ip адресом вай-фай роутера. Но мне нужно, чтобы веб-трафик от вай-фай роутера шел через сквид. Пока не получается…

    Кстати, PFSense поднят на виртуалке, если это что-то меняет.




  • А wifi router на схеме это точно роутер (NAT отключен) ?



  • А в настройках прокси во вкладке Proxy server: Access control разрешена подсеть 222.222.222.х ?



  • @nomeron:

    А wifi router на схеме это точно роутер (NAT отключен) ?

    ТОчно роутер. NAT включен. Я вижу только общий трафик от роутера, т.е. его IP адрес.

    @werter:

    А в настройках прокси во вкладке Proxy server: Access control разрешена подсеть 222.222.222.х ?

    Конечно, в конфиге это видно. И к тому же, если не была бы включена, то и не вываливалась бы такая ошибка на клиентах, которую я описал в начале топика.



  • ТОчно роутер. NAT включен. Я вижу только общий трафик от роутера, т.е. его IP адрес.

    Тогда как я понимаю
    Исходное значения
    10.10.10.1:рандом 1–> internet addr:80
    NAT на wifi
    222.222.222.2:рандом 2 --> internet addr:80

    Ваше правило NAT
    src xxx:80 -->  dst 172.16.0.132:81
    тогда под него ничего не подпадает

    По идее трансляция в такой ситуации невозможна.
    Проблему решает только прозрачный режим сквида, когда именно сам сквид захватывает пакеты на интерфейсе



  • Да,  и учет трафика , если получится запустить, будет ОБЩИМ , т.к. весь будет натиться на 222.222.222.1.
    Попробуйте назначить в Virtual IP интерфейсу WIFI_WAN дополнительно незанятый адрес из подсети 172.16.0.0\24. В правилах NAT-а создать новое правило - натить ви-фи клиентов на этот адрес и поместить его в самый верх.

    Но, ИМХО, повторяю, самым простым и приемлемым вариантом для вас был бы перевод ви-фи роутера в режим обычной ТД и раздача (получается прозрачно) адресов ви-фи клиентам по dhcp pf-ом автоматом. И не надо будет делать двойной (!) NAT.

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



  • @nomeron:

    Ваше правило NAT
    src xxx:80 –>  dst 172.16.0.132:81
    тогда под него ничего не подпадает

    По логике да, но почему при применении этого правила у меня и вываливается вышеописанная ошибка? Получается, что данное правило NAT влияет на дальнейшую маршрутизацию пакетов.
    Сразу встречный вопрос может ли squid работать одновременно в 2х режимах: прозрачном и в режиме аутентификации? Где-то в инете встречал, что не может. Может заблуждаюсь?

    @werter:

    Да,  и учет трафика , если получится запустить, будет ОБЩИМ , т.к. весь будет натиться на 222.222.222.1.

    Это я знаю. Мне бы пока так - общий трафик учитывать.

    @werter:

    Попробуйте назначить в Virtual IP интерфейсу WIFI_WAN дополнительно незанятый адрес из подсети 172.16.0.0\24. В правилах NAT-а создать новое правило - натить ви-фи клиентов на этот адрес и поместить его в самый верх.

    Попробую.

    @werter:

    Но, ИМХО, повторяю, самым простым и приемлемым вариантом для вас был бы перевод ви-фи роутера в режим обычной ТД и раздача (получается прозрачно) адресов ви-фи клиентам по dhcp pf-ом автоматом. И не надо будет делать двойной (!) NAT.

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

    НАсчет ТД - это понятно. А вот насчет того, чтоб сделать более правильно - не так у нас все просто. Есть ряд причин, в том числе амбициозного характера вышестоящих лиц.



  • По логике да, но почему при применении этого правила у меня и вываливается вышеописанная ошибка? Получается, что данное правило NAT влияет на дальнейшую маршрутизацию пакетов.
    Сразу встречный вопрос может ли squid работать одновременно в 2х режимах: прозрачном и в режиме аутентификации? Где-то в инете встречал, что не может. Может заблуждаюсь?

    Очень похоже, что ваш запрос проходит через нат на самом пф минуя сквид.
    Потом, поскольку правилу удовлетворяет ответ из интернета (т.е. сама страница яндекса с порта 80) она отправляется на порт сквида.
    Структура пакета в таком случае ошибочная, но часть информации видимо сквид понимает. И в пакете есть правильный обратный адрес (который отдал нат) на который сквид и отдает ошибку.



  • НАсчет ТД - это понятно. А вот насчет того, чтоб сделать более правильно - не так у нас все просто. Есть ряд причин, в том числе амбициозного характера вышестоящих лиц

    В такой ситуации я все делаю втихую. Задача была поставлена - задача решена, остальное - ненужные ньюансы. Да и начальство особо не вникает - то ли не интересует их это, то ли квалификации (иногда) не хватает.



  • В такой ситуации я все делаю втихую. Задача была поставлена - задача решена, остальное - ненужные ньюансы. Да и начальство особо не вникает - то ли не интересует их это, то ли квалификации (иногда) не хватает.

    Так и стоит делать. Хотя наверно решающий показатель надежность работы\время обслуживания.
    Если есть куча времени ковырять пф и потом бегать и разбираться, где что отвалилось, то городите свою систему.
    Я вначале в пф сомневался, но уже 3 месяца четыре точки доступа раздают wifi (в режиме NAT+лимитер). Это параллельно с двумя рабочими подсетями.
    Только народ жалуется, что уж больно точно скорость обрезается. Сквид бы наверно немного ускорил загрузку страниц.



  • Короче, перевел, wifi роутеры в режим AP, в PF настроил DHCP, ip клиентам выдаются, настроил правила, NAT - интернет работает. Попытался завернуть все это через прокси. Вылазит та же самая ошибка, что и в шапке темы. Делал так:
    Wifi сеть 10.0.0.0/24, IP на WIFI_WAN 10.0.0.1
    В Nat создал такое правило:
      If          Proto   Src. addr Src. ports Dest. addr Dest. ports NAT IP       NAT Ports
    WIFI_WAN TCP         *     *                *            80 (HTTP) 10.0.0.1 81

    В прокси добавил такие строчки:
    http_port 10.0.0.1:81
    acl WIFI-net src 10.0.0.0/255.255.255.0
    http_access allow WIFI-net

    Т.к. на LAN интерфейсе сквид работает не в прозрачном режиме с аутентификацией по kerberos и авторизацией по ldap, то acl WIFI-net я прописал до авторизации. Если включить прозрачный режим на интерфейсе 10.0.0.1, то вай-фай трафик идет через сквид, но сквид не может работать в 2х режимах одновременно и в логах ссыпятся ошибки:
    aclAuthenticated: authentication not applicable on transparently intercepted requests

    Помогите, плиз, разрулить ситуацию правильно.

    P.S. ПФсенс у меня работает в кластере, т.е. поднят CARP и чтобы сквид мог работать в кластере были добвлены такие правила NAT для каждого ПФсенса:
    If        Proto   Src. addr Src. ports Dest. addr Dest. ports NAT IP       NAT Ports
    LAN TCP          *      *           172.16.0.250      81         172.16.0.132 81
    LAN TCP          *      *           172.16.0.250      81           172.16.0.133 81

    где 172.16.0.250 - CARP IP для LAN
    172.16.0.132 - IP address PFSense1
    172.16.0.133 - IP address PFSense2



  • По идее трансляция в такой ситуации невозможна.
    Проблему решает только прозрачный режим сквида, когда именно сам сквид захватывает пакеты на интерфейсе

    Вышло так, как я раньше и писал.
    Трансляцию легко вы можете реализовать только в одну сторону.
    Вопрос в том,  как пакету выходящему со сквида вернуть в поле источника (soure) реальный ip адрес сайта, который был в запросе.
    Тогда и получим режим прозрачного прокси.



  • Короче сделал так, хотя это неправильно, но работает. Добавил в конфиг сквида след. строчки и пустил вай-фай клиентов до аутентификации:

    http_port 10.0.0.1:81
    acl WIFI-net src 10.0.0.0/255.255.255.0
    http_access allow WIFI-net

    И добавил правило NAT (завернул веб трафик с вай-фай на сквид).

    WIFI TCP 10.0.0.0/24 * * 80 (HTTP) 10.0.0.1 81

    Работает в других сетях аутентификация и авторизация как и прежде, а сетку WIFI пускает прозрачно. Правда в логах cache.log  сыпятся такие ошибки:
    aclAuthenticated: authentication not applicable on transparently intercepted requests

    Теперь вопрос как сделать так, чтобы в логах не появлалась эта ошибка, т.е. отключить логирование для таких типов ошибок, чтоб не засорять лог?



  • Поделитесь опытом
    С этим правилом

    WIFI    TCP    10.0.0.0/24    *    *    80 (HTTP)    10.0.0.1    81

    остается доступ из wifi к веб интерфейсу пф.
    Не пробовали еще такое правило
    WIFI    TCP    10.0.0.0/24    *    *    443 (HTTPs)    10.0.0.1    81
    оно ведь тоже многим нужно



  • По 443 порту в прозрачном режиме сквид не может работать, как и с ftp. Такое правило ради интереса я пробовал - не работает.
    Трафик по 443 порту пришлось пустить в обход сквида. А правилами файрвола я закрыл доступ из вай-фай к локальной сети за исключением некоторых адресов.


Locked