Перейти к содержанию
Официальное хранилище ПО в виде файлов
  • 19

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

KorDen

Ответ от KorDen,

 Поделиться

Вопрос

KorDen Старожил

KorDen

Опубликовано
Опубликовано

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

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

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

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

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

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

48 ответов на этот вопрос

Рекомендуемые сообщения

  • 0
Le ecureuil Старожил

Le ecureuil

Опубликовано
Опубликовано

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

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

  • Спасибо 3
  • 1
Le ecureuil Старожил

Le ecureuil

Опубликовано
Опубликовано
22 часа назад, dexter сказал:

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

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

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


ip static Home ISP
ip static Vlan101 ISP

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

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


ip nat Home
ip nat Vlan101

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

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

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

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

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

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

  • 0
dexter Старожил

dexter

Опубликовано
Опубликовано

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

  • 0
gaaronk Поставщик контента

gaaronk

Опубликовано
Опубликовано

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

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

 

Что то вроде

ip nat out ISP

 

  • 0
gaaronk Поставщик контента

gaaronk

Опубликовано
Опубликовано

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

 

  • 0
KorDen Старожил

KorDen

Опубликовано
  • Автор
Опубликовано (изменено)
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

Изменено пользователем KorDen
  • 0
KorDen Старожил

KorDen

Опубликовано
  • Автор
Опубликовано

YAY! 2.09.A.4.0-1:

Цитата

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

 

  • 0
r13 Старожил

r13

Опубликовано
Опубликовано

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

  • 0
Le ecureuil Старожил

Le ecureuil

Опубликовано
Опубликовано
6 минут назад, r13 сказал:

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

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

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

  • 0
gaaronk Поставщик контента

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 что пользоваться ими без понимания не надо.

 

  • Спасибо 1
  • 0
Le ecureuil Старожил

Le ecureuil

Опубликовано
Опубликовано
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 у нас вообще нет ;(

  • 0
Le ecureuil Старожил

Le ecureuil

Опубликовано
Опубликовано
Только что, KorDen сказал:

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

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

  • 0
gaaronk Поставщик контента

gaaronk

Опубликовано
Опубликовано

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

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

  • 0
KorDen Старожил

KorDen

Опубликовано
  • Автор
Опубликовано (изменено)

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

Изменено пользователем KorDen
  • 0
gaaronk Поставщик контента

gaaronk

Опубликовано
Опубликовано
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 то его срежет фильтр.

  • 0
KorDen Старожил

KorDen

Опубликовано
  • Автор
Опубликовано (изменено)
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 роутера, а не с реальным?

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

Изменено пользователем KorDen
  • 0
gaaronk Поставщик контента

gaaronk

Опубликовано
Опубликовано
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.

 

 

  • 0
gaaronk Поставщик контента

gaaronk

Опубликовано
Опубликовано (изменено)
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

Изменено пользователем gaaronk
  • 0
dexter Старожил

dexter

Опубликовано
Опубликовано (изменено)

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

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

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

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

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

ip static Home ISP

 

Изменено пользователем dexter
Гость
Эта тема закрыта для публикации ответов.
 Поделиться
Перейти к списку вопросов

  • Последние посетители   0 пользователей онлайн

    • Ни одного зарегистрированного пользователя не просматривает данную страницу
×
×
  • Создать...

Важная информация

На этом сайте используются файлы cookie. Нажимая "Я принимаю" или продолжая просмотр сайта, вы разрешаете их использование: Политика конфиденциальности.

  Я принимаю