Jump to content
Официальное хранилище ПО в виде файлов
  • 19

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

KorDen

Asked by KorDen,

 Share

Question

KorDen Honored Flooder

KorDen

Posted
Posted

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

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

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

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

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

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

Link to comment
Share on other sites

48 answers to this question

Recommended Posts

  • 0
Le ecureuil Honored Flooder

Le ecureuil

Posted
Posted

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

Отключаете 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
Link to comment
Share on other sites
  • 1
Le ecureuil Honored Flooder

Le ecureuil

Posted
Posted
22 часа назад, dexter сказал:

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

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

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


ip static Home ISP
ip static Vlan101 ISP

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

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


ip nat Home
ip nat Vlan101

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

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

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

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

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

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

Link to comment
Share on other sites
  • 0
dexter Honored Flooder

dexter

Posted
Posted

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

Link to comment
Share on other sites
  • 0
gaaronk Content Generator

gaaronk

Posted
Posted

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

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

 

Что то вроде

ip nat out ISP

 

Link to comment
Share on other sites
  • 0
gaaronk Content Generator

gaaronk

Posted
Posted

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

 

Link to comment
Share on other sites
  • 0
KorDen Honored Flooder

KorDen

Posted
  • Author
Posted (edited)
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
Link to comment
Share on other sites
  • 0
r13 Honored Flooder

r13

Posted
Posted

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

Link to comment
Share on other sites
  • 0
Le ecureuil Honored Flooder

Le ecureuil

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

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

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

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

Link to comment
Share on other sites
  • 0
gaaronk Content Generator

gaaronk

Posted
Posted

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

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

Если мы задействует этот механизм, то например если у у нас локалка, гостевая сеть, приватный туннель и выход через 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
Link to comment
Share on other sites
  • 0
Le ecureuil Honored Flooder

Le ecureuil

Posted
Posted
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 у нас вообще нет ;(

Link to comment
Share on other sites
  • 0
Le ecureuil Honored Flooder

Le ecureuil

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

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

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

Link to comment
Share on other sites
  • 0
gaaronk Content Generator

gaaronk

Posted
Posted

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

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

Link to comment
Share on other sites
  • 0
KorDen Honored Flooder

KorDen

Posted
  • Author
Posted (edited)

Еще вопрос: Если к примеру есть домашняя сеть 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
Link to comment
Share on other sites
  • 0
gaaronk Content Generator

gaaronk

Posted
Posted
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 то его срежет фильтр.

Link to comment
Share on other sites
  • 0
KorDen Honored Flooder

KorDen

Posted
  • Author
Posted (edited)
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
Link to comment
Share on other sites
  • 0
gaaronk Content Generator

gaaronk

Posted
Posted
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.

 

 

Link to comment
Share on other sites
  • 0
gaaronk Content Generator

gaaronk

Posted
Posted (edited)
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
Link to comment
Share on other sites
  • 0
dexter Honored Flooder

dexter

Posted
Posted (edited)

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

Поддержу вопрос 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
Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to question listing

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...