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

A Former User

По поводу безотказности:
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. К счастью\сожалению.

A Former User

@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 не обращает внимание на плохо устанавливаемые соединения.