пробивание отверстий TCP

Обход TCP NAT и пробивание отверстий TCP (иногда сквозное соединение NAT ) в компьютерных сетях происходит, когда два хоста за трансляцией сетевых адресов (NAT) пытаются подключиться друг к другу с помощью исходящих TCP-соединений. Такой сценарий особенно важен в случае одноранговой связи, такой как передача голоса по IP (VoIP), обмен файлами, телеконференции, системы чата и подобные приложения.

Пробивка отверстий TCP — это экспериментально используемый метод обхода NAT для установления TCP-соединения между двумя узлами в Интернете за устройствами NAT. Обход NAT — это общий термин для методов, которые устанавливают и поддерживают сеть TCP/IP и/или TCP- соединения, проходящие через шлюзы NAT.

Терминология

Далее термины хост, клиент и одноранговый узел используются почти как взаимозаменяемые.

локальная конечная точка , внутренняя конечная точка: локальный IP:порт, видимый локально хостом и внутренней частью NAT.
общедоступная конечная точка , внешняя конечная точка: внешний IP-порт, сопоставленный NAT, видимый сетью и внешней частью NAT.
удаленная конечная точка: IP-порт другого узла, видимый сетью, или внешние части обоих NAT.

Описание

Обход NAT посредством перфорации TCP-дыр устанавливает двунаправленные TCP-соединения между узлами Интернета в частных сетях с использованием NAT. Он работает не со всеми типами NAT, поскольку их поведение не стандартизировано. Когда два хоста подключаются друг к другу по TCP, оба через исходящие соединения, они находятся в случае «одновременного открытия TCP» на диаграмме конечного автомата TCP. ^[1]

Сетевой рисунок

Узел A ←→ Шлюз A (NAT-a) ← .. Сеть .. → Шлюз B (NAT-b) ←→ Узел B

Типы НАТ

Доступность пробивки TCP-дыр зависит от типа выделения портов компьютера , используемого NAT. Для двух одноранговых узлов за NAT для одновременного подключения друг к другу через TCP ^{[ объяснить ]}, им нужно немного знать друг о друге. Одна вещь, которую им абсолютно необходимо знать, — это «местоположение» другого узла или удаленной конечной точки. Удаленная конечная точка — это данные IP-адреса и порта, к которому будет подключаться партнер. Поэтому, когда два узла, A и B, инициируют TCP-соединения путем привязки к локальным портам Pa и Pb соответственно, им необходимо знать порт удаленной конечной точки, сопоставленный NAT, чтобы установить соединение. Когда оба узла находятся за NAT, то, как обнаружить общедоступную удаленную конечную точку другого узла, представляет собой проблему, называемую прогнозированием порта NAT . Все методы обхода TCP NAT и перфорации должны решать проблему прогнозирования портов.

Распределение портов NAT может быть одним из двух:

предсказуемый: шлюз использует простой алгоритм для сопоставления локального порта с портом NAT. Большую часть времени NAT будет использовать сохранение порта , что означает, что локальный порт сопоставляется с тем же портом NAT.
не предсказуемый: шлюзы используют алгоритм, который либо случайен, либо слишком непрактичен для прогнозирования.

В зависимости от того, демонстрируют ли NAT предсказуемое или непрогнозируемое поведение, можно будет или нет выполнить TCP-соединение посредством одновременного открытия TCP, как показано ниже в матрице соединений, представляющей различные случаи и их влияние на сквозное соединение. завершить общение: ^{[ нужна ссылка ]}

	Предсказуемый	Непредсказуемый
Б предсказуемый	ДА	ДА
Б непредсказуемый	ДА	НЕТ

ДА: соединение будет работать постоянно
НЕТ: соединение почти никогда не будет работать

Техники

Методы прогнозирования портов (с предсказуемыми NAT)

Вот некоторые методы, используемые NAT, чтобы позволить узлам выполнять прогнозирование портов:

NAT назначает последовательным внутренним портам последовательные внешние порты : если удаленный узел имеет информацию об одном сопоставлении, то он может угадать значение последующих сопоставлений. TCP-соединение будет происходить в два этапа: сначала одноранговые узлы устанавливают соединение с третьей стороной и изучают свое сопоставление. На втором этапе оба узла могут угадать, каким будет сопоставление портов NAT для всех последующих подключений, что решает задачу прогнозирования портов. Этот метод требует создания как минимум двух последовательных подключений для каждого узла и использования третьей стороны. Этот метод не работает должным образом в случае NAT операторского уровня с большим количеством абонентов за каждым IP-адресом, поскольку доступно только ограниченное количество портов, и выделение последовательных портов одному и тому же внутреннему хосту может быть непрактичным или невозможным.

