Выборочное отключение NAT без статического IP

KorDen · January 11, 2017

Вопрос, который давно уже поднимался, но лично для меня встал острее с появлением туннелей.

На текущий момент единственный вариант не натировать сеть через туннель - отключить ip nat полностью, воспользовавшись ip static, однако он требует наличия статического IP - https://zyxel.ru/kb/3252/

По вполне очевидным причинам во многих случаях этот вариант совсем не приемлем (разве что играться со скриптами в entware).

Варианты реализации с точки зрения пользователя, на мой взгляд:

- в ip nat добавить опциональный исходящий интерфейс, описывая таким образом что натить, а что нет (скажем, натить Home->ISP, Guest ->ISP, IPIP0->ISP, но не натить IPIP<->Home)

- в ip static добавить возможность указания исходящего интерфейса, чтобы автоматически брался IP с этого интерфейса

Le ecureuil · March 14, 2017

Можете тестировать.

Отключаете nat на интерфейсе, пакеты с которого не нужно nat-ить (предположим это Home)

> no ip nat Home

Включаем nat на исходящих интерфейсах, пакеты уходящие в которые нужно nat-ить (предположим это ISP и PPTP0):

> ip static Home ISP

> ip static Home PPTP0

Все остальные пакеты из Home в другие интерфейсы пойдут без NAT (например, в EoIP0, L2TP0, etc).

Чтобы правильно работал ip static исходящие интерфейсы (ISP, PPTP0) обязательно должны иметь security-level public.

Le ecureuil · March 15, 2017

22 часа назад, dexter сказал:
Радость была не долгой.

Отловился первый глюк.

После введения:
ip static Home ISP
ip static Vlan101 ISP
пропадают правила проброса портов и соответственно проброс не работает(затерлись).

Если прописать старой командой:
ip nat Home
ip nat Vlan101
правила появляются вновь(если их повторно добавить в вэб морде).

Пока вернул как было.

Если нужна какая информация скину в кратчайшие сроки.

Web ничего не знает о новой команде, и затирает ее полностью (как и любую другую команду ip static, не относящуюся к пробросу портов).

Потому если хотите выключения nat индивидуально по сегментам - настраивайте проброс портов через ip static тоже только в CLI.

Больше проблем не замечено.

IgaX · January 11, 2017

согласен, а-ля Cisco NAT exemption и заодно Policy NAT (e.g.) было бы неплохо для гибкости

dexter · January 11, 2017

Поддержу тему. У самого есть и туннель и сегменты. Не очень удобно когда нет чистой маршрутизации, а все что прилетает через кинетик имеет его IP.

r13 · January 11, 2017

Ну и я поддержу

T@rkus · January 12, 2017

Поддерживаю

Edited January 12, 2017 by T@rkus

Le ecureuil · January 12, 2017

Есть идеи на этот счет, записали в список, ожидайте

dexter · January 12, 2017

О, это гуд. Записался в тестировщики.

avkuzmin · January 22, 2017

Давно об этом техподдержку просил, буду рад, если всё же реализуете.

awoland · February 21, 2017

Присоединяюсь к страждущим ...

drugold · February 22, 2017

Поддержу запрос.

gaaronk · March 9, 2017

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

Или как вариант в CLI разрешить использовать обычную, а не инверсную логику NAT - делать на выходе из интерфейса

Что то вроде

ip nat out ISP

gaaronk · March 9, 2017

Ну вот пока такой костыль который не NATит в сторону gre (мой частный случай) тоннелей и NATит трафик из туннелей на выходе из public интерфейсов

#!/bin/sh

[ "$table" != "nat" ] && exit 0

/opt/sbin/iptables -t nat -A _NDM_IPSEC_POSTROUTING_NAT -o ngre+ -j ACCEPT
/opt/sbin/iptables -t nat -A _NDM_STATIC_SNAT -i ngre+ -p udp -j _NDM_NAT_UDP
/opt/sbin/iptables -t nat -A _NDM_STATIC_SNAT -i ngre+ -j MASQUERADE

KorDen · March 9, 2017

1 час назад, gaaronk сказал:

ip nat out ISP

Я бы все же хотел иметь возможность сделать что-то вроде "ip nat from Home to ISP" с возможностью сделать условно "ip nat from all to ISP" или "ip nat from Guest to all" (запахло IPFW )

