Как настроить DMZ, проброс портов и NAT loopback?

Question

[vitalyrline]

Здравствуйте!
Имеется сервер NextCloud в виде контейнера Proxmox. Есть задача открыть к нему доступ из интернета. У организации есть белый ip адрес.
Решил разместить сервер в демилитаризованной зоне (DMZ) и затем уже пробрасывать порты. Но поскольку раньше не приходилось настраивать DMZ не уверен, что сделал это правильно.
Опишу как настроил DMZ. В качестве роутера выступает Mikrotik RB-951G ROS 6.49.19, у которого 5-й порт был свободен. Создал отдельный бридж (bridge_dmz), поместил этот порт туда и задал бриджу адрес 172.16.100.1/24. Настроил NAT на этот бридж. У основного бриджа адрес 192.168.1.1/24. В FW настроил правила блокирующие доступ из DMZ в основную сеть и к микротику.
Firewall Rule. Chain: forward. In.Interface: bridge_dmz. Out.Interface: bridge. Action: drop.
Firewall Rule. Chain: input. In.Interface: bridge_dmz. Action: drop.

Шнурок из 5 порта Микротика воткнул в свободную сетевуху на Проксмоксе. Там так же создал отдельный Linux bridge (vmbr2), в который поместил указанный сетевой интерфейс. Затем создал ещё один Linux bridge (vmbr3), в нём никаких сетевых интерфейсов нет. Этот бридж будет внутренней сетью для общения виртуальных машин между собой.
Поднял ВМ pfSense. Порт WAN повесил на vmbr2 и присвоил ему адрес 172.16.100.2/24. Порт LAN на vmbr3 с адресом 172.16.101.1/24. У контейнера Nextcloud адрес 172.16.101.2, интерфейс так же висит на vmbr3.
Далее на Микротике открыл порт, для примера это будет 11111 и настроил проброс этого порта на pfSense 172.16.100.2. С порта 11111 на pfSense настроил проброс на порт 443 контейнера NextCloud.
Проброс работает. Из интернета я попадаю на веб морду NextCloud. В то же время из сети 172.16.101.0 я не могу достучаться в сеть 192.168.1.1. Значит и DMZ работает.
Но основная проблема в том, что пользователям сети 192.168.1.1 так же нужно попадать в NextCloud. Изнутри не получится, для этого собственно и сделана DMZ. Если я правильно понимаю, нужно настроить Nat loopback на Микротике.
Что пробовал сделать.
NAT Rule. srcnat. Src.Address: 192.168.1.0/24 Dst.Address: 172.16.100.2. Action: masqerade
Firewall Rule. Chain: forward. Src.Address: 192.168.1.0/24. Dst.Address: 172.16.100.2. Protocol: 6(tcp). Dst.Port: 443. Action: accept
Но не получилось. Прошу помощи.

Comments

[Dieman666]

ну короче вы сами себе своим решением решили усложнить жизнь, за место того, чтобы просто пробросить порт, и теперь условно на ровном месте маетесь головняком, за место того, чтобы просто забить на этот дмз, я ничего не упустил?)

[vitalyrline]

Dieman666, В целом всё верно. Мы не ищем лёгких путей.

[muhamuha]

в смысле, вы пытаетесь сделать доступ туда, куда сами его и ограничили? Это не про легкие-нелёгкие пути, это про здравый смысл. Неправильно поставленная задача не имеет решения

[Ziptar]

А ведь можно было просто сделать два влана с маршрутизацией между ними и не мучаться

[Aleksandr]

Зачем второй бридж на микротике, если в нем всего один порт? А так, вариант с dmz имеет право быть. Hairpin nat поправить, как тут писали, и будет работать.

[Valentin Barbolin]

NAT Rule. srcnat. Src.Address: 192.168.1.0/24 Dst.Address: 172.16.100.2. Action: masqerade
Firewall Rule. Chain: forward. Src.Address: 192.168.1.0/24. Dst.Address: 172.16.100.2. Protocol: 6(tcp). Dst.Port: 443. Action: accept

После этих правил клиент из сети 192.168.1.0/24 обращается на 172.16.100.2:433 ?
На pfsence правил блокировки нет?
На микроте есть правило established,related ?

[vitalyrline]

После этих правил клиент из сети 192.168.1.0/24 обращается на 172.16.100.2:433 ?

Если имеется ввиду доступность, то нет, правила не сработали.

На pfsence правил блокировки нет?

На pfSene открыт порт и настроен проброс, остальное всё по дефолту.

На микроте есть правило established,related ?

Да, есть дефолтное правило.

[vitalyrline]

Ziptar,

А ведь можно было просто сделать два влана с маршрутизацией между ними и не мучаться

Если между ними будет маршрутизация, то как это сочетается с DMZ?

[Ziptar]

vitalyrline, я лично вообще не люблю понятие DMZ как таковое, это фуфел. Есть разные способы изоляции сервиса/машины. На разных уровнях и разными методами. Влан тебе бесплатно, то есть даром, даёт изоляцию на L2. А само требование доступа к сервису из локальной подсети вынуждает тебя так или иначе маршрутизировать к сервису трафик на L3. Не важно как ты будешь это делать - нормально маршрутизировать, нормально отфильтровывая всё, кроме нужного трафика, либо непонятно зачем пропустишь через NAT - то есть всё равно смаршрутизируешь, но с довольным видом думая, что NAT тебя от чего-то спасёт, и обозвав это DMZ.
Ты, вот, второй бридж обозвал DMZ. Так можно? Ну можно. Некрасиво, но можно. Но доступ тебе из локалки всё равно нужен, всё равно ты маршрутизируешь туда трафик всё на том же L3. И дальше что? А pfsence тут просто не нужен ни за чем.

Answer 1

[Пума Тайланд]

Там нет dstnat-правила для hairpin. Srcnat-masquerade у тебя правильный, но без dst-nat трафик из 192.168.1.x на публичный IP не перехватывается — просто уходит к провайдеру, а не редиректится на pfSense.

Добавь в NAT (до основного dst-nat):

chain=dstnat src-address=192.168.1.0/24 dst-address=<белый_IP> dst-port=11111 protocol=tcp action=dst-nat to-addresses=172.16.100.2 to-ports=11111

И ещё: в forward-правиле у тебя dst-port=443, а нужно 11111 — dst-nat уже поменял порт до forward chain.

Comments

[vitalyrline]

Сделал. Форвард правило тоже исправил. Не помогло.