Малоизвестные подробности работы NAT
ОГЛАВЛЕНИЕ
Эта или подобная схема иногда применяется для обеспечения доступа снаружи к хостам, находящимся в локальной сети (например, к веб-серверу или FTP-серверу). Она может также применяться для балансировки нагрузки путем динамического распределения пакетов, приходящих на публичный адрес маршрутизатора, между несколькими серверами, находящимися в локальной сети, и еще в некоторых случаях.
Исторически сложилось так, что именно его, как правило, имеют в виду, когда употребляют термин «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 на пограничном маршрутизаторе.
Некоторым приложениям, особенно предназначенным для IP-телефонии (поскольку там это наиболее актуально), важно знать, находится ли компьютер, на котором они запущены, в локальной сети за NAT или на компьютере с публичным IP адресом, и в случае NAT – определить, какого он типа. Для этого в настоящее время широко используется протокол STUN, который позволяет также определить наличие блокирующего firewall на пограничном маршрутизаторе или самом компьютере.
Источник
Трансляция сетевых адресов (NAT) и SIP
Содержание
ВВЕДЕНИЕ
Типы трансляторов сетевых адресов (NAT)
Трансляторы адресов подразделяются на 4 типа:
1. Полный конус (Full Cone)
2. Ограниченный конус (Restricted Cone)
3. Порт ограниченного конуса (Port Restricted Cone)
4. Симметричный (Symmetric)
В первых трех типах NATа разные IP-адреса внешней сети могут взаимодействовать с адресом из локальной сети используя один и тот же внешний порт. Четвертый типа, для каждого адреса и порта использует отдельный внешний порт.
NATы не имеют статической таблицы соответствия адресов и портов. Отображение открывается, когда первый пакет посылается из локальной сети наружу через NAT и действует определенный промежуток времени (как правило, 1-3 минуты), если пакеты через этот порт не проходят, то порт удаляется из таблицы соответствия. Обычно NAT распределяют внешние порты динамически, используется диапазон выше 1024.
Полный конус (Full Cone)
При использовании NATа работающего по типу полного конуса внешний отображаемый порт открыт для пакетов приходящих с любых адресов. Если кто-то из внешнего Интернета хочет в этот момент отправить пакет клиенту, расположенному за НАТом, то ему нужно знать только внешний порт через который установлено соединение. Например, компьютер за NATом с IP-адресом 10.0.0.1 посылает и получает пакеты через порт 8000, отображающийся на внешний IP-адрес и порт 212.23.21.25:12345, то любой в Интернете может послать пакеты на этот 212.23.21.25:12345, и эти пакеты попадут на клиентский компьютер 10.0.0.1:8000.
Ограниченный конус (Restricted Cone)
NAT, c ограниченным конусом, открывает внешний порт сразу после того как локальный компьютер отправит данные на определенный внешний IP-адрес. Например, если клиент посылает наружу пакет внешнему компьютеру 1, NAT отображает клиента 10.0.0.1:8000 на 212.23.21.25:12345, и внешний компьютер 1 может посылать пакеты назад по этому назначению. Однако, NAT будет блокировать пакеты идущие от компьютера 2, до тех пор пока клиент не пошлет пакет на IP-адрес этого компьютера. Когда он это сделает, то оба внешних компьютера 1 и 2 смогут посылать пакеты назад клиенту, и оба будут иметь одно и то же отображение через НАТ.
Порт ограниченного конуса (Port Restricted Cone)
NAT с портом ограниченного конуса почти идентичен NATу с ограниченным конусом. Только в этом случае, NAT блокирует все пакеты, если клиент предварительно не послал наружу пакет на IP-адрес и порт того компьютера, который посылает пакеты клиенту. Поэтому, если клиент посылает внешнему компьютеру 1 на порт 5060, то NAT только тогда пропустит пакет к клиенту, когда он идет с 212.33.35.80:5060. Если клиент послал наружу пакеты к нескольким IP-адресам и портам, то они могут ответить клиенту на один и тот же отображенный IP-адрес и порт.
Симметричный (Symmetric)
Симметричный NAT кардинально отличается от первых трех в способе отображения внутреннего IP-адреса и порта на внешний адрес и порт. Это отображение зависит от IP-адреса и порта компьютера, которому предназначен посланный пакет. Например, если клиент посылает с адреса 10.0.0.1:8000 компьютеру 1, то он может быть отображен как 212.23.21.25:12345, в тоже время, если он посылает с того же самого порта (10.0.0.1:8000) на другой IP-адрес, он отображается по-другому (212.23.21.25:12346).
Компьютер 1 может отправить ответ только на 212.23.21.25:12345, а компьютер 2 может ответить только на 212.23.21.25:12346. Если любой из них попытается послать пакеты на порт с которого он не получал пакеты, то эти пакеты будут игнорированы. Внешний IP-адрес и порт открывается только тогда, когда внутренний компьютер посылает данные наружу по определенному адресу.
NAT и Интернет телефония с использованием SIP протокола
Существует три основных проблемы прохождения через NAT звонков с использованием SIP протокола.
1. Наличие локальных адресов в SIP сигнализации.
INVITE sip:81070957877777@212.53.35.244 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.201 :5060
From: sip:1234567@tario.ru
To: sip:81070957877777@tario.ru
Contact: sip: 1234567@ 192.168.1.201 :5060
Call-ID: ED9650AC-8054-CF8CCC22FDAD@ 192.168.1.201
CSeq: 43 INVITE
Content-Type: application/sdp
Content-Length: 228
v=0
o=562003 819348 819348 IN IP4 192.168.1.201
s=X-Lite
c=IN IP4 192.168.1.201
t=0 0
m=audio 8090 RTP/AVP 4 101
a=rtpmap:4 G723/8000
a=rtpmap:101 telephone-event/8000
В приведенном примере сигнализации красным цветом выделены поля, в которых указан локальный адрес. Как следствие этого сервер сети Интернет-телефонии (SoftSwitch) обработав такой запрос, с локальными адресами, не может отправить абоненту ответ, поскольку в поле «Via» указан адрес, который не маршрутизируется в Интернете.
2. Прохождение голосового потока (RTP). Вызываемый абонент, получив вызов от сервера сети Интернет-телефонии, с указанием локального адреса получателя голосового потока не может отправить речевую информацию по назначению, поскольку указанный адрес не маршрутизируется в Интернете. Вследствие этого возникает, одностороння слышимость абонентов или ее полное отсутствие.
3. Абонент, подключенный через NAT, практически не может принимать входящие звонки. Это связанно с тем, что NAT резервирует внешний порт на небольшой промежуток времени (от 1 до 3 мин.), поле чего освобождает его.
Полученный после этого входящий вызов от сервера сети Интернет-телефонии просто игнорируется и как следствие этого абонент расположенный за NATом не может получить информацию о входящем звонке.
Возможные методы прохождения через NAT
Разные производители предусматривают в своем оборудовании разные способы решения проблемы с прохождения через NAT. Однако все этим методы можно разделить на четыре группы.
1. Использование предоставленного IP адреса (Shared IP)
Суть данного метода заключается в том, что на NAT сервере прописывается безусловное перенаправление пакетов приходящих на определенный внешний порт NATа внутреннему IP адресу VoIP устройства. На VoIP устройстве указывается внешний IP адрес NATа, который используется в сигнализации в качестве оригинирующего. Данный метод приемлем для небольших локальных сетей с постоянным внешним IP адресом, использующих небольшое количество VoIP устройств. Его можно использовать вне зависимости от типа NATа. Использование данного метода в больших сетях использующих динамические адреса практически невозможно.
Примеры устройств поддерживающих данный метод.
— Cisco ATA-186
— Grandstream BudgeTone 100
— Asotel Dynamix DW-02 (DW-04)
2.UPnP
Данная технология была разработана компанией Microsoft для решения проблем прохождения через NAT. Суть ее заключается в возможности автоматического управления работой NATа. Для подключения с использованием этого необходима поддержка UPnP как VoIP устройством так и самим NATом. Одной из основных проблем при использовании данного подхода является очень ограниченное количество NATов и VoIP устройств поддерживающих данный протокол.
Примеры устройств поддерживающих данный метод.
— PC Phoneline
— Asotel Dynamix
— WellTech
— Windows Messenger 5.0
Примеры NATов поддерживающих UPnP
— Windows XP NAT
— Winroute Pro 5.0
3.STUN
Данная технология позволяет обеспечить работу VoIP устройств, которые подключены через конусные NATы. Суть данного метода заключается в том, что VoIP устройство вначале отправляет запрос на STUN сервер, который сообщает текущий внешний адрес и порт, который потом используется в качестве принимающего.
Для обеспечения прохождения входящих звонков VoIP устройство периодически посылает пустые пакеты на адрес сервера маршрутизации сети Интернет телефонии, поддерживая, таким образом, резервирование внешнего порта. Подключение с использованием STUN может использоваться в крупных сетях с использованием динамического распределения адресов.
Примеры устройств поддерживающих данный метод.
— Cisco ATA-186 v3.0 и выше
— Grandstream BudgeTone 100
— SIPURA SPA-2000
4. Проксирование на оригинирующий адрес
Данный метод позволяет подключать через NAT практически любое SIP устройство, даже не предусматривающее подключение через NAT. Его можно использовать с любым типом NATа. Суть данного метода заключается в использовании специального пограничного контролера (OutBoundProxy) производящего коррекцию сигнализации и проксирование голосового трафика на оригинирующий адрес. Основным недостатком данного метода является проксирование голосового трафика, что может приводить к дополнительной задержке, если OutBoundProxy находится на значительном расстоянии от клиента.
Для обеспечения прохождения входящих звонков VoIP устройству переодически отсылаются пустые пакеты для поддержки резервирования внешнего порта.
Простейшим примером пограничного контролера может являться SIPOffice.
Источник
Трансляция сетевых адресов (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ом не может получить информацию о входящем звонке
Источник