Пока же проще, если на каком-то интерфейсе динамический IP, скриптом добавлять ip static для нынешнего IP

Edited March 9, 2017 by KorDen

KorDen · March 13, 2017

YAY! 2.09.A.4.0-1:

Цитата

добавлена поддержка to-interface в команде ip static по аналогии с IP-адресом назначения

Le ecureuil · March 14, 2017

@KorDen @IgaX @dexter @avkuzmin

Le ecureuil · March 14, 2017

@gaaronk @drugold @awoland

r13 · March 14, 2017

@Le ecureuil Спасибо за разъяснения, а то начал пробовать без отключения nat на интерфейсе( думал новая команда наоборот работает, а так еще лучше!)

Le ecureuil · March 14, 2017

6 минут назад, r13 сказал:

@Le ecureuil Спасибо за разъяснения, а то начал пробовать без отключения nat на интерфейсе( думал новая команда наоборот работает, а так еще лучше!)

Пожалуйста

Все непонятки описывайте здесь, возможно что-то работает не совсем корректно или не учтено

gaaronk · March 14, 2017

Отлично, спасибо!

Вопрос ради интереса на логику.

Если мы задействует этот механизм, то например если у у нас локалка, гостевая сеть, приватный туннель и выход через ISP в MAN и PPPoE в WAN, то нам надо написать такие правила

ip static Home ISP

ip static Home PPPoE

ip static Guest ISP

ip static Guest PPPoE

ip static Gre0 ISP

ip static Gre0 PPPoE

По сути полную матрицу, если что то не опишем - в сторону провайдера уйдут не транслированные адреса, что некрасиво.

Вариант "ip static out <WAN_INT>" подразумевает что то вроде

-A POSTROUTING ! -s <WAN_IP>/32 -o <WAN_INTERFACE> -j MASQUERADE

В этом случае на выход через этот интерфейс (на котором от нас ожидается только трафик от выданного нам IP) мы всегда идем с правильным source IP.

Или такой механизм затратнее чем матчить по source интерфейсу? Ну а команды в CLI на то и даны только в CLI что пользоваться ими без понимания не надо.

Le ecureuil · March 14, 2017

1 час назад, gaaronk сказал:

Отлично, спасибо!

Вопрос ради интереса на логику.

Если мы задействует этот механизм, то например если у у нас локалка, гостевая сеть, приватный туннель и выход через ISP в MAN и PPPoE в WAN, то нам надо написать такие правила

ip static Home ISP

ip static Home PPPoE

ip static Guest ISP

ip static Guest PPPoE

ip static Gre0 ISP

ip static Gre0 PPPoE

По сути полную матрицу, если что то не опишем - в сторону провайдера уйдут не транслированные адреса, что некрасиво.

Вариант "ip static out <WAN_INT>" подразумевает что то вроде

-A POSTROUTING ! -s <WAN_IP>/32 -o <WAN_INTERFACE> -j MASQUERADE

В этом случае на выход через этот интерфейс (на котором от нас ожидается только трафик от выданного нам IP) мы всегда идем с правильным source IP.

Или такой механизм затратнее чем матчить по source интерфейсу? Ну а команды в CLI на то и даны только в CLI что пользоваться ими без понимания не надо.

Сейчас у нас главное - это обратная совместимость.

Да, возможно решение неидеальное и требует особого внимания со стороны настраивающего, но это самое простое что можно было реализовать с сохранением прямой совместимости команд и всех инструкций в базе знаний.

