Jump to content
Калькуляторы
А как у вас?  

29 members have voted

  1. 1. NAT NAT NAT

    • Алиасы на интерфейсах натника
      10
    • Blackhole всего что не принадлежит трансляциям
      13
    • Reject всего что не принадлежит трансляциям
      3
    • Что-то другое
      10


Как правильно NATить?

Собственно созрел вопрос при NAT некоторого количества пользователей.

То что на NAT надо вешать пул я надеюсь ни у кого вопросов не вызывает, т.к. речь идет не об одном-двух пользователях, а о тысячах и более. Хотя если есть возражения готов их выслушать :)

 

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

 

1) Повесить весь пул алиасами на какой либо интерфейс того устройства где происходит NAT.

Результат:

Порождает кучу ICMP Port unreachable и видимо еще TCP RST. Плюс скорее всего эти IP-шники будут сканить, и если есть сервисы слушающие на всех адресах то совсем не супер.

 

2)Сделать route blackhole.

Результат:

Вроде бы сплошные плюсы, ресурсов машины не жрет. Единственное что адреса из пула для всего остального интернета "умирают", не очень понятно минус это или нет.

 

3)Сделать route reject.

Результат:

Кроме ICMP Destination unreachable ничего не порождает, но тоже не в малом количестве. Адреса из пула даже непонятно какими в таком случае считать, живыми или мертвыми.

 

 

Напрашивается вариант с blackhole, как самый незатратный по ресурсам, хотя тоже спорно, непонятно в каком случае прилетать будет лишних пакетов на адреса пула.

Любые аргументы и другие варианты приветствуются )

Edited by [GP]Villi

Share this post


Link to post
Share on other sites

Получить белых адресов и отказаться от нат?:)

Share this post


Link to post
Share on other sites
Получить белых адресов и отказаться от нат?:)

Это путь криворуких ламеров. :-)

Share this post


Link to post
Share on other sites

Используем route blackhole.

PS. Отдельная тема, как правильно размазывать пользователей по пулу нат адресов.

Share this post


Link to post
Share on other sites
Получить белых адресов и отказаться от нат?:)

Это путь криворуких ламеров. :-)

+1, больше добавить нечего :)

Share this post


Link to post
Share on other sites

Хотелось бы увидеть комментарии тех кто выбрал 'что-то другое', интересно что. Ну и вообще какие либо существенные комментарии за и против.

 

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

Share this post


Link to post
Share on other sites

...

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

Я вот столкнулся с проблеммой в OS LINUX при использовании SNAT Range.

Каждая новая сессия уходит с нового ip из nat range. Т.о. такие ресурсы, как ICQ или видео VKONTAKTE, перестали корректно работать. По этому нужно чтобы одному Fake IP соответствовал один Real IP из пула.

 

Share this post


Link to post
Share on other sites

По этому нужно чтобы одному Fake IP соответствовал один Real IP из пула.

-j SNAT --persistent

Share this post


Link to post
Share on other sites
По этому нужно чтобы одному Fake IP соответствовал один Real IP из пула.
-j SNAT --persistent

Верно - это я и подразумевал, когда говорил "правильно размазывать пользователей по пулу нат адресов".

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

[GP]Villi, речь конечно же идет не о каждом пакете, а о каждой новой паре "src IP, dst IP".

 

Share this post


Link to post
Share on other sites
-j SNAT --persistent
Мне куда больше нравится -j NETMAP. Оно гарантирует, что и через неделю у клиента будет тот же самый внешний адрес.

 

А --persistent, насколько я понимаю - только до исчезновения из conntrack-таблицы последнего соединения этого клиента.

Share this post


Link to post
Share on other sites
нравится -j NETMAP
-j NETMAP подразумевает трансляцию двух диапазанов одного и того же размера (например 5.5.5.0/24 -> 6.6.6.0/24) с сохранением изменяемых октетов, то есть 1 к 1.

 

А --persistent, насколько я понимаю - только до исчезновения из conntrack-таблицы последнего соединения этого клиента.
Нет. --persistent заставляет netfilter игнорировать dst-адрес при расчете хеша для выбора IP-адреса из SNAT-пула. Таким образом клиент всегда выходит с одним и тем же src IP.
Edited by Умник

Share this post


Link to post
Share on other sites
-j NETMAP подразумевает трансляцию двух диапазанов одного и того же размера (например 5.5.5.0/24 -> 6.6.6.0/24) с сохранением изменяемых октетов, то есть 1 к 1.
Нет. У меня все работает через правило -A POSTROUTING -j NETMAP -s 10.0.0.0/8 --to x.x.x.x/27

В man сказано, что в случае различия длины -s и --to- сетей IP выбирается из пула по маске в to-сети:

The resulting address will be constructed in the following way: All ’one’ bits in the mask are filled in from the new ‘address’. All bits that are zero in the mask are filled in from the original address.
А --persistent, насколько я понимаю - только до исчезновения из conntrack-таблицы последнего соединения этого клиента.
Нет. --persistent заставляет netfilter игнорировать dst-адрес при расчете хеша для выбора IP-адреса из SNAT-пула. Таким образом клиент всегда выходит с одним и тем же src IP.

А man говорит, что SNAT не расчитывает хеш для выбора IP из пула, а использует round-robin-алгоритм для простого перебора IP из пула.

А способ, который вы описали, характерен как раз-таки для NETMAP. Может, и для --persistent тоже, я не уверен, но документация заставляет думать иначе.

Edited by Алексей Андриянов

Share this post


Link to post
Share on other sites

но документация заставляет думать иначе.

Видимо она устарела. --persistent появился не так давно. А NETMAP все-таки лучше подходит для 1:1 трансляций, SNAT как-то роднее.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this