pfSense как шлюз для нескольких компаний

X3PPY

Всем привет!

Есть 5 проводов от провайдера. На каждом свой договор. Настройка через PPPoE.
Есть холдинг. Все вокруг общее, локальная сеть одна. Но нужно чтобы некоторые компьютеры в этой локальной сети ходили через свои шлюзы из числа этих пяти проводов. С NAT все просто. Я завел все провода в сервер, настроил подключения, настроил фаервол для выхода с конкретных алиасов (ip адреса) на свой шлюз. В теории все работает и можно было бы остановится, но т.к. это мое первое знакомство с pfSense решил попробовать считать трафик.

Хочется получить функционал на подобии Керио. Там можно создать правило по пользователю\по адресу и пустить его через любой шлюз или через любой внешний ИП на шлюзе, при этом тамошний прокси все запишет на нужного пользователя.

В pfSense же, если работать через прокси, то правила NAT в фаерволе игнорируются и внешний ИП у всех один.

Собственно вопросы: может ли pfSense + squid в принципе работать с несколькими раздельными WAN (грубо говоря своя копия squid на каждый WAN)? Можно ли создавать правила с Source не по алиасам\ip адресам, а по имени пользователя, если настроен kerberos?

И еще вопрос. В этой же локальной сети есть виртуалка с тестовым pfSense. Один WAN один LAN. Настроен прозрачный squid с фильтрацией HTTPS splice all (Splice Whitelist, Bump Otherwise тоже все работает). В данной конфигурации с клиента все прекрасно работает. Считается HTTPS трафик, подменяется или пропускается сертификаты по whitelist - вопросов нет. Но на сервере с 5 WAN с точно такой же настройкой squid некоторые сайты (например youtube) выводят ошибку SSL_ERROR_RX_RECORD_TOO_LONG. Если настроить непрозрачный прокси то ошибки нет, но не могу понять, почему на тестовой машине все норм, а на боевой нет...

viktor_g

Собственно вопросы: может ли pfSense + squid в принципе работать с несколькими раздельными WAN (грубо говоря своя копия squid на каждый WAN)? Можно ли создавать правила с Source не по алиасам\ip адресам, а по имени пользователя, если настроен kerberos?

В squid'е есть директива tcp_outgoing_address вот с помощью неё и можно указать исходящий адрес для конкретного адреса,
см. https://forum.netgate.com/topic/97328/work-in-progress-squid-failover-and-load-balancing-for-pfsense
На данный момент поддерживается только Local/RADIUS/LDAP аутентификация. С kerberos не всё так просто, см https://redmine.pfsense.org/issues/5646

Но на сервере с 5 WAN с точно такой же настройкой squid некоторые сайты (например youtube) выводят ошибку SSL_ERROR_RX_RECORD_TOO_LONG.

Какая у вас версия pfSense / squid ?

X3PPY

pfSense: 2.4.5-RELEASE-p1 (amd64)
squid: 0.4.44_30 (squid -v: Squid Cache: Version 4.10)

viktor_g, спасибо!

@viktor_g said in pfSense как шлюз для нескольких компаний:

В squid'е есть директива tcp_outgoing_address вот с помощью неё и можно указать исходящий адрес для конкретного адреса

Это решение работает! Спасибо!
В Services -> Squid Proxy Server -> General: Show Advanced Options
Custom Options (Before Auth), нужно указать примерно следующее
acl ACL_NAME src 192.168.100.1 10.0.3.0/24
tcp_outgoing_address GATEWAY_IP ACL_NAME

Осталась проблема с SSL_ERROR_RX_RECORD_TOO_LONG + прозрачный прокси + HTTPS

werter

@X3PPY

Осталась проблема с SSL_ERROR_RX_RECORD_TOO_LONG + прозрачный прокси + HTTPS

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

werter

@X3PPY

acl ACL_NAME src 192.168.100.1 10.0.3.0/24

Может acl ACL_NAME src 10.0.3.0/24 ? Зачем там еще одиночный ip (192.168.100.1) ?

X3PPY

@werter said in pfSense как шлюз для нескольких компаний:

@X3PPY

Осталась проблема с SSL_ERROR_RX_RECORD_TOO_LONG + прозрачный прокси + HTTPS

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

Проблемных доменов может быть много, гугл, ютуб... Никакой подмены сертификатов не происходить (splice all).
Да и даже если придумать какой-то костыль - почему на тестовой машине все работает...
Ошибка в логах squid: NONE/409 4101 CONNECT www.youtube.com:443 - HIER_NONE/- text/html
Попробовал на тестовой машине добавить в прослушку loopback интерфейс, убрать\поставить прозрачный прокси, убрать\поставить SSL MITM. На 5 минут ситуация повторилась - ошибка при открытии youtube. Но спустя короткое время все восстановилось и работает...

@werter said in pfSense как шлюз для нескольких компаний:

@X3PPY

acl ACL_NAME src 192.168.100.1 10.0.3.0/24

Может acl ACL_NAME src 10.0.3.0/24 ? Зачем там еще одиночный ip (192.168.100.1) ?

