full cone nat что это такое
Типы NAT
NAT – трансляция сетевых адресов, позволяет локальным (частным) сетям, использующим незарегистрированные IP-адреса, подключаться к Интернету. NAT работает на маршрутизаторе, обычно соединяя две сети вместе, и преобразует частные адреса во внутренней сети в публичные адреса, прежде чем пакеты будут перенаправлены в другую сеть.
В рамках этой возможности NAT может быть настроен для объявления только одного адреса для всей сети внешнему миру. Это обеспечивает дополнительную безопасность, эффективно скрывая за этим адресом всю внутреннюю сеть. NAT предлагает двойные функции безопасности и сохранения адресов и обычно реализуется в средах удаленного доступа.
Как работает
NAT позволяет одному устройству, например маршрутизатору, действовать как агент между Интернетом и локальной сетью, представляя доступ устройствам за пределами своей сети.
Зачем это нужно
В качестве примера возьмем игровые консоли. Когда вы подключаете PlayStation 4/5 или Xbox к беспроводному маршрутизатору, хотя вы можете подключиться к Xbox Live / PlayStation Network, однако возникают следующие проблемы:
Например, PlayStation 4/5 необходимо установить Type NAT 1 (позволяет создавать многопользовательскую игру ) или Type NAT 2 (не позволяет создавать многопользовательскую игру, но можно подключиться к другим игрокам ).
Full Cone NAT
Все запросы с одного и того же внутреннего IP-адреса и порта с одним и тем же внешний IP-адресом и портом. Любой внешний хост может отправить пакет внутреннему хосту, отправив пакет на назначенный внешний адрес.
Restricted Cone NAT
Все запросы с одного и того же внутреннего IP-адреса и порта с одним и тем же внешний IP-адресом и портом. В отличие от Full Cone NAT, внешний хост (с IP-адресом X) может отправить пакет на внутренний хост только в том случае, если внутренний хост ранее отправил пакет на IP-адрес X.
Port Restricted NAT
То же, что и Restricted Cone NAT, но в этом случае обращается внимание на соответствие номера порта источника, и не обращает внимания на адрес источника. Маршрутизатор будет транслировать входящие пакеты с любым адресом источника, но порт источника при этом обязан быть 53, в противном случае пакет будет уничтожен маршрутизатором.
Symmetric NAT
Все запросы с одного и того же внутреннего IP-адреса и порта на определенный IP-адрес и порт назначения, сопоставляется с одним и тем же внешний IP-адресом и портом. Если один и тот же хост отправляет пакет с тем же адресом источника и портом, но в другое место назначения, используется другое сопоставление. Только внешний хост, который получает пакет от внутреннего хоста, может отправить пакет обратно.
Проблемы
В Symmetric NAT некоторые онлайн-игры или потоковые сервисы могут работать некорректно. В настоящее время вы можете переключиться на Fullcone NAT, чтобы обеспечить нормальное использование связанных сервисов, однако с менее безопасным.
Если у вас нет особых потребностей или после завершения игры, рекомендуется настроить тип NAT на Symmetric NAT по умолчанию, чтобы сделать внутреннюю сетевую среду более безопасной.
Трансляция сетевых адресов (NAT). Виды, схемы работы
Типы трансляторов сетевых адресов (NAT)
Трансляторы адресов подразделяются на 4 типа:
1. Symmetric NAT.
2. Full Cone NAT.
3. Address Restricted Cone NAT (он же Restricted NAT).
4. Port Restricted Cone NAT (или Port Restricted NAT)
В первых трех типах NATа разные IP-адреса внешней сети могут взаимодействовать с адресом из локальной сети используя один и тот же внешний порт. Четвертый тип, для каждого адреса и порта использует отдельный внешний порт.
NATы не имеют статической таблицы соответствия адресов и портов. Отображение открывается, когда первый пакет посылается из локальной сети наружу через NAT и действует определенный промежуток времени (как правило, 1-3 минуты), если пакеты через этот порт не проходят, то порт удаляется из таблицы соответствия. Обычно NAT распределяют внешние порты динамически, используется диапазон выше 1024.
1.Symmetric NAT.
До недавнего времени это была наиболее распространённая реализация. Его характерная особенность – в таблице NAT маппинг адреса IL на адрес IG жёстко привязан к адресу OG, то есть к адресу назначения, который был указан в исходящем пакете, инициировавшем этот маппинг. При указанной реализации NAT в нашем примере хост 192.168.0.141 получит оттранслированные входящие UDP-пакеты только от хоста 1.2.3.4 и строго с портом источника 53 и портом назначения 1053 – ни от кого более. Пакеты от других хостов, даже если указанные в пакете адрес назначения и порт назначения присутствуют в таблице NAT, будут уничтожаться маршрутизатором. Это наиболее параноидальная реализация NAT, обеспечивающая более высокую безопасность для хостов локальной сети, но в некоторых случаях сильно усложняющая жизнь системных администраторов. Да и пользователей тоже.
2. Full Cone NAT.
Эта реализация NAT – полная противоположность предыдущей. При Full Cone NAT входящие пакеты от любого внешнего хоста будут оттранслированы и переправлены соответствующему хосту в локальной сети, если в таблице NAT присутствует соответствующая запись. Более того, номер порта источника в этом случае тоже не имеет значения – он может быть и 53, и 54, и вообще каким угодно. Например, если некое приложение, запущенное на компьютере в локальной сети, инициировало получение пакетов UDP от внешнего хоста 1.2.3.4 на локальный порт 4444, то пакеты UDP для этого приложения смогут слать также и 1.2.3.5, и 1.2.3.6, и вообще все до тех пор, пока запись в таблице NAT не будет по какой-либо причине удалена. Ещё раз: в этой реализации NAT во входящих пакетах проверяется только транспортный протокол, адрес назначения и порт назначения, адрес и порт источника значения не имеют.
3. Address Restricted Cone NAT (он же Restricted NAT).
Эта реализация занимает промежуточное положение между Symmetric и Full Cone реализациями NAT – маршрутизатор будет транслировать входящие пакеты только с определенного адреса источника (в нашем случае 1.2.3.4), но номер порта источника при этом может быть любым.
4.Port Restricted Cone NAT (или Port Restricted NAT).
То же, что и Address Restricted Cone NAT, но в этом случае маршрутизатор обращает внимание на соответствие номера порта источника и не обращает внимания на адрес источника. В нашем примере маршрутизатор будет транслировать входящие пакеты с любым адресом источника, но порт источника при этом обязан быть 53, в противном случае пакет будет уничтожен маршрутизатором.
NAT и Интернет телефония с использованием SIP протокола
Существует три основных проблемы прохождения через NAT звонков с использованием SIP протокола.
1. Наличие локальных адресов в SIP сигнализации.
INVITE sip:74957877070@212.1.1.45 SIP/2.0
Record-Route:
Via: SIP/2.0/UDP 212.1.1.45;branch=z9hG4bK3af7.0a6e92f4.0
Via: SIP/2.0/UDP 192.168.0.21;branch=z9hG4bK12ee92cb;rport=5060
From: «test» ;tag=as149b2d97
To: sip:74957877070@mangosip.ru
Contact:
Call-ID: 3cbf958e6f43d91905c3fa964a373dcb@192.168.0.21:5060
CSeq: 3 INVITE
Max-Forwards: 70
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: 394
В приведенном примере сигнализации выделены поля, в которых указан локальный адрес. Как следствие этого сервер сети Интернет-телефонии (SoftSwitch) обработав такой запрос, с локальными адресами, не может отправить абоненту ответ, поскольку в поле «Via» указан адрес, который не маршрутизируется в Интернете.
2. Прохождение голосового потока (RTP).
Вызываемый абонент, получив вызов от сервера сети Интернет-телефонии, с указанием локального адреса получателя голосового потока не может отправить речевую информацию по назначению, поскольку указанный адрес не маршрутизируется в Интернете. Вследствие этого возникает, одностороння слышимость абонентов или ее полное отсутствие.
3. Абонент, подключенный через NAT, практически не может принимать входящие звонки.
Это связанно с тем, что NAT резервирует внешний порт на небольшой промежуток времени (от 1 до 3 мин.), поле чего освобождает его.
Полученный после этого входящий вызов от сервера сети Интернет-телефонии просто игнорируется и как следствие этого абонент расположенный за NATом не может получить информацию о входящем звонке
Так ли страшен Symmetric NAT
Задача прямого соединения машин, находящихся за NAT’ом стара как мир и я думаю, что многие слышали про UDP Hole Punching. Когда я только начинал интересоваться вопросом, я утвердился во мнении, что symmetric nat пробить невозможно и пытаться даже не стоит. Однако совсем недавно мне попалась статья в которой утверждалось, что симметричный нат — это не приговор.
Типы NAT
1) фильтр входящих пакетов;
2) правило маппинга портов.
Первая характеристика как раз описана в большинстве статей и означает, какие входящие пакеты передавать машине за NAT’ом: все (no filter – Full cone), с конкретного адреса (address-restricted) или с конкретного адреса и порта (port-restricted).
Вторая характеристика же присуще только симметричному НАТ’у, так как первые три типа пытаются сделать отражение один в один. Например, если клиент посылает пакет с внутреннего адреса 192.168.10.24:62145, то от роутера пакет пойдет с адреса 1.2.3.4:62145. Причем вне зависимости от адреса получателя.
Symmetric NAT
Выбирается тот самый порт случайно (ну или не случайно, а по очереди, но это не важно, так как повлиять на его выбор извне мы не можем). Но есть определенные правила, они похожи на фильтр входящих пакетов:
При этом есть еще и правила для выбора следующего порта:
Это может быть какая-то дельта (+1/-1 или +10/-10) или вообще каждый раз случайно.
Кроме того видел один NAT у которого каждый последующий порт отстоял от предыдущего на случайное число, но всегда кратное 4096.
Вместо заключения
Итак, понятного, что зная правило распределения портов и дельту можно угадать, с какого порта пойдет исходящий пакет, соответственно пробить тот самый симметричный NAT. Разумеется, в случае выбора порта совсем случайно, этот фокус не пройдет.
Ну что же мы подобрались к сути и цели статьи. Ответу на вопрос
«Можно ли определить правило распределения портов и дельту, находясь за NAT’ом?»
Поможет нам в этом STUN, конечно. Наша задача сделать четыре запроса к разным адресам и портами используя один сокет (один локальный порт) и оценить результаты:
Мы сможем понять каким образом распределяются исходящие порты (адрес или порт) и попробовать рассчитать ту самую дельту.
И тут я призываю хабрасообщество мне помочь со статистикой. На просторах Интернета был найден простенький stun клиент, немножко допилен кувалдой и вот что получилось:
Пользователи Линукса прекрасно знают как это скомпилировать.
Под винду отлично компилится студией, вот тут бинарник, если студии под рукой нет.
Да простит меня stun.counterpath.net за хабра эффект 🙂
Вот мои результаты, но у меня не симметричный НАТ и не интересно:
Results
tests: 1010
NAT present: 1
first preserved port: 1
preserves port: 0
type: Port restricted NAT
mapped ports: 55907 55907 55907 55907
Всем спасибо за помощь!
udp: Оставляйте, пожалуйста, ваши результаты в комментариях, даже если НАТ не симметричный. Ведь в любом случаю важно знать распиновку по типам.
Малоизвестные подробности работы NAT
Используя терминологию Cisco, в контексте NAT есть четыре основных определения для IP-адресов. Рассмотрим их на примере, показанном на рисунке ниже. На обоих маршрутизаторах делается NAT (network address translation).
Эта или подобная схема иногда применяется для обеспечения доступа снаружи к хостам, находящимся в локальной сети (например, к веб-серверу или FTP-серверу). Она может также применяться для балансировки нагрузки путем динамического распределения пакетов, приходящих на публичный адрес маршрутизатора, между несколькими серверами, находящимися в локальной сети, и еще в некоторых случаях.
Исторически сложилось так, что именно его, как правило, имеют в виду, когда употребляют термин «NAT», и о нём мы и будем говорить в дальнейшем, ввиду его распространённости.
В конфигурации маршрутизатора указано, что он должен выполнять NAT для всех пакетов, с адресами источника 192.168.0.0/24, пришедших через интерфейс Ethernet0 и отправляемых далее через интерфейс Serial0, а также для ответных пакетов, пришедших через Serial0, для которых есть соответствующая запись в таблице трансляций:
interface Ethernet0
ip address 192.168.0.1 255.255.255.0
ip nat inside
ip nat inside source list MyNetwork interface Serial0 overload
ip access-list extended MyNetwork
permit ip 192.168.0.0 0.0.0.255 any
В результате этого в таблице NAT появится примерно такая запись:
UDP 11.22.33.44:1053 192.168.0.141:1053 1.2.3.4:53 1.2.3.4:53
Здравый смысл подсказывает, что вроде бы не должен. С другой стороны, налицо факт: в нашей таблице NAT черным по белому записано, что пакет с адресом назначения 11.22.33.44 и портом назначения 1053 нужно принять и транслировать в локальную сеть для хоста 192.168.0.141 (который его примет и молча уничтожит, поскольку на этом компьютере не запущено сетевого приложения, которому был бы предназначен этот пакет.)
По этой же причине может не работать DCC chat в клиентах IRC, передача файлов в ICQ и тому подобные вещи, для которых требуется обеспечение беспрепятственного прохождения пакетов непосредственно между пользовательскими компьютерами.
Протокол STUN
Для иллюстрации работы STUN рассмотрим следующий рисунок(взят из статьи «Anatomy: A Look Inside Network Address Translators» в «The IP Journal» Vol.7 Num. 2 за сентябрь 2004 г.).
Клиент STUN встроен в некоторые приложения IP-телефонии, например, X-Pro и X-Lite от компании CounterPath, и в некоторые другие. Консольный клиент STUN под ОС Windows может быть загружен отсюда: http://prdownloads.sourceforge.net/stun/client.exe?download.
Запустив его и указав в качестве параметра командной строки один из публичных STUN-серверов, вы узнаете тип вашего NAT:
STUN client version 0.94
Primary: Full Cone Nat, random port, no hairpin
Return value is 0x9
Приведённый выше результат получен на компьютере, находящемся за маршрутизатором ZyXEL Prestige 645R.
Результат для маршрутизатора Cisco 1721 с IOS версии 12.2 в свою очередь выглядит так:
STUN client version 0.94
.
Primary: Port Restricted Nat, preserves ports, no hairpin
Return value is 0x1b
Такой же результат получен для маршрутизатора, построенного на основе FreeBSD, на которой NAT выполнялась демоном natd.
А вот как выглядит результат для PIX (прим. HunSolo)
STUN client version 0.94
.
Primary: Port Restricted Nat, rundom port, no hairpin
Return value is 0xb
Осталось объяснить, что такое «random port», «preserves ports» и «no hairpin» в приведенных выше результатах.
Посмотрим еще раз на строчку из таблицы NAT в нашем примере:
UDP 11.22.33.44:1053 192.168.0.141:1053 1.2.3.4:53 1.2.3.4:53
Random port означает, что данная реализация NAT не заботится о том, чтобы номер порта источника в исходящем наружу пакете оставался таким же, каким он был получен от хоста локальной сети, и заменяет его на случайное значение в диапазоне от 1024 до 65535. Можно предположить, что по замыслу автора идеи «random ports» такая замена уменьшает вероятность конфликта между записями, если несколько хостов локальной сети одновременно попытаются отправить наружу пакеты с совпадающим номером порта источника. Поскольку номер порта источника в исходящих пакетах формируется хостами локальной сети также случайным образом, преимущества такой замены сомнительны, из недостатков же можно назвать хотя бы потенциальную проблему с протоколом RPC, да и не только.
Hairpin же означает следующее. Допустим, при наличии в таблице NAT приведенной выше строчки другой хост нашей локальной сети (например, 192.168.0.241) отправляет UDP-пакет с адресом назначения 11.22.33.44, портом назначения 1053 и портом источника 53. Что произойдет в результате?
NAT и шлюзы приложений
Первый случай. Пользователь, находящийся в локальной сети за NAT, использует FTP-клиент для того, чтобы получить доступ к FTP-серверу с публичным IP-адресом
Проблема здесь возникает, когда клиент пытается использовать активный режим FTP. Сессия протекает при этом следующим образом. В некоторый момент по управляющему соединению серверу передается команда FTP-клиента: PORT 192,16,0,101,4,211.
Дальнейший диалог выглядит примерно так:
Наибольший интерес здесь представляет первая команда от клиента, которая информирует сервер о том, что хост с адресом 192.168.0.101 открыл для приема соединения данных порт номер (4*256) + 211 = 1235. В ответ на это сервер должен установить соединение данных со своего порта номер 20 на указанный порт хоста 192.168.0.101. Поскольку этот адрес является приватным, такое соединение не может быть установлено. В результате наблюдается знакомый многим системным администраторам эффект, когда клиент вроде бы успешно подключается к FTP-серверу, но не может скачивать с него файлы или даже просматривать содержимое текущего каталога (это происходит потому, что передача листинга файлов с сервера на клиент также осуществляется по соединению данных).
ля борьбы с описанной проблемой может использоваться переключение сервера в так называемый пассивный режим. Поскольку в этом режиме инициатором соединения данных выступает клиент, проблема исчезает. Именно поэтому в Microsoft Internet Explorer, как и консольный FTP-клиент, встроенный в Windows, используют по умолчанию пассивный режим (они автоматически вставляют перед командами RETR и NLST команду PASV, переключающую сервер в пассивный режим).
Второй случай. Пользователь, находящийся в локальной сети за NAT, использует FTP-клиент для того, чтобы получить доступ к FTP-серверу, который также находится за NAT. В этом случае, очевидно, не поможет и пассивный режим, так как в команде PORT независимо от того, клиент или сервер ее отдает, всегда будет указан приватный IP-адрес, и соединение данных никогда не будет установлено.
Так, в приведенном выше примере, если предположить, что публичный IP-адрес маршрутизатора с NAT 1.2.3.4 и что он сохраняет номер порта источника неизменным, команда PORT 192,16,0,101,4,211 была бы изменена маршрутизатором на PORT 1,2,3,4,4,211. Благодаря этому в обоих указанных выше случаях соединение данных будет успешно установлено.
Функция ALG в маршрутизаторах Cisco позволяет осуществлять трансляцию адресов уровня приложений не только для протокола FTP, но также и для протоколов SIP, H.323, Skinny и некоторых других (благодаря этому можно, например, размещать в локальной сети серверы DNS). Для большего удобства функция ALG в маршрутизаторах Cisco включена по умолчанию.
Аналогичную ALG функциональность в маршрутизаторах на основе ОС Linux обеспечивают дополнительные загружаемые модули и патчи к ядру (такие, как ip_masq_ftp, ip_masq_irc и т. п.).
Full cone nat что это такое
NAT (от англ. Network Address Translation — «преобразование сетевых адресов») — это механизм в сетях TCP/IP, позволяющий преобразовывать IP-адреса транзитных пакетов. Также имеет названия IP Masquerading, Network Masquerading и Native Address Translation.
Содержание
Функционирование [ править | править код ]
Принимая пакет от локального компьютера, роутер смотрит на IP-адрес назначения. Если это локальный адрес, то пакет пересылается другому локальному компьютеру. Если нет, то пакет надо переслать наружу в интернет. Но ведь обратным адресом в пакете указан локальный адрес компьютера, который из интернета будет недоступен. Поэтому роутер «на лету» транслирует (подменяет) обратный IP-адрес пакета на свой внешний (видимый из интернета) IP-адрес и меняет номер порта (чтобы различать ответные пакеты, адресованные разным локальным компьютерам). Комбинацию, нужную для обратной подстановки, роутер сохраняет у себя во временной таблице. Через некоторое время после того, как клиент и сервер закончат обмениваться пакетами, роутер сотрет у себя в таблице запись об n-м порте за сроком давности.
Помимо source NAT (предоставления пользователям локальной сети с внутренними адресами доступа к сети Интернет) часто применяется также destination NAT, когда обращения извне транслируются межсетевым экраном на компьютер пользователя в локальной сети, имеющий внутренний адрес и потому недоступный извне сети непосредственно (без NAT).
Существует 3 базовых концепции трансляции адресов: статическая (Static Network Address Translation), динамическая (Dynamic Address Translation), маскарадная (NAPT, NAT Overload, PAT).
Статический NAT — отображение незарегистрированного IP-адреса на зарегистрированный IP-адрес на основании один к одному. Особенно полезно, когда устройство должно быть доступным снаружи сети.
Динамический NAT — отображает незарегистрированный IP-адрес на зарегистрированный адрес из группы зарегистрированных IP-адресов. Динамический NAT также устанавливает непосредственное отображение между незарегистрированными и зарегистрированными адресами, но отображение может меняться в зависимости от зарегистрированного адреса, доступного в пуле адресов, во время коммуникации.
Перегруженный NAT (NAPT, NAT Overload, PAT, маскарадинг) — форма динамического NAT, который отображает несколько незарегистрированных адресов в единственный зарегистрированный IP-адрес, используя различные порты. Известен также как PAT (Port Address Translation). При перегрузке каждый компьютер в частной сети транслируется в тот же самый адрес, но с различным номером порта.
Механизм NAT определён в RFC 1631, RFC 3022.
Типы NAT [ править | править код ]
Классификация NAT, часто встречающаяся в связи с VoIP. [2] Термин «соединение» использован в значении «последовательный обмен пакетами UDP».
Симметричный NAT (Symmetric NAT) — трансляция, при которой каждое соединение, инициируемое парой «внутренний адрес: внутренний порт» преобразуется в свободную уникальную случайно выбранную пару «публичный адрес: публичный порт». При этом инициация соединения из публичной сети невозможна. [ источник не указан 1204 дня ]
Cone NAT, Full Cone NAT — однозначная (взаимная) трансляция между парами «внутренний адрес: внутренний порт» и «публичный адрес: публичный порт». Любой внешний хост может инициировать соединение с внутренним хостом (если это разрешено в правилах межсетевого экрана).
Address-Restricted cone NAT, Restricted cone NAT — постоянная трансляция между парой «внутренний адрес: внутренний порт» и «публичный адрес: публичный порт». Любое соединение, инициированное с внутреннего адреса, позволяет в дальнейшем получать ему пакеты с любого порта того публичного хоста, к которому он отправлял пакет(ы) ранее.
Port-Restricted cone NAT — трансляция между парой «внутренний адрес: внутренний порт» и «публичный адрес: публичный порт», при которой входящие пакеты проходят на внутренний хост только с одного порта публичного хоста — того, на который внутренний хост уже посылал пакет.
Преимущества [ править | править код ]
NAT выполняет три важных функции.
Недостатки [ править | править код ]
Пример [ править | править код ]
Трансляция локальной сети с диапазоном адресов 172.16.14.0/24 в глобальную сеть будет осуществляться через один внешний IP-адрес (адрес маршрутизатора, выполняющего трансляцию).
Применение:IP сеть через единственный IP-адрес [ править | править код ]
• Экономическая выгода вследствие приобретения единственного IP-подключения, а не IP-сети.
• Сокрытие от внешнего наблюдателя структуры внутренней IP-сети.
• Организация системы с распределенной нагрузкой.
• При общем доступе через NAT прозрачно открывается доступ к внутренней структуре с защитой без использования межсетевого экрана и т. п.
• Через NAT корректно работают многие сетевые протоколы. Конструктивные реализации (общий доступ — это и есть подключение NAT) есть аппаратная реализация NAT (интегрированы межсетевые экраны).
NAT loopback [ править | править код ]
Смысл технологии NAT loopback (или NAT hairpinning) прост: если пакет приходит из внутренней сети на внешний IP-адрес маршрутизатора, он считается пришедшим извне — а значит, работают правила брандмауэра, относящиеся ко внешним соединениям. И если пакет успешно пройдёт сквозь брандмауэр, сработает NAT, взяв на себя посредничество между двумя внутрисетевыми машинами. Это даёт две вещи.
Недостатком NAT loopback можно считать повышенную нагрузку на хаб и маршрутизатор (по сравнению с прямым доступом к серверу).
NAT Traversal [ править | править код ]
NAT Traversal (прохождение или автонастройка NAT) — это набор возможностей, позволяющих сетевым приложениям определять, что они находятся за устройством, обеспечивающим NAT, узнавать внешний IP-адрес этого устройства и выполнять сопоставление портов для пересылки пакетов из внешнего порта NAT на внутренний порт, используемый приложением; все это выполняется автоматически, пользователю нет необходимости вручную настраивать сопоставления портов или вносить изменения в какие-либо другие параметры. Однако существуют меры предосторожности в доверии к таким приложениям — они получают обширный контроль над устройством, появляются потенциальные уязвимости.
Программная реализация NAT [ править | править код ]
При наличии уже существующего сервера под управлением серверной ОС возможно организовать трансляцию адресов без необходимости закупки дополнительных, аппаратных устройств. Как правило для программной реализации NAT требуется наличие по крайней мере двух сетевых адаптеров в сервере (возможны варианты с одним, но при наличии trunk-VLAN).
Все существующие и использующиеся серверные ОС поддерживают простейшую трансляцию адресов.
С точки зрения отказоустойчивости, гибкости и производительности, используются операционные системы семейства UNIX (большинство GNU/Linux, *BSD-системы, а также OpenSolaris и др.). Во многих из них NAT доступен «из коробки», в других возможна реализация за счёт добавления модулей в сочетании с межсетевыми экранами с функциями трансляции адресов (IPFW, IPtables и др.). Также, NAT работает «из коробки» в семействе операционных систем Windows Server.
Cone NAT, Full Cone NAT — Однозначная (взаимная) трансляция между парами «внутренний адрес: внутренний порт» и «публичный адрес: публичный порт». Любой внешний хост может инициировать соединение с внутренним хостом (если это разрешено в правилах межсетевого экрана).
Перегруженный NAT (NAPT, NAT Overload, PAT, маскарадинг) — форма динамического NAT, который отображает несколько незарегистрированных адресов в единственный зарегистрированный IP-адрес, используя различные порты. Известен также как PAT (Port Address Translation). При перегрузке каждый компьютер в частной сети транслируется в тот же самый адрес, но с различным номером порта.
ОГЛАВЛЕНИЕ
При этом используются следующие термины:
Простейший случай NAT – это трансляция адресов Inside Local в Inside Global и наоборот. При этом маршрутизатор, выполняющий NAT, модифицирует поле адреса в заголовке IP следующим образом:
Таким образом, в таблице сопоставлений NAT каждая запись состоит из двух значений – IL и IG.
Эта или подобная схема иногда применяется для обеспечения доступа снаружи к хостам, находящимся в локальной сети (например, к веб-серверу или FTP-серверу). Она может также применяться для балансировки нагрузки путем динамического распределения пакетов, приходящих на публичный адрес маршрутизатора, между несколькими серверами, находящимися в локальной сети, и еще в некоторых случаях.
Более распространённый случай – это NPAT, network and port address translation. При использовании NPAT в таблице сопоставлений каждая запись имеет не два (как в простом NAT), а пять значений:
Это позволяет использовать единственный публичный адрес для предоставления доступа в Интернет компьютерам, находящимся в локальной сети. В документации Cisco такая схема обычно называется «NAT with port overload» или короче – «NAT overload».
Исторически сложилось так, что именно его, как правило, имеют в виду, когда употребляют термин «NAT», и о нём мы и будем говорить в дальнейшем, ввиду его распространённости.
До сих пор речь шла о вещах общеизвестных. Однако, если посмотреть на NAT поближе, возникают новые вопросы. Возьмём простейшую сеть, с одним компьютером и одним маршрутизатором, выполняющим NAT. Модель маршрутизатора в данном случае не слишком важна – допустим, что это давно устаревшая, но все еще популярная Cisco 1601R.
В конфигурации маршрутизатора указано, что он должен выполнять NAT для всех пакетов, с адресами источника 192.168.0.0/24, пришедших через интерфейс Ethernet0 и отправляемых далее через интерфейс Serial0, а также для ответных пакетов, пришедших через Serial0, для которых есть соответствующая запись в таблице трансляций:
interface Serial0
ip address 11.22.33.44 255.255.255.252
ip nat outside
interface Ethernet0
ip address 192.168.0.1 255.255.255.0
ip nat inside
ip nat inside source list MyNetwork interface Serial0 overload
ip access-list extended MyNetwork
permit ip 192.168.0.0 0.0.0.255 any
Предположим, компьютер с адресом IL 192.168.0.141 отправляет DNS-запрос на внешний хост 1.2.3.4 (порт 53, протокол UDP). Как следует из конфигурации, наш внешний адрес IG – 11.22.33.44.
В результате этого в таблице NAT появится примерно такая запись:
Proto Inside global Inside local Outside local Outside global
UDP 11.22.33.44:1053 192.168.0.141:1053 1.2.3.4:53 1.2.3.4:53
Допустим, после появления такой записи в таблице, другой хост, 1.2.3.5, отправляет пакет UDP с адресом назначения 11.22.33.44 и портом назначения 1053. Вопрос – получит ли наш хост 192.168.0.141 этот пакет?
Здравый смысл подсказывает, что вроде бы не должен. С другой стороны, налицо факт: в нашей таблице NAT черным по белому записано, что пакет с адресом назначения 11.22.33.44 и портом назначения 1053 нужно принять и транслировать в локальную сеть для хоста 192.168.0.141 (который его примет и молча уничтожит, поскольку на этом компьютере не запущено сетевого приложения, которому был бы предназначен этот пакет.)
Кстати говоря – ну хорошо, допустим такого приложения нет, а если бы оно было? Как хорошо известно пользователям таких программ, как eMule и eDonkey, они требуют, чтобы им была предоставлена возможность беспрепятственно получать UDP пакеты с портом назначения 4661, или 4242, или 4321 – точный номер порта зависит от настроек. И, что также хорошо известно их пользователям, эти программы плохо работают, будучи запущены из локальной сети, находящейся за NAT. Так вот, это может происходить, в том числе и потому, что несмотря на успешное установление локальным клиентом соединения с сервером, из-за специфики данной конкретной реализации NAT другие клиенты, находящиеся во внешнем мире, не могут устанавливать соединение с локальным клиентом.
По этой же причине может не работать DCC chat в клиентах IRC, передача файлов в ICQ и тому подобные вещи, для которых требуется обеспечение беспрепятственного прохождения пакетов непосредственно между пользовательскими компьютерами.
Итак, отвечая на вопрос, «получит ли наш хост 192.168.0.141 пакет, направленный на 11.22.33.44 от постороннего хоста», – может быть, получит, а может быть, и нет; ответ на этот вопрос зависит от реализации NAT на пограничном маршрутизаторе.
Реализаций же насчитывается четыре:
Как видим, реализации NAT – это настоящий зоопарк, в котором каждой твари по паре. Положение смягчается тем, что для большинства сетевых приложений подробности реализации NAT большого значения не имеют (в особенности для приложений, использующих транспорт TCP, как известно, это протокол, использующий сессии, поэтому сказанное выше для TCP неактуально. Тем не менее с развитием приложений Peer-to-Peer (eDonkey, eMule, Skype), IPтелефонии и разнообразной сетевой мультимедии (зачастую использующих транспорт на основе UDP) различия в реализациях NAT постепенно начинают играть заметную роль. Поэтому для разработчиков таких приложений пришла пора задуматься над тем, как их детище будет работать, находясь в локальной сети за NATом. Одним из плодов таких раздумий стал протокол STUN (Simple Traversal of UDP through NAT), описанный в RFC 3489.
Некоторым приложениям, особенно предназначенным для IP-телефонии (поскольку там это наиболее актуально), важно знать, находится ли компьютер, на котором они запущены, в локальной сети за NAT или на компьютере с публичным IP адресом, и в случае NAT – определить, какого он типа. Для этого в настоящее время широко используется протокол STUN, который позволяет также определить наличие блокирующего firewall на пограничном маршрутизаторе или самом компьютере.