Classical linux hybrid nat vs full cone nat

Страничка VOIP Инженера

Это скромная попытка поделится с миром жизненным опытом

Типы Network Address Translation (NAT)

В свое время, когда я пытался понять как работают различные типы NAT маршрутизаторов. С одной стороны количество статей на эту тему оказалось крайне мало. С другой стороны, исходя из того что было, понять их было крайне сложно. Попробую написать понятное объяснение с максимумом картинок и минимумом определений. Перевод оригинальной английской терминологии на русский язык резанул по ушам, поэтому решил ее оставить как есть.

Cone NAT

Внутренний адрес (192.168.0.2:2210) проецируются на внешний адрес (1.1.1.2:8801). Любой пакет посланный с 192.168.0.2:2210 будет послан через 1.1.1.2:8801. Любой пакет с внешнего хоста, посланный на адрес 1.1.1.2:8801 будет отправлен на 192.168.0.2:2210

Address-Restricted cone NAT или Restricted cone NAT.

Внутренний адрес (192.168.0.2:2210) проецируются на внешний адрес (1.1.1.2:8801). Любой пакет посланный с 192.168.0.2:2210 будет послан через 1.1.1.2:8801. Пакет с любого порта внешнего хоста, посланный на адрес 1.1.1.2:8801 будет отправлен на 192.168.0.2:2210 только в случае, если 192.168.0.2:2210 предварительно посылал пакет на этот внешний хост.

Port-Restricted cone NAT

Внутренний адрес (192.168.0.2:2210) проецируются на внешний адрес (1.1.1.2:8801). Любой пакет посланный с 192.168.0.2:2210 будет послан через 1.1.1.2:8801. Внешний хост (1.1.1.30:1234) модет послать пакет на 192.168.0.2:2210 через 1.1.1.2:8801 только в случае если ранее 192.168.0.2:2210 слал пакет на 1.1.1.30:1234

Symmetric NAT

Каждый пакет с определенного внутреннего IP адреса:порта на определенный внешний IP адрес:порт будет иметь после трансляции уникальный внешний адрес порт. Соответственно, пакет с одного и того-же внутреннего адреса:порта, но посланный на другой внешний хост или порт после трансляции будет иметь другой внешний адрес-порт. Внешние хосты могут послать обратный пакет только на те хосты:порты откуда они получили пакеты.

Еще одна, часто встречающаяся особенность NAT, так называемый port preservation, такой гибрид Port-Restricted и Symmetric NAT, будет рассмотрен в другой статье.

17 Комментариев к “Типы Network Address Translation (NAT)”

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

Спасибо, особенно за картинки

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

А на предмет картинок. Так вот, вменяемых картинок с объяснением алгоритмов NAT на середину 2008 года в интернете не было.

Немного непонятно, при чем все-таки тут конкретные реализации connttrack? Речь шла о базовых принципах работы. в статья же (к сожалению на буржуйском) рассмотрены эти механизмы, а также сопутствующие проблемы, знание которых и позволяет адекватно понимать «а что такое модули connttrack и для чего нужно их использовать». Или я не прав?
Кстати в статьях есть интересные ссылки на доп ресурсы

Мы вообще о разных вещах говорим. Дело в том, что под connttrack модулями имелись ввиду абсолютно безупречные connttrack модули для VOIP протоколов от циско. Встроенные в IOS и осуществляющие абсолютно корректную трансляцию не только заголовков пакетов, но и тела самого пакета. Если бы то же самое делали остальные производители, то данная статья имела бы чисто академический интерес,
поскольку никаких настроек там нет. IOS достаточно умный, чтобы все исправить самостоятельно.

А когда приходится разбираться с тем, почему после прохода NAT от производителя из Шанхайского подвала, происходит та или иная проблема с VOIP, без моих картинок ой как тоскливо.

Спасибо. полдня читаю про типы NAT уже крыша едет. еще б статью дополнить как протестить какой тип NAT в конкретном случае. Что типа вывода утилитки stun.

Если читаете как пользователь, для вас моя же статейка:
http://aoz.com.ua/2009/02/06/sipovernat/
то есть по простому:
1.Обрубаете __все__ связанное с nat traversal,
если интернет между вами и провайдером нормальный и провайдер правильный.
2. Если интернет иногда уходит в полочку, надо позаботится о sipping с вашей стороны.
3. Если провайдер не правильный идите к нормальному.

