Симметричная пробивка отверстий NAT и UDP

Я читал этот вопрос , но объяснение Symmetric NAT было недостаточно подробным.

Пожалуйста, кто-нибудь может помочь мне понять следующие пункты?

Я читал об симметричном NAT :

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

http://en.wikipedia.org/wiki/Network_address_translation#Types_of_NAT

А это по поводу UDP Hole-punching :

Пробивание UDP-дырок не будет работать с симметричными устройствами NAT (также известными как двунаправленные NAT), которые обычно встречаются в крупных корпоративных сетях. В симметричном NAT сопоставление NAT, связанное с подключением к общеизвестному серверу STUN, ограничено приемом данных от общеизвестного сервера, и поэтому сопоставление NAT, которое видит общеизвестный сервер, не является полезной информацией для конечной точки.

http://en.wikipedia.org/wiki/UDP_hole_punching

Но я на самом деле не поглощаю это. У меня такое ощущение, что это говорит мне о том, что (в клиент-серверном приложении, где клиент инициирует связь) сервер не может связаться обратно другим способом, если это явно не разрешено устройством NAT. Я не понимаю, почему это то, что он говорит. Если это возможно, не могли бы вы немного упростить это описание для меня?

У нас есть проблема в нашей среде, когда известный инструмент удаленной поддержки не может использоваться столь же известным поставщиком программного обеспечения для оказания нам поддержки. Клиент поддерживает прокси-сервер, но для некоторого резонанса он считает, что было бы неплохо не использовать его и делать что-то совершенно другое через UDP на порту 1153.

Из нашего чата ... так что другие могут не получить полный разговор, но основы здесь.

Итак, основной NAT = source address:port >> external address:port >> NAT>> new source address:port >> external address port

с симметричным NAT это статическое отображение и то же самое каждый раз и для источника И для пункта назначения.

Пример: 192.168.100.5:34983 going to 4.2.2.2:53 then REQUIRE it to be 216.222.222.222:44444 with destination 8.8.8.8:333333

«в клиент-серверном приложении, где клиент инициирует связь), сервер не может связаться обратно другим способом, если это явно не разрешено устройством NAT».

та часть, которую вы говорите, неверна, она должна гласить:

в клиент-серверном приложении, где клиент инициирует связь), сервер МОЖЕТ связаться обратно другим способом ПОСЛЕ того, как источник устанавливает сеанс ПО портам, используемым в сеансе.

Это означает, что если 2.2.2.2:43424 переходит к 5.5.5.5:80, то 5.5.5.5:80 отправляет информацию обратно в 2.2.2.2:43424 после установления сеанса. В вашем предложении ... сеанс будет когда-либо только источником сообщения с пунктом назначения, причем пункт назначения никогда не отвечает пакетами / info / graphics / что угодно.

«У нас есть проблема в нашей среде, когда известный инструмент удаленной поддержки не может использоваться столь же известным поставщиком программного обеспечения для оказания нам поддержки. Клиент осведомлен о прокси-сервере, но для некоторого резонанса он считает, что это может быть хорошая идея не использовать его и делать что-то совершенно другое через UDP на порту 1153. "

Это может быть потому, что они просто блокируют Logmein / Teamviewer / что угодно на уровне порта, так как они просят использовать другой порт ... поэтому они думают, что если вы разрешите или будете общаться на 1153, это обойдет их собственные ограничения ИТ ... лучше всего Я могу думать, не зная подробно, что приложение или полные детали. Ничего общего с симметричным пробиванием дырок в NAT или UDP ... по крайней мере, в том, что касается проблемы, которую они поднимают.

Я бы порекомендовал поговорить с их группой поддержки о том, с каким инструментом удаленной поддержки они работают ИЛИ работают с ними, чтобы определить способ использования понравившегося вам инструмента. Если это означает определенные портовые NATing / правила, то вам нужно будет поработать с ними и вашей сетевой командой, чтобы выяснить это.

Надеюсь, что все помогает.

Посмотрите на эти фотографии, сделанные на странице "Перевод сетевых адресов" из Википедии.

В "Full Cone NAT"

1. Как только внутренний адрес (iAddr: iPort) сопоставлен с внешним адресом (eAddr: ePort), любые пакеты из iAddr: iPort отправляются через eAddr: ePort.
2. Любой внешний хост может отправлять пакеты в iAddr: iPort, отправляя пакеты в eAddr: ePort.

В симметричном NAT

1. Каждый запрос с одного и того же внутреннего IP-адреса и порта на определенный IP-адрес и порт назначения сопоставляется с уникальным IP-адресом и портом внешнего источника; если один и тот же внутренний хост отправляет пакет даже с тем же адресом источника и портом, но в другое место назначения, используется другое сопоставление.
2. Только внешний хост, который получает пакет от внутреннего хоста, может отправить пакет обратно.

Теперь давайте обсудим, почему пробивание дырок в UDP не работает в Symmetric NAT. Допустим, Server1 - это сервер STUN, а сервер 2 - это устройство NAT другой частной сети. В дырочном пробивании UDP Клиент соединяется с Сервером1, и на устройстве NAT создается сопоставление портов. Но когда этот клиент подключается к узлу за сервером Server2, устройство NAT создает другое сопоставление портов, как показано на рисунке 2. Сервер1 совместно использует сопоставление портов клиента с узлом за сервером Server2, и с этим сопоставлением портов Server2 не может установить соединение, а Server2 не знает о втором сопоставление портов, созданное устройством NAT.