Назад | Перейти на главную страницу

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

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

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

Я читал об этом Симметричный NAT:

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

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

А это про UDP Пробивка отверстий:

Пробивка отверстий 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 после установления сеанса. В вашем предложении ... сеанс будет только источником, связывающимся с местом назначения, с назначением, никогда не отвечающим пакетами / информацией / графикой / чем-то еще.

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

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

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

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

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

В "Full Cone NAT"

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

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

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

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