Это просто для примера, вдруг кому-то потребуется. Можно как одиночный ип указывать так и сеть. У меня несколько одиночных ИП указано в конечном итоге - это работает.

werter

Ошибка в логах squid: NONE/409 4101 CONNECT www.youtube.com:443 - HIER_NONE/- text/html

https://www.linuxquestions.org/questions/linux-server-73/tag_none-409-connect-squid-3-5-20-a-4175620518/
https://stackoverflow.com/questions/31742245/https-sites-not-working-in-squid-transparent-mode

werter

@X3PPY said in pfSense как шлюз для нескольких компаний:

GATEWAY_IP

Подскажите, что там указывать?

X3PPY

@werter said in pfSense как шлюз для нескольких компаний:

@X3PPY said in pfSense как шлюз для нескольких компаний:

GATEWAY_IP

Подскажите, что там указывать?

Перечисляем клиентов: хосты или сети

acl acl_wan2 src 192.168.1.5 192.168.1.20 192.168.1.21 192.168.1.23 192.168.1.24

Указываем шлюз

tcp_outgoing_address 5.255.255.5 acl_wan2

где 5.255.255.5 - это внешний IP адрес от провайдера (соединение предварительно настроено)

Проблема с прозрачным прокси + HTTPS решена:
https://docs.netgate.com/pfsense/en/latest/cache-proxy/squid-troubleshooting.html

Перевод от гугла:

Сайты не загружаются с соединением / Ошибка 409 в журнале доступа
В качестве меры безопасности squid не позволит пользователю подключаться к сайту, имя которого не соответствует его IP-адресу. Это не позволяет клиентам жестко кодировать или изменять ответы DNS, чтобы избежать контроля доступа. Побочным эффектом этого, однако, является то, что сайты, которые используют циклический DNS или другие оптимизации DNS, могут заставить squid непреднамеренно блокировать или сбрасывать соединения с этими сайтами. Журнал доступа squid будет иметь код ошибки 409 (конфликт) по причине разрыва соединения.

Это происходит с такими сайтами, как Google или Facebook, когда клиент и squid используют разные источники для DNS и, таким образом, получают разные результаты DNS для одного и того же запроса, потому что результаты рандомизированы. Несмотря на то, что адрес для сервера является действительным, несоответствие заставляет Squid разорвать соединение.

Решение состоит в том, чтобы клиенты использовали брандмауэр в качестве своего DNS-сервера, чтобы и Squid, и клиенты использовали один и тот же источник DNS, и результаты соответствовали бы.

werter

@X3PPY

Может и так можно https://www.linux.org.ru/forum/general/14459476 ?
Т.е. 'dns_nameservers 127.0.0.1' добавить в Advanced сквида и перезагрузиться?
Возможно, еще понадобится принудительно завернуть все днс-запросы клиентов на ip пф для того, чтобы не было конфликта с разрешением имен сквидом и локальными клиентами.

X3PPY

@werter said in pfSense как шлюз для нескольких компаний:

@X3PPY

Может и так можно https://www.linux.org.ru/forum/general/14459476 ?
Т.е. 'dns_nameservers 127.0.0.1' добавить в Advanced сквида и перезагрузиться?
Возможно, еще понадобится принудительно завернуть все днс-запросы клиентов на ip пф для того, чтобы не было конфликта с разрешением имен сквидом и локальными клиентами.

Тут решение просто поднять DNS сервер (он уже стоит по умолчанию в pfSense) и указать его для squid и для клиентов. У меня в сети есть AD и DNS. В настройках pfSense эти днс указаны. Но так же у pfSense есть днс от провайдеров, а у меня их 5. Теоретически можно запретить pfSense использовать днс от провайдера и получать резолв от моих внутренних днс... надо подумать какой вариант лучше...

werter

Добрый.
@X3PPY said in pfSense как шлюз для нескольких компаний:

У меня в сети есть AD и DNS. В настройках pfSense эти днс указаны.

Не указывать ip этих ДНС явно в настройках днс пф-а. Указать их в форвадинге в настройках unbound, т.е. "объяснить" пф, что вот эти домены обслуживают вот эти DNS. Делается прямо в вебке пф.
Клиентам же по dhcp выдавать 1-м днс - адрес пф, 2-м и последующими - адреса внутренних dns.

Но так же у pfSense есть днс от провайдеров, а у меня их 5.

Не использую днс провайдеров без особой надобности (напр., для разрешения имен внутренних ресурсов провайдеров, но и это решаемо). Использую я-днс\г-днс etc. Тот же днс от adguard еще и рекламу резать будет.

Получать резолв от моих внутренних днс

Описал в п.1

И самое главное - не забыть принудительно завернуть все днс-запросы клиентов на ip пф. Делается одним правилом port forward на LAN https://docs.netgate.com/pfsense/en/latest/dns/redirecting-all-dns-requests-to-pfsense.html

Тогда схема сквида с директивой 'dns_nameservers 127.0.0.1' должна заработать.

Я бы попробовал реализовать, сделав перед этим обязательный бэкап настроек пф.