1632
правки
Изменения
NAT
,rollbackEdits.php mass rollback
'''NAT''' — Network Address Translation, метод трансляции сетевых адресов, описан в стандарте [https://tools.ietf.org/html/rfc3022 RFC 3022], [https://tools.ietf.org/html/rfc1631 RFC 1631]. [http://rfc.com.ru/rfc3022.htm RFC 3022] на русском языке.
=Принцип работы=
Компьютер может быть подключен к Интернету напрямую (белый IP-адрес, обычно при подключении непосредственно к модему), либо через NAT — тогда компьютер имеет локальный IP-адрес, из Интернета недоступный(частный, серый). К серым адресам относятся адреса из следующих диапазонов: {| class="wikitable"!Диапазон!Количество хостов|-|10.0.0.0 - 10.255.255.255/8|16 777 216 хостов|-|172.16.0.0 - 172.31.255.255/12|1 048 576 хостов|-|192.168.0.0 - 192.168.255.255/16|65 536 хостов|} Преобразование адреса методом NAT может производиться почти любым маршрутизирующим устройством — маршрутизатором, сервером доступа, межсетевым экраном. Принимая пакет от локального компьютера, роутер смотрит на IP-адрес назначения. Если это локальный адрес, то пакет пересылается другому локальному компьютеру. Если нет, то пакет надо переслать наружу в интернет. Но ведь обратным адресом в пакете указан локальный адрес компьютера, который из интернета будет недоступен. Поэтому роутер «на лету» транслирует (подменяет) обратный IP-адрес пакета на свой внешний (видимый из интернета) IP-адрес и меняет номер порта (чтобы различать ответные пакеты, адресованные разным локальным компьютерам). Комбинацию, нужную для обратной подстановки, роутер сохраняет у себя во временной таблице. Через некоторое время после того, как клиент и сервер закончат обмениваться пакетами, роутер сотрет у себя в таблице запись о n-ом порте за сроком давности. ==Пример==[[Файл:NATExample2.jpg]] =Типы NAT=== Статический ==Один внутренний адрес преобразуется в один внешний, все запросы, приходящие на внешний адрес будут транслироваться на внутренний, как будто хост и является обладателем белого IP-адреса. Такой подход бывает полезным, когда внутри частной сети есть сервер, к которому необходим полный доступ извне. Минус подхода в том, что он никак не помогает сохранить белые адреса. == Динамический ==Есть пул белых адресов, например, провайдер выделил сеть 198.51.100.0/28 с 16-ю адресами. Два из них (первый и последний) — адрес сети и широковещательный, ещё два адреса назначаются на оборудование для обеспечения маршрутизации. Двенадцать оставшихся адресов можно использовать для NAT и выпускать через них своих пользователей. Ситуация похожа на статический NAT — один приватный адрес транслируется на один внешний, — но теперь внешний не чётко зафиксирован, а будет выбираться динамически из заданного диапазона. Проблема подхода такая же, как и в случае со статическим NAT — не решается проблема ограниченности белых адресов. == Many-to-One ==Следующий тип имеет несколько названий: NAT Overload, Port Address Translation (PAT), IP Masquerading, Many-to-One NAT.Суть этого типа в том, что через один внешний адрес выходит наружу много приватных. Этот подход, в отличие от предыдущих, позволяет решить проблему с нехваткой внешних адресов. =Проблемы NAT=* Принцип сетевых адресов никак не вписывается в архитектуру IP, которая подразумевает, что каждый IP-адрес уникальным образом идентифицирует только одну машину в мире.* NAT нарушает «сквозной» принцип, согласно которому каждый хост должен уметь отправлять пакет любому другому хосту в любой момент времени. Поскольку отображение адресов в NAT задается исходящими пакетами, входящие пакеты не принимаются до тех пор, пока не отправлены исходящие.* NAT превращает Интернет из сети без установления соединения в нечто подобное сети, ориентированной на соединение. Проблема в том, что NAT-блок должен поддерживать таблицу отображения для всех соединений, проходящих через него. Запоминать состояние соединения — дело сетей, ориентированных на соединение, но никак не сетей без установления соединений.* При использовании NAT нарушается одно из фундаментальных правил построения многоуровневых протоколов: уровень <tex>k</tex> не должен строить никаких предположений относительно того, что именно уровень <tex>k + 1</tex> поместил в поле полезной нагрузки.* Процессы в Интернете вовсе не обязаны использовать только TCP или UDP. Если пользователь машины <tex>A</tex> решит придумать новый протокол транспортного уровня для общения с пользователем машины <tex>B</tex>, то ему придется как-то бороться с тем, что NAT не сможет корректно обработать поле Порт источника TCP. =Hole punching='''Hole punching''' — метод для прямого соединения двух хостов, которые находятся за NAT-ами. Для инициации соединения требуется третья сторона – сервер, который виден обоим компьютерам. Обычно используются публичные STUN-серверы. '''STUN''' (сокр. от англ. Session Traversal Utilities for NAT, Утилиты прохождения сессий для NAT) — это сетевой протокол, который позволяет клиенту, находящемуся за сервером трансляции адресов (или за несколькими такими серверами), определить свой внешний IP-адрес, способ трансляции адреса и порта во внешней сети, связанный с определённым внутренним номером порта. Эта информация используется для установления соединения UDP между двумя хостами в случае, если они оба находятся за маршрутизатором NAT. ==UDP hole punching=====Алгоритм установления UDP сессии между 2 хостами находящимися за NAT===Hole punching предполагает, что два клиента, <tex>A</tex> и <tex>B</tex>, уже имеют UDP сессию с сервером <tex>S</tex>. Когда клиент начинает сессию с <tex>S</tex>, сервер сохраняет две пары значений для этого клиента: пару IP адрес и UDP порт, которые клиент указывает при отправке пакета в поле отправителя, чтобы говорить с <tex>S</tex>, и пару IP адрес и UDP порт отправителя, которые сервер наблюдает при получении пакета. Первую пару будем называть приватным адресом, а вторую публичным. Приватный адрес сервер может получить от самого клиента в теле сообщения в поле регистрации клиента, а публичный адрес клиента он может посмотреть в поле отправителя в заголовках IP и UDP этого сообщения. Если клиент не за NAT, то его приватный и публичный адрес должны совпадать. Предположим , что клиент <tex>A</tex> хочет установить UDP сессию непосредственно с клиентом <tex>B</tex>. Hole punching происходит следующим образом : * <tex>A</tex> изначально не знает , как связаться с <tex>B</tex>, поэтому <tex>A</tex> просит помощи у <tex>S</tex> в создании UDP сессии с <tex>B</tex>.* <tex>S</tex> отвечает <tex>A</tex> сообщением , содержащим приватный и публичный адрес <tex>B</tex>. В то же время, <tex>S</tex> отправляет сообщение <tex>B</tex> с запросом на соединение, содержащее приватный и публичный адрес <tex>A</tex>. После того, как эти сообщения будут получены, <tex>A</tex> и <tex>B</tex> знают приватные и публичный адреса друг друга.* Когда <tex>A</tex> получает приватный и публиный адреса <tex>B</tex> от <tex>S</tex>, <tex>A</tex> начинает посылать UDP пакеты по обоим адресам, и фиксирует как правильный тот адрес, с которого первым пришел ответ от <tex>B</tex>. Аналогичным образом, когда <tex>B</tex> получает приватный и публичный адрес <tex>A</tex>, он начинает посылать UDP пакеты по обоим адресам. Порядок и время доставки этих сообщений не имеет решающего значения, так как они являются асинхронными. Если <tex>A</tex> и <tex>B</tex> находятся за одним и тем же NAT-ом, то они соединятся через приватные адреса, иначе через публичные. На картинке показан пример, когда <tex>A</tex> и <tex>B</tex> находятся за разными NAT-ами. [[Файл:UDPHolePunching.png]] ==TCP hole punching== ===Алгоритм установления TCP соединения между 2 хостами находящимися за NAT===Предположим, что клиент <tex>A</tex> хочет установить TCP соединение с клиентом <tex>B</tex>. Как и в UDP, мы предполагаем, что у <tex>A</tex> и <tex>B</tex> уже есть TCP соединения с известным сервером <tex>S</tex>. Сервер записывает приватный и публичный адреса каждого зарегистрированного клиента, так же как и для UDP. На уровне протокола, TCP hole punching работает почти так же, как для UDP: * Клиент <tex>A</tex> использует TCP соединение с <tex>S</tex>, чтобы попросить о помощи для подключения к <tex>B</tex>.* <tex>S</tex> отвечает <tex>A</tex>, отправляя приватный и публичный адреса <tex>B</tex>, и в то же время посылает <tex>B</tex> приватный и публичный адреса <tex>A</tex>.* Из тех же самых локальных портов TCP, которые <tex>A</tex> и <tex>B</tex> используют для соединения с <tex>S</tex>, <tex>A</tex> и <tex>B</tex> каждый асинхронно совершают попытки подключения друг к другу по публичному и приватному адресам, и одновременно слушают эти порты на входящие соединения.* Когда TCP соединение устанавливается, клиенты идентифицируют друг друга, чтобы убедиться, что они подключены к нужному клиенту. Если проверка подлинности завершается неудачно, клиенты закрывают эту связь и продолжают ожидание. Клиенты используют первое успешное соединение. В отличие от UDP, где каждый клиент только нуждается в одном сокете, чтобы взаимодействовать с <tex>S</tex> и любым числом хостов одновременно, в TCP приложение должно управлять несколькими сокетами привязаными к одному локальному TCP порту на клиенте. Каждый клиент нуждается в сокете, который соединяет его с <tex>S</tex>, слушающем сокете, который будет принимать входящие соединения, и в двух дополнительных сокетах, с помощью которых клиент будет инициировать исходящие соединения с публичными и приватными TCP адресами другого клиента. [[Файл:TCPHolePunching.png]] ==Источники информации==* Таненбаум Э., Уэзеролл Д. Компьютерные сети. 5-е изд.* [http://www.brynosaurus.com/pub/net/p2pnat/ Bryan Ford, Pyda Srisuresh, Dan Kegel Peer-to-Peer Communication Across Network Address Translators]* [https://ru.wikipedia.org/wiki/STUN STUN]