Ну а если сами провайдер или админ сети тогда читайте, бог в помощь.

А на предмет stun, забудьте как про страшный сон. Толку от нее, если симметричный nat без помощи провайдера не пробить.

Хорошая статья в картинках
Кому надо — тот конечно и на цискоком посмотрит, но итак всё вроде понятно

Хороший пост, очень понятные и информативные рисунки, довольно доходчиво. Я только начал разбираться с типами NAT-ов и после прочтения поста мне все же не понятно чем Port-Restricted cone NAT отличается от Symmetric NAT. Рисунки иллюстрирующие эти два типа NAT-ов, если я не ошибаюсь, отличаются только красной надписью вверху

При симметричном NAT: Каждый пакет с определенного внутреннего IP адреса:порта на определенный внешний IP адрес:порт будет иметь после трансляции уникальный внешний адрес порт, В отличие от Port Restricted, где все SIP устройства из-за NAT видны с одним и тем же портом.

Если уже по по цветам это синенкая рамочка снизу

Благодарю Вас за то, что не поленились поделиться добытыми знаниями!

Спасибо за внесённую ясность. Особенно за картинки — словами гораздо дольше и туманнее. А по картинке можно сразу рассмотреть варианты и разобрать, что к чему.

Роутер Асус, с кастомной прошивкой от Padavan,
столкнулся с настройкой classical linux hybrid nat в выборе модели НАТ.
Уважаемые, не подскажете — что из себя представляет данный вид модели?

В iptables симметричный NAT с попыткой сохранить порт src клиента (если он свободен)

iptables ето открывание портов для атс а как с оконечниками с ихними дивайсами за натом со своими фаерволами и случей когда нужные порты уже чемто заняты ето целая наука затрагующая всю цепочку начиная с провадера интернета и заканчуя телефонным апаратом и единого решения нет разные дивайсы раздают интернет какие поддерживают одни функции какие другие про dsl -модемы ничего не сказано а ето часто реально прблема со своими фаерволами и качеством про keep-Alive не увидел так что только тиория хотя грамотно,считаю что только в практике абон обслуживания и подключения начинаеш пониать чтотакое нат и как можно его обойти а если нат двойной и пару свичей в сетке да еще и какойто хаб полностью забитый абонами рвет пакеты при передаче что факс уже не отправиш а как правило что ето хаб какойто тупое устройство все портачит подумаеш в последнюю очередь у того торент качает тот в скайпе сидит у того вирусняк какойто у того комп гадит в сетку чемто и в таких условиях абон требует чтобы факсы бегали и качество связи было идеальным потомучто ему обеснили поопулярно что ето цыфра и качество будет клас ни еха тибе ни ободраных фраз атличный дуплекс оба слышат друг друга так что нат пройти бывает надо постараца даище и в обе стороны поетому становишся сетевым спецом широкого профиля чтобы абона подключить зайдеш на роутер порты нужные пробросить а там прошивка 8-летней давности так что и обновить приходится короче по возится а он если че ему говориш нада роутер по соврименей купить а он мне раньше все работало а вы полезли и поломали мне там чета короче весило а мне начальство пришол включил и ушол любой справится наверно чтобы зарплату не подымать за обем который не обсуждался при устройстве на роботу раз 50 ситуации разные происходят начинаеш сразу оприделять что может быть нат фаервол или ище чета так что нат бывает так потра-шся а кажется зашол включил и ушол а включаеш а а порты открыть не выходит ну тоесть ты все сделал как надо везде галочки стоят где надо порты открыты а всерамно однастороняя связь услуга куплиная не полноценная и все проблема типа пришлите мне спеца по компитентней тебя нет два года наты проходиш так что подключив ну там шлюз например напрямую в роутер изернетавский и ето единственое что на роутере висит успешно прходиш нат стандартно и пишиш красивую научно популярную статью как ето делается а на прктике та не так совсем а вариант поиграйся там тем тем ну типа по порамитрам погуляйпоминяй попробуй так тотом так занимает много времени и производит впечетление что чиловек не знае что он делает особенно с приложениями на айфон или андройд я раз так попал с айпадом что только не пробывал голос не ходит и все а оказался нат а ета настройка фиг знает где оказалась в сетевых настройках тольконастройка в настройкеслучайно практически на нее попал тоже с натом связанная я оп поменял моментально все заработало звук голос посли етого зойпер стал моим любимым приложением а все потому что в нем шире придставлины настройки нат есть че выбрать а в сипсемпле например воще ети настройки отсутствуют и ету проблему победить не возможно не чем ну раз нет етих настроек значит и ненадо думаеш а они надо потомушто голс не ходит и регистрацие отваливается периодически не дороботаное приложение простинькое хотя много где работает и в 3Сх нет зойпер самое полное ну конечно можно сехать у вас кодека 729 нет ево надо докупать мы мол придуприждали вася абон плату платит а поговорить не может а ето походу НАТ всего навсиго порты режит кроет верно настроеный нат снимае ети вопросы но он сеть поминяет там может другой вариант работает надо заходить менять если есть на что минять а если нет чувак кодек купил а прблемы ето не решило начинается ваша связь ху—ня верните деньги а ето нат порты вот и все и галимое приложение так что нат для voip имеет решающее значение часто так что на ету тему надо писать обсуждать варианты настроек обговаривать много головных болей пройдет и качество и надежность ай-пи телефонии подымит ну как-то так извените за то что наваял тут дофига просто нужная тема и у меня тоже есть по поводу нат мнение спосибо досвиданье кстати ма с вами знакомы лично так что я знаю чтовы сделали построли целого воип оператора

