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

sundoom

Добрый день.
Возникла очередная загвозка. Задача: необходимо пустить мобильных юзеров по 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

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

werter

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

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

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

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 попробую проверить, только надо найти телнет-клиент на свой смартфон.

werter

@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 ? Если нет - смените адрес на что-то более вменяемое для локальных (серых) сетей.

sundoom

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

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

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

nomeron

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

werter

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

sundoom

@nomeron:

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

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

@werter:

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

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

nomeron

ТОчно роутер. 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
тогда под него ничего не подпадает

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

werter

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

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

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

sundoom

@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.

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

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

nomeron

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

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

werter

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

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

nomeron

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

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

sundoom

Короче, перевел, 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

nomeron

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

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

sundoom

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

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

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

nomeron

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

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
оно ведь тоже многим нужно

sundoom

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