Вопрос: NAT-клиент и сервер и закрытие портов


Предположим, у меня есть клиент и сервер. Клиент находится за NAT и сервер является общедоступным.

Клиент хочет иметь сессия с сервером.

Предположим, что клиент находится на 192.168.1.1, NAT на 192.168.1.2 личных IP-адресах. И NAT на 50.0.0.1 и сервер на 50.0.0.2 общедоступных IP-адресах.

Клиент отправляет на сервер пакет UDP / IP (надеюсь, он похож на TCP / IP). Этот пакет имеет исходный IP 192.168.1.1, а исходный порт - 1000 (выбранный случайным образом), также имеет порт назначения 50.0.0.2 и порт назначения 2000, поскольку это приложение порта выполняется на сервере.

Пакет TCP / IP поступает в NAT, который изменяет исходный IP-адрес на 50.0.0.1, а порт, например, 5000 (выбирается случайным образом) и маршрутизирует на сервер.

Сервер отправляет пакет ответа с IP-адресом назначения 50.0.0.1 и портом 5000.

NAT изменяет IP-адрес назначения пакета на 192.168.1.1 и порт назначения на 1000.

  1. Теперь, может ли сервер отправлять много пакетов UDP / IP на тот же IP 50.0.0.1 и порт 5000, и все пакеты будут перенаправлены на клиентский порт 192.168.1.1 1000?

  2. Если да, то как долго этот порт 5000 на публичной стороне NAT передает пакеты указанному клиенту?

  3. Только пакеты с источником IP 50.0.0.2 и исходным портом 2000 будет отправлен клиенту?


0
2018-04-17 15:54


Источник


вы спрашиваете о различиях между TCP и UDP в отношении NAT? UDP делает NAT очень разным, чем TCP, поскольку TCP содержит информацию о виртуальной схеме, которая не существует для UDP, поэтому вы не можете сказать, что данный пакет является частью существующего потока. - Frank Thomas
@FrankThomas TCP НЕ содержит информацию о виртуальной схеме - и для этого, по крайней мере, частично, будет разбита динамическая маршрутизация, используемая всеми очень большими провайдерами. techrepublic.com/article/exploring-the-anatomy-of-a-data-packet  показывает содержимое заголовка UDP и TCP и объясняет, как TCP согласовывает надежное соединение (используя подтверждения и последовательности пакетов, а не информацию виртуальной схемы) - davidgo
@FrankThomas не защищать то, что говорит откровенно, поскольку он сказал, что UDP делает NAT абсолютной глупостью, но касается виртуальных схем, где он говорит, что TCP действительно содержит информацию о виртуальной цепи, и вы говорите, что этого не делает. Это говорит о том, что en.wikipedia.org/wiki/Virtual_circuit говорит: «можно использовать TCP как виртуальную схему, поскольку TCP включает в себя нумерацию сегментов, которая позволяет переупорядочивать на стороне приемника, чтобы обеспечить доставку вне заказа». - barlop
@barlop Что вы подразумеваете под «UDP не делает NAT»? И виртуальная схема в том смысле, о которой вы говорите, не совпадает с упоминанием Франка. В вашем тексте речь идет о переупорядочении, которое делает его шов, который пакет поступает через канал (контур). Но UDP и TCP одинаковы в отношении идентификации потока - только по IP и номеру порта (хотя TCP использует как источник, так и пункт назначения и только для адреса UDP). - croraf
ОК, я явно оговорюсь, пожалуйста, замените слово «Соединение» на «виртуальную схему». TCP имеет состояния подключения, управляемые флагами и значениями syn / ack, которые обеспечивают обыденность и непрерывность потока пакетов (например, вы знаете, что все они связаны с одним и тем же потоком, и в каком порядке они должны быть, независимо от того, какой заказ они приходят в). для TCP NAT использует эти характеристики для определения состояний соединения. UDP должен использовать трюки, такие как временные окна и сопоставление адресов, чтобы определить, что пара UDP-пакетов связана друг с другом. - Frank Thomas


Ответы:


ответы:

  1. Да.
  2. Это зависит от реализации NAT для устройства. В Linux это может быть настроено редактирование / proc / sys / net / ipv4 / netfilter / ip_conntrack_udp_ *
  3. Да - если есть «связанные» порты, распознанные NAT, в этом случае дополнительные NAT-модули используются для разработки того, что связано (по крайней мере, в Linux)

3
2018-04-17 16:27