Источник

Быстрый роутинг и NAT в Linux

Немного истории

Тема исчерпания адресного пространства IPv4 уже не нова. В какой-то момент в RIPE появились очереди ожидания (waiting list), затем возникли биржи, на которых торговали блоками адресов и заключались сделки по их аренде. Постепенно операторы связи начали предоставлять услуги доступа в Интернет с помощью трансляции адресов и портов. Кто-то не успел получить достаточно адресов, чтобы выдать «белый» адрес каждому абоненту, а кто-то начал экономить средства, отказавшись от покупки адресов на вторичном рынке. Производители сетевого оборудования поддержали эту идею, т.к. этот функционал обычно требует дополнительных модулей расширения или лицензий. Например, у Juniper в линейке маршрутизаторов MX (кроме последних MX104 и MX204) выполнять NAPT можно на отдельной сервисной карте MS-MIC, на Cisco ASR1k требуется лицензия СGN license, на Cisco ASR9k — отдельный модуль A9K-ISM-100 и лицензия A9K-CGN-LIC к нему. В общем, удовольствие стоит немалых денег.

IPTables

Задача выполнения NAT не требует специализированных вычислительных ресурсов, ее в состоянии решать процессоры общего назначения, которые установлены, например, в любом домашнем роутере. В масштабах оператора связи эту задачу можно решить используя commodity серверы под управлением FreeBSD (ipfw/pf) или GNU/Linux (iptables). Рассматривать FreeBSD не будем, т.к. я довольно давно отказался от использования этой ОС, так что остановимся на GNU/Linux.

Включить трансляцию адресов совсем не сложно. Для начала необходимо прописать правило в iptables в таблицу nat:

Операционная система загрузит модуль nf_conntrack, который будет следить за всеми активными соединениями и выполнять необходимые преобразования. Тут есть несколько тонкостей. Во-первых, поскольку речь идет о NAT в масштабах оператора связи, то необходимо подкрутить timeout’ы, потому что со значениями по умолчанию размер таблицы трансляций достаточно быстро вырастет до катастрофических значений. Ниже пример настроек, которые я использовал на своих серверах:

И во-вторых, поскольку по умолчанию размер таблицы трансляций не рассчитан на работу в условиях оператора связи, его необходимо увеличить:

Также необходимо увеличить и количество buckets для хэш-таблицы, хранящей все трансляции (это опция модуля nf_conntrack):

После этих нехитрых манипуляций получается вполне работающая конструкция, которая может транслировать большое количество клиентских адресов в пул внешних. Однако, производительность этого решения оставляет желать лучшего. В своих первых попытках использования GNU/Linux для NAT (примерно 2013 год) я смог получить производительность около 7Gbit/s при 0.8Mpps на один сервер (Xeon E5-1650v2). С того времени в сетевом стеке ядра GNU/Linux было сделано много различных оптимизаций, производительность одного сервера на том же железе выросла практически до 18-19 Gbit/s при 1.8-1.9 Mpps (это были предельные значения), но потребность в объеме трафика, обрабатываемого одним сервером, росла намного быстрее. В итоге были выработаны схемы балансировки нагрузки на разные серверы, но всё это увеличило сложность настройки, обслуживания и поддержания качества предоставляемых услуг.

