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

sundoom

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

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

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