NAT клиент и сервер, и закрытие порта

313
croraf

Допустим, у меня есть клиент и сервер. Клиент находится за 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
Вы спрашиваете о различиях между TCP и UDP в отношении NAT? UDP выполняет NAT очень иначе, чем TCP, поскольку TCP содержит информацию о виртуальном канале, который не существует для UDP, поэтому вы не можете сказать, что данный пакет является частью существующего потока. Frank Thomas 6 лет назад 1
@FrankThomas TCP не содержит информации о виртуальном канале - и это может, по крайней мере частично, нарушить динамическую маршрутизацию, используемую всеми очень крупными провайдерами. https://www.techrepublic.com/article/exploring-the-anatomy-of-a-data-packet/ показывает содержимое заголовков UDP и TCP и объясняет, как TCP согласовывает надежное соединение (используя подтверждения и последовательности пакетов, не виртуальная схема информации) davidgo 6 лет назад 2
@FrankThomas не защищать то, что говорит Фрэнк, так как он сказал, что UDP делает NAT, что является абсолютной ерундой, но в отношении виртуальных каналов, где он говорит, что TCP действительно содержит информацию о виртуальном канале, а вы говорите, что нет. Это говорит о том, что https://en.wikipedia.org/wiki/Virtual_circuit говорит, что «можно использовать TCP в качестве виртуального канала, поскольку TCP включает нумерацию сегментов, которая позволяет переупорядочивать на стороне получателя для размещения неупорядоченной доставки». «. barlop 6 лет назад 0
@barlop Что вы подразумеваете под "UDP не делает NAT"? И виртуальная схема в том смысле, в котором вы упоминаете, не та, что упоминает Фрэн В вашем тексте речь идет о переупорядочении, в результате чего пакет приходит через канал (канал). Но UDP и TCP одинаковы в отношении идентификации потока - только по IP и номеру порта (хотя TCP использует и источник, и пункт назначения, и только пункт назначения UDP). croraf 6 лет назад 0
@coraf Почему UDP не использует источник и назначение для отслеживания? Я бы подумал, что без отслеживания источника NAT сломался бы довольно плохо (представьте, что несколько устройств за NAT все используют DNS-серверы Google в качестве примера - если вы не отслеживали исходный порт, я не вижу, как это может работать) davidgo 6 лет назад 0
Хорошо, ясно, что я неправильно сказал, пожалуйста, замените слово «Соединение» на «виртуальный канал». TCP имеет состояния подключения, которые контролируются флагами и значениями syn / ack, которые обеспечивают ординальность и непрерывность потока пакетов (например, вы знаете, что все они связаны с одним и тем же потоком, и в каком порядке они должны быть, независимо от того, в каком порядке они прибывают в). для TCP NAT использует эти характеристики для определения состояний соединения. UDP должен использовать такие приемы, как окна синхронизации и сопоставление адресов, чтобы определить, что пара пакетов UDP связана друг с другом. Frank Thomas 6 лет назад 1
@croraf Я никогда не говорил этого, я никогда не говорил этого или нет, пожалуйста, посмотрите, как вы меня цитируете. barlop 6 лет назад 0
@ davidgo Я говорил об идентификации «потока» пакета как концепции TCP / UDP, то есть чтобы узнать, какому потоку UDP принадлежит пакет, он использует только пункт назначения. TCP использует и источник, и пункт назначения. Эта идентификация потока на самом деле является сокетом. Таким образом, TCP не содержит какой-либо специальной идентификации потока по сравнению с UDP. Для «потока NAT» следует использовать как источник, так и пункт назначения. (Извините, немного сложно объяснить, что я имею в виду, но я думаю, что мы на одной странице) croraf 6 лет назад 0
@croraf - я думаю, что мы неправильно общаемся - я утверждаю, что UDP, как и TCP, должен использовать как IP-адрес источника и порт, так и IP-адрес назначения и порт для маршрутизации данных от клиентов к серверу и обратно. Если он не использовал исходный IP-адрес и порт для сопоставления, если у вас есть 2 человека, выполняющих поиск DNS вне NAT, я не вижу, как устройство NAT могло бы определить, какие ответы были для какого клиента. davidgo 6 лет назад 0
@davidgo Согласен! croraf 6 лет назад 0
@barlop "так как он сказал, что UDP делает NAT, что является абсолютной чепухой" croraf 6 лет назад 0
@FrankThomas Чтобы определить «поток ответов» как в UDP, так и в TCP, вы используете исходный IP-адрес и исходный порт возвращаемого пакета (теперь источником является сервер). Никакие порядковые номера или флаги ack / nack вам здесь не помогут. croraf 6 лет назад 0
@croraf UDP и NAT - это две разные вещи (как вы знаете). Существует некоторое взаимодействие / взаимосвязь между NAT и TCP, а также между NAT и UDP. Например, NAPT - это форма NAT, множество людей используют NAPT, и (как мы знаем) NAPT может сказать, что нужно вводить TCP или UDP. на конкретном порту. Но я бы не использовал такой неуклюжий язык, чтобы сказать, что один делает другой, так как говорить такое - неуклюже в лучшем случае, а в худшем (и не только в худшем) - нет смысла. Как аналогия, принтер печатает, я бы не сказал, что принтер делает или не делает человека, это бессвязно. barlop 6 лет назад 0
@ barlop ОК. Теперь я понимаю, о чем ты думал. croraf 6 лет назад 0

1 ответ на вопрос

3
davidgo

ответы:

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

Похожие вопросы