NFTables

Сейчас модным направлением в программном «перекладывании пакетиков» является использование DPDK и XDP. На эту тему написана куча статей, сделано много разных выступлений, появляются коммерческие продукты (например, СКАТ от VasExperts). Но в условиях ограниченных ресурсов программистов у операторов связи, пилить самостоятельно какое-нибудь «поделие» на базе этих фреймворков довольно проблематично. Эксплуатировать такое решение в дальнейшем будет намного сложнее, в частности, придется разрабатывать инструменты диагностики. Например, штатный tcpdump с DPDK просто так не заработает, да и пакеты, отправленные назад в провода с помощью XDP, он не «увидит». На фоне всех разговоров про новые технологии вывода форвардинга пакетов в user-space, незамеченными остались доклады и статьи Pablo Neira Ayuso, меинтейнера iptables, про разработку flow offloading в nftables. Давайте рассмотрим этот механизм подробнее.

Основная идея заключается в том, что если роутер пропустил пакеты одной сессии в обе стороны потока (TCP сессия перешла в состояние ESTABLISHED), то нет необходимости пропускать последующие пакеты этой сессии через все правила firewall, т.к. все эти проверки всё равно закончатся передачей пакета далее в роутинг. Да и собственно выбор маршрута выполнять не надо — мы уже знаем в какой интерфейс и какому хосту надо переслать пакеты пределах этой сессии. Остается только сохранить эту информацию и использовать ее для маршрутизации на ранней стадии обработки пакета. При выполнении NAT необходимо дополнительно сохранить информацию об изменениях адресов и портов, преобразованных модулем nf_conntrack. Да, конечно, в этом случае перестают работать различные полисеры и другие информационно-статистические правила в iptables, но в рамках задачи отдельного стоящего NAT или, например, бордера — это не так уж важно, потому что сервисы распределены по устройствам.

Конфигурация

Чтобы воспользоваться этой функцией нам надо:

• Использовать свежее ядро. Несмотря на то, что сам функционал появился еще в ядре 4.16, довольно долго он было очень «сырой» и регулярно вызывал kernel panic. Стабилизировалось всё примерно в декабре 2019 года, когда вышли LTS ядра 4.19.90 и 5.4.5.
• Переписать правила iptables в формат nftables, используя достаточно свежую версию nftables. Точно работает в версии 0.9.0

Если с первым пунктом всё в принципе понятно, главное не забыть включить модуль в конфигурацию при сборке (CONFIG_NFT_FLOW_OFFLOAD=m), то второй пункт требует пояснений. Правила nftables описываются совсем не так, как в iptables. Документация раскрывает практически все моменты, также есть специальные конверторы правил из iptables в nftables. Поэтому я приведу только пример настройки NAT и flow offload. Небольшая легенда для примера: , — это сетевые интерфейсы, через которые проходит трафик, реально их может быть больше двух.

— начальный и конечный адрес диапазона «белых» адресов.

Конфигурация NAT очень проста:

С flow offload немного сложнее, но вполне понятно:

Вот, собственно, и вся настройка. Теперь весь TCP/UDP трафик будет попадать в таблицу fastnat и обрабатываться намного быстрее.

Результаты

Чтобы стало понятно, насколько это «намного быстрее», я приложу скриншот нагрузки на два реальных сервера, с одинаковой начинкой (Xeon E5-1650v2), одинаково настроенных, использующих одно и тоже ядро Linux, но выполняющих NAT в iptables (NAT4) и в nftables (NAT5).

На скриншоте нет графика пакетов в секунду, но в профиле нагрузки этих серверов средний размер пакета в районе 800 байт, поэтому значения доходят до 1.5Mpps. Как видно, запас производительности у сервера с nftables огромный. На текущий момент этот сервер обрабатывает до 30Gbit/s при 3Mpps и явно способен упереться в физическое ограничение сети 40Gbps, имея при этом свободные ресурсы CPU.

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

Источник