NAT и PAT и весь /29 - Форум UBIQUITI.RU

NAT и PAT и весь /29, UniFi Network

mumbles202

Guest

26.03.2019 20:05:00

Есть ли возможность сделать PAT для всего /29, который предоставляет провайдер? Я вижу, как настроить переадресацию портов на IP-адресе WAN-интерфейса без проблем, но пытаюсь понять, как использовать оставшиеся 4 IP, которые выделил провайдер. Я заменяю SonicWall на USG Pro и хочу максимально приблизить конфигурацию к текущей. Если это возможно только через CLI, я могу с этим смириться, так как, скорее всего, это временно. Если да, и у кого-то есть пример или документация, которую можно почитать — буду признателен.

mumbles202 Guest	#2 07.06.2019 18:28:00 Я не пытался запускать статистику, пока это не работало. В следующий раз попробую.

UI-Team Guest	#3 07.06.2019 17:15:00 @mumbles202 Насколько я помню, они должны работать из GUI. Ты запускал команду "show firewall name WAN_IN statistics", чтобы проверить, срабатывает ли правило? Может, какая-то часть твоего правила в GUI отличается от правила в CLI?

mumbles202

Guest

06.06.2019 20:39:00

Есть какая-то причина, почему правила файрвола, созданные в GUI для дополнительных IP-адресов, не работают? Как только я внес их обратно в json-файл, все заработало нормально.

@UBNT-jaffe

Может, ты можешь подключиться?

mumbles202

Guest

05.06.2019 15:52:00

Думаю, я с этим разобрался. Разделил на NAT и подтвердил, что эти изменения есть в текущей конфигурации на USG. Потом попробовал добавить правила фаервола через графический интерфейс — они вроде бы появились, но не работали (я видел пакеты на WAN-интерфейсе через tcpdump, но они так и не прошли на LAN). Вернулся и заново добавил секцию фаервола в json-файл — и теперь всё работает. По крайней мере, для одного из серверов, сейчас тестирую остальные.

mumbles202

Guest

04.06.2019 21:34:00

Это тоже можно сделать с использованием диапазона? Я настраиваю другой файрвол и мне нужно пробросить UDP порты с 10020 по 10500 снаружи на один IP, а другой диапазон — на другой IP. Хотелось бы задать правило, похожее на это: "description": "NEC Voice Public Ports", "destination": {"address": "AA.BB.CC.44", "port": "10020-10532"}. Файл config.gateway.json проходит проверку, но при применении правило просто зависает.

mumbles202 Guest	#7 10.04.2019 23:02:00 Спасибо. Да, я собирался делать правила фаервола через графический интерфейс, просто копируя правила из config.boot, а не выкладывать скриншот.

UI-Team

Guest

10.04.2019 22:06:00

Правила NAT выглядят нормально, всегда можно проверить, срабатывают ли они во время тестирования, командой: show nat statistics. Правило в файерволе должно быть в графическом интерфейсе, я бы просто оставил все состояния неотмеченными (это подразумевает любой статус). Доступ с LAN к гостевой сети разрешён через правило Allow All в LAN_IN. В LAN_OUT тоже есть правило по умолчанию, разрешающее всё.

mumbles202

Guest

10.04.2019 20:27:00

Ага, понятно по обоим пунктам. Значит, если я хочу разрешить всем сетям доступ к A.B.C.120 по публичному IP, а реальный IP — 10.10.10.120 (я собираюсь заменить своё текущее NAT с WAN на LAN этим правилом), то конфигурация будет такой:
{"service": {"nat": {"rule": {"2": {"description": "Inbound Web Redirect","destination": {"address": "A.B.C.120","port": "443"},"inbound-interface": "eth+","inside-address": {"address": "10.10.10.120","port": "443"},"log": "disable","protocol": "tcp","type": "destination"},"5000": {"description": "Allow 10.10.10.0/24 to 10.10.10.120 Using Public","destination": {"address": "10.10.10.120","port": "443"},"log": "disable","outbound-interface": "eth1","protocol": "tcp","source": {"address": "10.10.10.0/24"},"type": "masquerade"}}}}}

И для гостевой сети на eth0.20 нужно правило примерно такого вида:
name GUEST_IN {
rule 2001 {
action accept
description WebServer
destination WebServer
group {
address-group adfadfafad
port-group aefdafdaf
}
log enable
protocol tcp
state {
established enable
invalid disable
new enable
related disable
}
}
}

Подключения с LAN в GuestNetwork (обратный трафик) будут разрешены по умолчанию или мне нужно будет добавить ещё правила LAN_OUT?

UI-Team

Guest

#10

10.04.2019 19:58:00

Для hairpin NAT параметр «inbound-interface» должен соответствовать интерфейсу, к которому относится исходящий клиент. Например, если у вас LAN в сети 10.10.10.0/24 на eth1, то правило №2 выглядит правильно. Но если 10.10.10.0/24 находится на eth1.10 (vlan 10), тогда inbound interface должен быть eth1.10. Можно также использовать eth+ для «всех» ethernet-интерфейсов, если хотите, чтобы hairpin работал на всех LAN/VLAN. Для гостей действительно понадобится разрешающее правило на GUEST_IN к post-natted (внутреннему адресу) целевого устройства.

Я не совсем понимаю, зачем у вас правило 5000 и почему нужна эта маскарадинг-правила, не могли бы вы пояснить логику их создания? Единственная причина, по которой нужен masquerade/source NAT для hairpin NAT — если исходящий клиент и целевой клиент находятся в одной подсети. То есть, если вы инициируете соединение с 10.17.1.100 и хотите получить доступ к A.B.C.120 через порт 443, и у вас есть DNAT правило, которое переводит A.B.C.120 в 10.17.1.164, то здесь возникает проблема: когда 10.17.1.164 получает пакет, он отвечает напрямую 10.17.1.100 и *не* возвращается через USG, потому что он может напрямую запросить ARP для этого IP на канальном уровне. Это называется асимметричной маршрутизацией.

mumbles202 Guest	#11 10.04.2019 19:34:00 Это возможно выполнить?

mumbles202 Guest	#12 10.04.2019 13:53:00 Быстрый вопрос (надеюсь, простой): мне нужно настроить hairpinning, и пока я вижу, как это делается на устройстве Edgemax (и, вроде, понимаю, как заставить это работать по примеру из справочного документа), но а будет ли это работать, если исходные и целевые сети разные? У меня NAT нормально работает с WAN на LAN; с LAN, если я пытаюсь зайти на https://myserver.com, всё корректно редиректится на внутренний адрес благодаря DNS. Но если я пытаюсь зайти на сервер через его публичный адрес A.B.C.120 с LAN (10.10.10.0/24), меня кидает на страницу администратора USG. Думаю, документация по hairpinning для EdgeMax должна это покрывать — с этим вроде всё ясно. А если у меня есть гостевая LAN на eth1.20, которой тоже нужен доступ к A.B.C.120, достаточно ли будет просто прописать в источнике адрес подсети гостевой LAN и создать правило GUEST_IN, чтобы разрешить доступ к 10.10.10.120 (приватный сервер)? То есть что-то вроде этого: {"service": {"nat": {"rule": {"2": {"destination": {"address": "A.B.C.120","port": "443"},"inbound-interface": "eth1","inside-address": {"address": "10.17.1.164","port": "443"},"log": "disable","protocol": "tcp","type": "destination"},"5000": {"destination": {"address": "10.10.10.20","port": "443"},"log": "disable","outbound-interface": "eth1","protocol": "tcp","source": {"address": "172.20.27.0/24"},"type": "masquerade"}}}}}

Читают тему (гостей: 1)