Перейти к содержимому
Калькуляторы
А как у вас?  

30 пользователей проголосовало

  1. 1. NAT NAT NAT

    • Алиасы на интерфейсах натника
      11
    • 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, как самый незатратный по ресурсам, хотя тоже спорно, непонятно в каком случае прилетать будет лишних пакетов на адреса пула.

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

Изменено пользователем [GP]Villi

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

...

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

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

-j SNAT --persistent

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

нравится -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.
Изменено пользователем Умник

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

-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 тоже, я не уверен, но документация заставляет думать иначе.

Изменено пользователем Алексей Андриянов

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.