NAT, перенаправление трафика на другой узел

dilo

Доброго времени суток.
В организации имеется 2 не зависимых pfsense смотрящих в Lan интерфейсами в одну локальную сеть и отдельный для каждого Wan интерфейс.
Pfsense1 настроен как обычный роутер с dhcp сервером и со своими правилами проброса входящего трафика и является основным шлюзом.
Pfsense2 является резервом и также системой для проверки конфигураций, также на котором развёрнут squid и lightsquid.

Стоит достаточно простая задача пускать несколько компьютеров в некоторые временные промежутки времени через прокси на pfsense2 (руководство периодически устраивает проверки трафика).
Для того чтобы не ходить и не прописывать прокси сервер на каждом ПК вручную возникло желание прописать правило для перенаправления исходящего web трафика с опередённых ip на pfsese2 на порт прокси (3128). Всё бы не чего, но как бы я не пробовал правило не срабатывает.

Пробовал по разному менять сети WAN в правиле, менять порты, но в логах прокси не чего не видно, а на тестовом компьютере все сайты открываются :( .

Также пробовал выдавать через dhcp тестовому компьютеру pfsense2 как ОШ для использования прозрачного прокси, но он отлавливает только http и не видит https.
Пробовал развернуть wpad через DHCP, но почему-то тестовый компьютер с win7 не воспринял настройки и решил не копать в эту сторону.

Подскажите в чём может быть дело? куда копать? может есть лучше варианты?
На текущий момент поставил временно mikrotik и он перенаправляет трафик на порт прокси.

Заранее спасибо.

1. Первый раз вижу несколько роутеров в одной сети… А не пробовали на один сенс несколько интерфейсов и вперед, настраивайте сколько хотите и все бегает с родным шлюзом...
2. Обратные статические роуты на каждом компе?
3. Обычный прокси не будет отлавливать https трафик... Он будет отлавливать только HTTP по 80 порту. Чтобы резать HTTPS есть много статей как настраивать, но как по мне, проще просто резануть порт для наборов компьютеров...

dilo

@Bansardo:

1. Первый раз вижу несколько роутеров в одной сети… А не пробовали на один сенс несколько интерфейсов и вперед, настраивайте сколько хотите и все бегает с родным шлюзом...
2. Обратные статические роуты на каждом компе?
3. Обычный прокси не будет отлавливать https трафик... Он будет отлавливать только HTTP по 80 порту. Чтобы резать HTTPS есть много статей как настраивать, но как по мне, проще просто резануть порт для наборов компьютеров...

Ну тут удобно что не всё на одном устройстве. Если что-то произойдёт с ПО или железом основного устройства то будет достаточно пары кликов для продолжения работы офиса(замена ip резервного устройства на основной или просто включение dhcp на резерве). Простой составит минут 10 (включая первоначальную диагностику погибшего девайса). Да и всегда есть полигон для дополнительных проверок и экспериментов.
Да и думаю и с двумя роутерами должно всё бегать отлично, просто подозрение что как обычно забыл где-то "галочку поставить".
Они не требуются так как все девайсы находятся в одной подсети, в прямой видимости.
Личный экспериментальный роутер микротик также без маршрутов справляется, без ната, просто редирект в фаерволе. Хотелось бы чтобы на pfsense всё было =)

3)Увы, но порт закрыть нельзя. Сейчас очень много сайтов работают только через https, а также возможно потребуется заворачивать на прокси и web клиент-банки.
как понял, можно включить SSL Man In the Middle Filtering , но это не решил проблему личного присутствия меня на наблюдаемом месте.

Вчера вечером ещё поиграл с правилами и настройками. Нашёл в настройках "Enable automatic outbound NAT for Reflection" и включил.
Также получилось завернуть трафик на прокси когда выставил в Destination Any :o (источником также оставил ip наблюдаемого), но похоже тогда теряется часть адреса http и не чего не открывается.