NAT использует схему распределения с сохранением портов : NAT сопоставляет исходный порт внутреннего узла с тем же общедоступным портом. В этом случае прогнозирование порта тривиально, и узлам просто нужно поменять порт, к которому они привязаны, через другой канал связи (например, UDP или DHT) . ^{[ нужны разъяснения ]}) перед одновременным открытием исходящих соединений TCP. Этот метод требует только одного соединения для каждого узла и не требует, чтобы третья сторона выполняла прогнозирование портов.

NAT использует «независимое от конечной точки сопоставление» : два последовательных TCP-соединения, исходящие из одной внутренней конечной точки, сопоставляются с одной и той же общедоступной конечной точкой. При таком решении одноранговые узлы сначала подключатся к стороннему серверу, который сохранит значение сопоставления портов и передаст обоим узлам значение сопоставления портов другого узла. На втором этапе оба узла будут повторно использовать одну и ту же локальную конечную точку для одновременного открытия TCP друг с другом. К сожалению, это требует использования SO_REUSEADDR в сокетах TCP, и такое использование нарушает стандарт TCP. ^{[ как? ]} и может привести к повреждению данных. Его следует использовать только в том случае, если приложение может защитить себя от такого повреждения данных.

Подробности типичного создания экземпляра TCP-соединения с помощью TCP Hole Punching

Здесь мы предполагаем, что прогнозирование порта уже выполнено с помощью одного из методов, описанных выше, и что каждый узел знает конечную точку удаленного узла. POSIX Оба одноранговых узла выполняют вызов соединения к другой конечной точке однорангового узла. Одновременное открытие TCP произойдет следующим образом:

- Узел A отправляет SYN узлу B.
- Узел B отправляет SYN узлу A.
- Когда NAT-a получает исходящий SYN от узла A, он создает сопоставление в своем конечном автомате.
- Когда NAT-b получает исходящий SYN от узла B, он создает сопоставление в своем конечном автомате.
Оба SYN пересекаются где-то по сетевому пути, тогда:
- SYN от узла A достигает NAT-b, SYN от узла B достигает NAT-a
- В зависимости от времени этих событий (где в сети пересечение SYN),
- по крайней мере один из NAT пропустит входящий SYN и сопоставит его с внутренним узлом назначения.
После получения SYN партнер отправляет обратно SYN+ACK, и соединение устанавливается.

Требования к совместимости NAT для TCP Hole Punching

Другие требования к NAT для обеспечения одновременного открытия TCP

Для одновременного открытия TCP для работы NAT должен:

не отправлять RST в ответ на входящий пакет SYN, который не является частью какого-либо сопоставления
принять входящий SYN для общедоступной конечной точки, если NAT ранее видел исходящий SYN для той же конечной точки

Этого достаточно, чтобы гарантировать корректное поведение NAT при одновременном открытии TCP.

TCP-дырокол и NAT операторского уровня (CGN)

Описанный выше метод прекрасно работает в CGN. CGN также может использовать поведение перегрузки порта , что означает, что разные внутренние конечные точки с одинаковым значением порта могут быть сопоставлены с одной и той же общедоступной конечной точкой. Это не нарушает уникальности $пятерки {протокол, публичный адрес, публичный порт, удалённый адрес, удалённый порт$ } и, как следствие, является приемлемым. TCP Сохранение портов также может привести к случаям, когда порты CGN перегружены и не являются проблемой для работоспособности протокола. Перегрузка портов для TCP позволяет CGN разместить внутри себя больше хостов, сохраняя при этом гарантии сквозной связи TCP.

См. также

Ссылки

^ Институт информационных наук (сентябрь 1981 г.). «Протокол управления передачей: спецификация протокола интернет-программы DARPA» . IETF . Агентство перспективных оборонных исследовательских проектов.

[1] Институт информационных наук (сентябрь 1981 г.). «Протокол управления передачей: спецификация протокола интернет-программы DARPA» . IETF . Агентство перспективных оборонных исследовательских проектов.

[1]