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