Jump to content
  • 18
KorDen

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

Question

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

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

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

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

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

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

Share this post


Link to post
Share on other sites

48 answers to this question

  • 0

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

Отключаете 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.

  • Thanks 3

Share this post


Link to post
Share on other sites
  • 1
22 часа назад, dexter сказал:

Радость была не долгой.

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

После введения: 


ip static Home ISP
ip static Vlan101 ISP

пропадают правила проброса портов и соответственно проброс не работает(затерлись).

Если прописать старой командой: 


ip nat Home
ip nat Vlan101

правила появляются вновь(если их повторно добавить в вэб морде).

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

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

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

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

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

Share this post


Link to post
Share on other sites
  • 0

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

Share this post


Link to post
Share on other sites
  • 0

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

Share this post


Link to post
Share on other sites
  • 0

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

Share this post


Link to post
Share on other sites
  • 0

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

Share this post


Link to post
Share on other sites
  • 0

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

Share this post


Link to post
Share on other sites
  • 0

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

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

 

Что то вроде

ip nat out ISP

 

Share this post


Link to post
Share on other sites
  • 0

Ну вот пока такой костыль который не 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

 

Share this post


Link to post
Share on other sites
  • 0
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 by KorDen

Share this post


Link to post
Share on other sites
  • 0

YAY! 2.09.A.4.0-1:

Цитата

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

 

Share this post


Link to post
Share on other sites
  • 0

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

Share this post


Link to post
Share on other sites
  • 0
6 минут назад, r13 сказал:

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

Пожалуйста :)

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

Share this post


Link to post
Share on other sites
  • 0

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

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

Если мы задействует этот механизм, то например если у у нас локалка, гостевая сеть, приватный туннель и выход через 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 что пользоваться ими без понимания не надо.

 

  • Thanks 1

Share this post


Link to post
Share on other sites
  • 0
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 у нас вообще нет ;(

Share this post


Link to post
Share on other sites
  • 0

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

Share this post


Link to post
Share on other sites
  • 0
Только что, KorDen сказал:

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

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

Share this post


Link to post
Share on other sites
  • 0

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

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

Share this post


Link to post
Share on other sites
  • 0

Еще вопрос: Если к примеру есть домашняя сеть 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 by KorDen

Share this post


Link to post
Share on other sites
  • 0
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 то его срежет фильтр.

Share this post


Link to post
Share on other sites
  • 0
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 by KorDen

Share this post


Link to post
Share on other sites
  • 0
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.

 

 

Share this post


Link to post
Share on other sites
  • 0
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 by gaaronk

Share this post


Link to post
Share on other sites
  • 0

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

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

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

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

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

ip static Home ISP

 

Edited by dexter

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.

  • Recently Browsing   0 members

    No registered users viewing this page.

×