ip static out у нас вообще нет ;(

KorDen · March 14, 2017

@Le ecureuil, для клиентов PPTP-сервера (при 'ip nat vpn') как пойдут пакеты в случае перехода на статику?

Le ecureuil · March 14, 2017

Только что, KorDen сказал:

@Le ecureuil, для клиентов PPTP-сервера (при 'ip nat vpn') как пойдут пакеты в случае перехода на статику?

Остается полностью прошлое поведение. Если включен nat - будет с ним, если выключен - будет без него.

gaaronk · March 14, 2017

В любом случае спасибо и за такую реализацию. Я прекрасно понимаю как важна обратная совместимость и стабильность взаимодействия с остальными компонентами.

Я просто порассуждал на тему логики работы NAT. Возможно это будет интересно и вам (в будущем).

KorDen · March 14, 2017

Еще вопрос: Если к примеру есть домашняя сеть 192.168.0.1/24, гостевая (.1.1/24), и два туннеля (за ними .2.1/24 и .3.1/24) (выход через ISP и резерв на LTE) - правильно ли понимаю, что вместо описывания "матрицы интерфейсов" можно сделать что-то вроде:

ip static 192.168.0.0/22 ISP
ip static 192.168.0.0/22 UsbLte0

Или в таком виде могут быть скрытые сюрпризы, если например со стороны ISP вдруг прилетит пакет с IP из этого диапазона?

Edited March 14, 2017 by KorDen

gaaronk · March 14, 2017

25 minutes ago, KorDen said:

Еще вопрос: Если к примеру есть домашняя сеть 192.168.0.1/24, гостевая (.1.1/24), и два туннеля (за ними .2.1/24 и .3.1/24) (выход через ISP и резерв на LTE) - правильно ли понимаю, что вместо описывания "матрицы интерфейсов" можно сделать что-то вроде:

ip static 192.168.0.0/22 ISP
ip static 192.168.0.0/22 UsbLte0

Или в таком виде могут быть скрытые сюрпризы, если например со стороны ISP вдруг прилетит пакет с IP из этого диапазона?

Если такой пакет прилетит от ISP то его срежет фильтр.

KorDen · March 14, 2017

13 минуты назад, gaaronk сказал:

Если такой пакет прилетит от ISP то его срежет фильтр.

А если прилетит на открытый порт? Например: 192.168.2.1/24 - маршрутизируется через туннель, со стороны ISP разрешен доступ, скажем, к порту udp/12345, из-за неполадок у ISP дефолтный маршрут через LTE, прилетает пакет со 192.168.2.3 со стороны ISP на myip:12345 - не уйдет ли вдруг на LTE с моим же внешним IP ISP или через Nat Loopback прилетит на сервис на 12345, но с IP роутера, а не с реальным?

Понятно, что ответ никуда не уйдет..

Edited March 14, 2017 by KorDen

gaaronk · March 14, 2017

3 minutes ago, KorDen said:

А если прилетит на открытый порт? Например: 192.168.2.1/24 - маршрутизируется через туннель, со стороны ISP разрешен доступ, скажем, к порту udp/12345 (но сервис не запущен), из-за неполадок у ISP дефолтный маршрут через LTE, прилетает пакет со 192.168.2.3 со стороны ISP на myip:12345 - не уйдет ли вдруг на LTE с моим же внешним IP ISP или что подобное?

Нет конечно. Раз прилетает на IP рутера, то в FORWARD оно не попадет и НЕ будет маршрутизироваться. Рутер ответит скорее всего icmp unreachable.

gaaronk · March 14, 2017

14 minutes ago, KorDen said:

А если прилетит на открытый порт? Например: 192.168.2.1/24 - маршрутизируется через туннель, со стороны ISP разрешен доступ, скажем, к порту udp/12345 (но сервис не запущен), из-за неполадок у ISP дефолтный маршрут через LTE, прилетает пакет со 192.168.2.3 со стороны ISP на myip:12345 - не уйдет ли вдруг на LTE с моим же внешним IP ISP или что подобное?

Поясню немного свою позицию. NAT не является средством контроля и безопасности. Использовать его для этого - опасно. Это всего лишь правила по которым меняются source и/или destination адреса/порты у пакетов в зависимости от кого/кому предназначен пакет, через какой интерфейс он входит/выходит.

Контролировать доступ, кто куда может ходить, по каким портам и адресам - надо в filter.

Если пакет предназначен адресу вашего рутера он обработается в цепочке INPUT, если он транзитный то в FORWARD. Вот там и контролируйте. По умолчанию в кинетике пакет нового соединения не будет маршрутизироваться если он пришел из public интерфейса, то есть ваш рутер при нескольких провайдерах не будет транзитным.

Транзит разрешен от private - ко всем и и от protected к public

Edited March 14, 2017 by gaaronk

dexter · March 14, 2017

Проверил, все работает спасибо.

Поддержу вопрос KorDen

4 часа назад, KorDen сказал:

ip static 192.168.0.0/22 ISP
ip static 192.168.0.0/22 UsbLte0

Или можно только по имени интерфейса?

ip static Home ISP

Edited March 14, 2017 by dexter

Sign In

Выборочное отключение NAT без статического IP

Question

48 answers to this question

Recommended Posts

Recently Browsing 0 members