Мобильные клиенты 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 0pid_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 secondsacl 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.0uri_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 95acl 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 dynamicacl allow_hosts src "/var/squid/acl/unrestricted_hosts.acl"
http_access allow allow_hostsacl FTPclient proto FTP
acl FTP_port port 60000-61000
http_access allow FTPclient
http_access allow CONNECT FTP_porthttp_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-srvacl 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-Mailrequest_body_max_size 0 KB
reply_body_max_size 0 deny alldelay_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 Unlimithttp_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 попробую проверить, только надо найти телнет-клиент на свой смартфон.
-
У меня так не получится. Дело в том, что вай-фай клиенты сидят за вай-фай роутером в отдельной сети (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.х ?
-
А wifi router на схеме это точно роутер (NAT отключен) ?
ТОчно роутер. NAT включен. Я вижу только общий трафик от роутера, т.е. его IP адрес.
А в настройках прокси во вкладке 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.
Не бойтесь исправлять то, что кто-то до вас настроил явно неправильно. В крайнем случае, сделайте бэкап настроек роутера - это не сложно. Если не выйдет, то сможете всегда восстановить роутер к первоначальному состоянию без проблем.
-
Ваше правило NAT
src xxx:80 –> dst 172.16.0.132:81
тогда под него ничего не подпадаетПо логике да, но почему при применении этого правила у меня и вываливается вышеописанная ошибка? Получается, что данное правило NAT влияет на дальнейшую маршрутизацию пакетов.
Сразу встречный вопрос может ли squid работать одновременно в 2х режимах: прозрачном и в режиме аутентификации? Где-то в инете встречал, что не может. Может заблуждаюсь?Да, и учет трафика , если получится запустить, будет ОБЩИМ , т.к. весь будет натиться на 222.222.222.1.
Это я знаю. Мне бы пока так - общий трафик учитывать.
Попробуйте назначить в Virtual IP интерфейсу WIFI_WAN дополнительно незанятый адрес из подсети 172.16.0.0\24. В правилах NAT-а создать новое правило - натить ви-фи клиентов на этот адрес и поместить его в самый верх.
Попробую.
Но, ИМХО, повторяю, самым простым и приемлемым вариантом для вас был бы перевод ви-фи роутера в режим обычной ТД и раздача (получается прозрачно) адресов ви-фи клиентам по 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 порту пришлось пустить в обход сквида. А правилами файрвола я закрыл доступ из вай-фай к локальной сети за исключением некоторых адресов.