Типы 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
Full cone nat
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 адрес:порт будет иметь после трансляции уникальный внешний адрес порт. Соответственно, пакет с одного и того-же внутреннего адреса:порта, но посланный на другой внешний хост или порт после трансляции будет иметь другой внешний адрес-порт. Внешние хосты могут послать обратный пакет только на те хосты:порты откуда они получили пакеты.
Symmetric NAT
Еще одна, часто встречающаяся особенность NAT, так называемый port preservation, такой гибрид Port-Restricted и Symmetric NAT, будет рассмотрен в другой статье.
Февраль 3rd, 2009 | 15:58
Отличный пост, прочитав несколько статей на эту тему понял, что всё таки не посмотрел с другой стороны, а пост как-то очень заинтересовал.
Февраль 26th, 2009 | 08:47
Спасибо, особенно за картинки
Март 9th, 2009 | 22:48
Достаточно однобокий пост. Смысл-то в чем? Все равно 3-мя картинками для понимания принципов и проблем не обойтись.
Да и картинок-то хватает в инете.
Например, есть хорошие статейки:
http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080094831.shtml
http://www.cisco.com/web/about/ac123/ac147/ac174/ac182/about_cisco_ipj_archive_article09186a00800c83ec.html
Март 10th, 2009 | 09:32
phantom,
если бы у всех стояли циско роутеры с ios-овской реализацией connttrack,
данная статья бы, не имела бы смысла для практических инженеров.
А на предмет картинок. Так вот, вменяемых картинок с объяснением алгоритмов NAT на середину 2008 года в интернете не было.
Март 10th, 2009 | 10:04
Немного непонятно, при чем все-таки тут конкретные реализации connttrack? Речь шла о базовых принципах работы. в статья же (к сожалению на буржуйском) рассмотрены эти механизмы, а также сопутствующие проблемы, знание которых и позволяет адекватно понимать «а что такое модули connttrack и для чего нужно их использовать». Или я не прав?
Кстати в статьях есть интересные ссылки на доп ресурсы
Март 10th, 2009 | 10:38
Мы вообще о разных вещах говорим. Дело в том, что под connttrack модулями имелись ввиду абсолютно безупречные connttrack модули для VOIP протоколов от циско. Встроенные в IOS и осуществляющие абсолютно корректную трансляцию не только заголовков пакетов, но и тела самого пакета. Если бы то же самое делали остальные производители, то данная статья имела бы чисто академический интерес,
поскольку никаких настроек там нет. IOS достаточно умный, чтобы все исправить самостоятельно.
А когда приходится разбираться с тем, почему после прохода NAT от производителя из Шанхайского подвала, происходит та или иная проблема с VOIP, без моих картинок ой как тоскливо.
Июнь 2nd, 2009 | 20:31
Спасибо. полдня читаю про типы NAT уже крыша едет. еще б статью дополнить как протестить какой тип NAT в конкретном случае. Что типа вывода утилитки stun.
Июнь 2nd, 2009 | 21:36
Если читаете как пользователь, для вас моя же статейка:
http://aoz.com.ua/2009/02/06/sipovernat/
то есть по простому:
1.Обрубаете __все__ связанное с nat traversal,
если интернет между вами и провайдером нормальный и провайдер правильный.
2. Если интернет иногда уходит в полочку, надо позаботится о sipping с вашей стороны.
3. Если провайдер не правильный идите к нормальному.
Ну а если сами провайдер или админ сети тогда читайте, бог в помощь.
А на предмет stun, забудьте как про страшный сон. Толку от нее, если симметричный nat без помощи провайдера не пробить.
Июнь 21st, 2009 | 21:15
Хорошая статья в картинках
Кому надо — тот конечно и на цискоком посмотрит, но итак всё вроде понятно
Август 20th, 2009 | 16:11
Хороший пост, очень понятные и информативные рисунки, довольно доходчиво. Я только начал разбираться с типами NAT-ов и после прочтения поста мне все же не понятно чем Port-Restricted cone NAT отличается от Symmetric NAT. Рисунки иллюстрирующие эти два типа NAT-ов, если я не ошибаюсь, отличаются только красной надписью вверху
Август 21st, 2009 | 08:38
chs,
При симметричном NAT: Каждый пакет с определенного внутреннего IP адреса:порта на определенный внешний IP адрес:порт будет иметь после трансляции уникальный внешний адрес порт, В отличие от Port Restricted, где все SIP устройства из-за NAT видны с одним и тем же портом.
Если уже по по цветам это синенкая рамочка снизу
Февраль 21st, 2010 | 07:56
Благодарю Вас за то, что не поленились поделиться добытыми знаниями!
Февраль 14th, 2012 | 14:31
Спасибо за внесённую ясность. Особенно за картинки — словами гораздо дольше и туманнее. А по картинке можно сразу рассмотреть варианты и разобрать, что к чему.