Вроде задача простая, а бьюсь уже день 5-тый. :(

По поводу безотказности:
MultiWAN на одной железке решает вопрос с отказом канала
Конфиг файл PF в прямой доступности + стоящий установленный комп с чистым PF решает вопрос по замене сломавшегося за 1 минуту.
С одной железкой PF не надо мучатся с заворачиванием и перенаправлением.

Если хотите перенаправить определенные IP, тогда в фаерволе надо прописать маршрут в Firewall LAN с указанием Source IP ПК для переброски (их лучше вбить алиасом) и портом 80, Destination IP PF2 и порт также 80. А PF должен сам перебросить 80 порт на прокси, если все в одной подсети.
А чисто теоретически в разделе Route PF1 создать новый шлюз (IP PF2) и задать в ручную для IP нужных компов, предварительно забив их по MAC в статическую таблицу DHCP, этот шлюз. Тоже должно прокатить.

werter

Вставлю свои 5 коп

Виртуализация (кластер- proxmox умеет от 3-х нод) + pf (+CARP)

pigbrother

Давно думаю про CARP.
Спрашивал тут:
https://forum.pfsense.org/index.php?topic=113152.msg630657#msg630657
Спрашивал там:
https://forum.pfsense.org/index.php?topic=111069.0

Так и неясно - возможен ли CARP при PPPOE over Ethernet

dilo

@Bansardo:

По поводу безотказности:
MultiWAN на одной железке решает вопрос с отказом канала
Конфиг файл PF в прямой доступности + стоящий установленный комп с чистым PF решает вопрос по замене сломавшегося за 1 минуту.
С одной железкой PF не надо мучатся с заворачиванием и перенаправлением.

Если хотите перенаправить определенные IP, тогда в фаерволе надо прописать маршрут в Firewall LAN с указанием Source IP ПК для переброски (их лучше вбить алиасом) и портом 80, Destination IP PF2 и порт также 80. А PF должен сам перебросить 80 порт на прокси, если все в одной подсети.
А чисто теоретически в разделе Route PF1 создать новый шлюз (IP PF2) и задать в ручную для IP нужных компов, предварительно забив их по MAC в статическую таблицу DHCP, этот шлюз. Тоже должно прокатить.

По поводу безотказности:
Описанная ситуация аналогична, только пока отсутствует "мультиван". Просто рядом стоящий pf не простаивает а участвует в экскрементах и сейчас это прокси.

Разве исходящий порт будет 80? Браузер вроде генерирует исходящий порт из свободно используемых.
Мысль про маршрут была, но тогда прокси должен работать в прозрачном режиме и перехватывать http и https - что без прямого вмешательства к клиентскому пк не получится из-за добавления сертификата под https.

Попробовал, результата нет :(
Немного не понял где именно правило надо и сделал разные варианты.
firewall->NAT

firewall->rules->lan

лог в states

Вместо 80 порта взял и 443 порт https.

Предполагаю что правило должно быть в Nat зоне с Source IP c any порт и Destination wan net, redirect ip pf2 с протом 3128, Но почему-то оно не срабатывает :(
Подскажите что бы Вы сделали если бы это было реализовано на одном PF, может по аналогии найду у себя ошибку :( какбы мне завернуть https трафик на порт прокси :(

@werter:

Вставлю свои 5 коп

Виртуализация (кластер- proxmox умеет от 3-х нод) + pf (+CARP)

Развёрнута аналогичная система, но даже в такой системе может упасть хранилище и кластер с миграцией будет бесполезен + вторая pf преимущественно используется для тестов и экспериментов, как в данном случае возникла потребность в временной прокси.

dilo

@pigbrother:

Давно думаю про CARP.
Спрашивал тут:
https://forum.pfsense.org/index.php?topic=113152.msg630657#msg630657
Спрашивал там:
https://forum.pfsense.org/index.php?topic=111069.0

Так и неясно - возможен ли CARP при PPPOE over Ethernet

Судя по теме dsl работает роутер работает стабильно, тогда почему не поднять pppoe на нём, пусть он выдаёт "готовый интернет" - поработает, так сказать, роутером. За dsl стаить свич тогда carp можно легко использовать в обычных для него условиях и не привязываться вообще к технологии ПД.

pigbrother

@dilo:

@pigbrother:

Давно думаю про CARP.
Спрашивал тут:
https://forum.pfsense.org/index.php?topic=113152.msg630657#msg630657
Спрашивал там:
https://forum.pfsense.org/index.php?topic=111069.0

Так и неясно - возможен ли CARP при PPPOE over Ethernet

Судя по теме dsl работает роутер работает стабильно, тогда почему не поднять pppoe на нём, пусть он выдаёт "готовый интернет" - поработает, так сказать, роутером. За dsl стаить свич тогда carp можно легко использовать в обычных для него условиях и не привязываться вообще к технологии ПД.

Тогда попадаешь в зависимость от надежности\производительности внешнего устройства, плюс прелести двойного NAT.
Да и нет у меня DSL. К счастью\сожалению.

@dilo:

Разве исходящий порт будет 80? Браузер вроде генерирует исходящий порт из свободно используемых.
Мысль про маршрут была, но тогда прокси должен работать в прозрачном режиме и перехватывать http и https - что без прямого вмешательства к клиентскому пк не получится из-за добавления сертификата под https.

Это простите как? На каком тогда прокси работает, если порт генерируется рандомно? HTTP всегда ходило и будет ходить в стандарте по 80 порту. Это общепринятый закон.
@dilo:

Вместо 80 порта взял и 443 порт https.

А шифрование не пугает? Ну добавили, ничего не будет работать, только на лишний порт прокси смотреть будет. У нас в компании не запрещали, а просто поставили контроль трафика, кто гуляет куда не надо, предоставляются распечатки инженером по защите информации шефу на планерке, а тот дрюкает потом. И шефу не скучно и все держатся в тонусе. )
@dilo:

Немного не понял где именно правило надо и сделал разные варианты.
firewall->NAT

Зачем NAT трогать? У вас он итак Ваш диапазон пускает наружу. Как Вы описали, все находится в одном диапазоне ЛВС. Прочитайте что такое NAT и зачем он нужен, дабы не натворить глупостей.

Мой Вам совет, переходите на одну железку вместо двух и куча вопросов отпадет сама собой. Не делайте масло масляное.

dilo

@Bansardo:

Это простите как? На каком тогда прокси работает, если порт генерируется рандомно? HTTP всегда ходило и будет ходить в стандарте по 80 порту. Это общепринятый закон.

Видимо я не верно понял тот вариант который предложили.
"с указанием Source IP ПК для переброски (их лучше вбить алиасом) и портом 80" - как понял имелось ввиду перехватывать пакеты которые исходят с источника где ip пк перепроброски (допустим 192.168.1.5) и портом 80.

Барузер формирует пакет данных в котором есть Ip:порт источника и ip:порт назначения. Каждое приложение занимает свой порт на устройстве. Обще принято использовать веб серверу для http 80 порт. Для работы firefox нет стандарта использования порта и поэтому он берёт из свободных. Следовательно браузер firefox будет причиной создания пакета где будет ip:порт_из_свободных в источнике и ip_веб_сайта:80 в назначениях. Пример сайт mail.ru 192.168.1.5:48836 -> 217.69.139.199:80
Поэтому меня и смутила информация о "с указанием Source IP ПК для переброски (их лучше вбить алиасом) и портом 80". Возможно не прав так как не могу понять как графический интерфейс pf переведёт в правила фаервола. Видимо и меня не так поняли, Извиняюсь.
Кстати наглядный пример хождения пакета на 3-тем скрине. Увы, это скрин после построения правил и видно что перенаправления не было.

@Bansardo:

А шифрование не пугает? Ну добавили, ничего не будет работать, только на лишний порт прокси смотреть будет. У нас в компании не запрещали, а просто поставили контроль трафика, кто гуляет куда не надо, предоставляются распечатки инженером по защите информации шефу на планерке, а тот дрюкает потом. И шефу не скучно и все держатся в тонусе. )

Не пугает. Первоначально идёт передача не шифрованных заголовков что прекрасно логируется проксей и можно узнать на каких сайтах сидел пользователь. Нельзя просмотреть только содержимое, но и это можно сделать через SSL Man In the Middle Filtering, но не исключит физический обход перенаправляемых компьютеров .
А Вы не задумывались как инженер собирает логи для контроль трафика? Net Flow? Net Stat? Proxy? В любом случае происходит сбор на отдельной машине. Для более простого и ЧИТАБЕЛЬНОГО отчёта чаще всего используется Прокси где тем или иным способом трафик перенаправляется на сервер.

@Bansardo:

Зачем NAT трогать? У вас он итак Ваш диапазон пускает наружу. Как Вы описали, все находится в одном диапазоне ЛВС. Прочитайте что такое NAT и зачем он нужен, дабы не натворить глупостей.

Я прекрасно представляю работу ната и если вы не заметили на скринах отключаю трансляцию адреса при перенаправлении. Роутеру требуется обрабатывать трафик проходящий сквозь него и обработка таких данных в большинстве случаев происходит в зоне NAT (в веб формах не выделяют отдельно зону FORWARD). Явным и простым примером является проброс портов с wan в lan, прмеров которых явно больше чем в моём случае.

Я также проделал предложенный вариант, скрин 2, подскажите верно ли правило и так задумывалось?

@Bansardo:

Мой Вам совет, переходите на одну железку вместо двух и куча вопросов отпадет сама собой. Не делайте масло масляное.

Хорошо, я учту. Но в любом случае я так и не увидел варианта перенаправления трафика с хотя бы на одном железке. Вот какой вариант будет когда мне требуется на одном pf перенаправить направленный в интернет трафик с 443 порта на 3128 порт для логирования в проксе.

Заранее спасибо.

dilo

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

https://forum.pfsense.org/index.php?topic=120850.0
https://forum.pfsense.org/index.php?topic=117946.0
https://forum.pfsense.org/index.php?topic=113328.0
https://forum.pfsense.org/index.php?topic=69664.msg380825#msg380825
https://forum.pfsense.org/index.php?topic=100693.msg561267#msg561267
https://forum.pfsense.org/index.php?topic=32661.0
https://forum.pfsense.org/index.php?topic=97931.msg545547#msg545547

Почти все задачи имеют свои отличия, но все сводят к одному решению в виде переадресации трафика на прокси через пункт NAT:

The NAT topic.

Assuming your squid is running on 3128 + 3129 ports you can try:
Source: any
Destination any
Dport: 80
redirect IP: 192.168.1.12
redirect port 3128

and
Source: any
Destination any
Dport: 443
redirect IP: 192.168.1.12
redirect port 3129

If this is not working then try with such a NAT rule:
Source: any
Destination any
Dport: 80
redirect IP: 127.0.0.1
redirect port 3128

and

Source: any
Destination any
Dport: 443
redirect IP: 127.0.0.1
redirect port 3129

Увы, в моём случае всё это не подошло. Как выяснилось squid в pfsense имеет весьма скудный конфиг и всегда наравит исправить все мои "ручные" изменения на свои. Был развёрнут свой сервер с ~~"игральными автоматомами" и~~ "кальмаром" который отлично отрабатывал в прозрачном режиме http и https. Также отдельная консольная система позволила крутить на себе iptables в любом понравившемся направлении, в следствии чего заворот трафика с 80 и 443 портов на порты прокси было решено сделать именно на данной системе.
Главный вопрос упростился, но также остался, "Как перенаправить направленный на 80 и 443 порты трафик идущий с локальной сети без изменений на адрес прокси сервера?".
Задача также решена:
В разделе firewall->rules->LAN создал правила

Action: pass
Interface: LAN
Address Family: ipv4
Protocol: TCP

Source alias: iptoproxy (в аиасах вбит список ip)
Source port range: any
Destination: any
Destination port range: 80

Gateway: Proxy IP (прописывается ip прокси сервера на который требуется перенаправлять)

И

Action: pass
Interface: LAN
Address Family: ipv4
Protocol: TCP

Source alias: iptoproxy (в аиасах вбит список ip)
Source port range: any
Destination: any
Destination port range: 443

Gateway: Proxy IP (прописывается ip прокси сервера на который требуется перенаправлять)

PF перенаправляет только паркеты направленные на 80 и 443 порт на сервер с прокси. Далее firewall на отдельном сервере заворачивает на требуемые порты прокси.

Система отлично отработала неделю, НО руководство всё же решило проксировать всех сотрудников так что всё равно пришлось внедрять wpad и выключать всю эту прозрачность.

Оставляю найденые решения, вдруг кому тоже потребуется , но в roadmap pf видно что во всю внедряется прозрачность прокси для https без подмены сертификатов.

PbIXTOP

@dilo:

В разделе firewall->rules->LAN создал правила

Action: pass
Interface: LAN
Address Family: ipv4
Protocol: TCP

Source alias: iptoproxy (в аиасах вбит список ip)
Source port range: any
Destination: any
Destination port range: 80

Gateway: Proxy IP (прописывается ip прокси сервера на который требуется перенаправлять)

И

Action: pass
Interface: LAN
Address Family: ipv4
Protocol: TCP

Source alias: iptoproxy (в аиасах вбит список ip)
Source port range: any
Destination: any
Destination port range: 443

Gateway: Proxy IP (прописывается ip прокси сервера на который требуется перенаправлять)

Очень плохая идея по умолчанию, если Proxy IP входит в подсеть самого клиента, которого pfSense перенаправляет, поскольку просто сработает асимметричная маршрутизация, а pfSense её не любит из коробки.

dilo

@PbIXTOP:

Очень плохая идея по умолчанию, если Proxy IP входит в подсеть самого клиента, которого pfSense перенаправляет, поскольку просто сработает асимметричная маршрутизация, а pfSense её не любит из коробки.

Возможно, но PF не выдавал ошибки в логах и уведомлений. Возможно из-за того что он не перепроверял список ip а Аслиасе. Возможно так как proxy-ip считается одним из GW.
Напрямую в правиле PF запрещает писать ip, но если его добавить в настройках в список GW то можно выбрать в выпадающем меню.
А вообще согласен, выглядит странно, быстрее костыль :( , но лучше не нашёл.

PbIXTOP

@dilo:

@PbIXTOP:

Очень плохая идея по умолчанию, если Proxy IP входит в подсеть самого клиента, которого pfSense перенаправляет, поскольку просто сработает асимметричная маршрутизация, а pfSense её не любит из коробки.

Возможно, но PF не выдавал ошибки в логах и уведомлений. Возможно из-за того что он не перепроверял список ip а Аслиасе. Возможно так как proxy-ip считается одним из GW.

А ошибок не будет в логах. pfSense не обращает внимание на плохо устанавливаемые соединения.