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