1632
правки
Изменения
NAT
,rollbackEdits.php mass rollback
=Принцип работы=
Компьютер может быть подключен к Интернету напрямую (белый 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=
Следующий тип имеет несколько названий: 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]
