Как маршрутизатор решает, к какому устройству направлять данные, если на обоих устройствах программы прослушивают один и тот же порт?

287
Rudy

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

Как маршрутизатор узнает, на какое устройство направить запрос на подключение? Оба устройства прослушивают порт 999, но трафик может в конечном итоге попасть только на одно из устройств, не так ли?

Я знаю, что переадресация портов будет правильным способом обеспечить передачу данных на правильное устройство, но что, если конфигурация переадресации портов не настроена? Получает ли пакет отклонение от маршрутизатора, так как он не знает, какое устройство является «правильным» устройством?

0

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

0
David Schwartz

Это зависит от того, как настроен маршрутизатор. Наиболее распространенная конфигурация приводит к тому, что пакет либо игнорируется, либо приводит к сбросу соединения. Как правило, маршрутизаторы SoHo, выполняющие NAT, принимают входящие соединения только в том случае, если переадресация портов специально настроена или соединение осуществляется с самим маршрутизатором.

Одна морщина была бы, если маршрутизатор имеет назначение по умолчанию или настроенную DMZ. В этом случае соединение будет перенаправлено в пункт назначения по умолчанию.

Другая морщина была бы, если бы маршрутизатор поддерживал UPnP. В этом случае соединение будет перенаправлено на любой хост, который первым запросил переадресацию этого порта, если таковой имеется.

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

Это полностью зависит от того, как настроен маршрутизатор и какие функции он поддерживает.

Огромное спасибо. Я слышал термины «запрошенные» и «незапрошенные» данные о маршрутизации пакетов ранее. Где «запрашиваемые» пакеты - это пакеты, которые были запрошены в некоторой емкости, и, следовательно, маршрутизатор знает, куда их вернуть. Будет ли это играть роль в этом уравнении? Rudy 7 лет назад 0
Похоже, что вопрос строго о незапрошенных пакетах, то есть о тех, которые не являются прямым ответом на ранее отправленный исходящий пакет. Запрашиваемые ответные пакеты передаются обратно отправителю пакета, который их запросил, если это не запрещено настройками брандмауэра. David Schwartz 7 лет назад 1
Попался. Я думал, что это так. Существует ли в отрасли термин «запрошенные» и «незапрошенные» пакеты? Я видел, как они называли это в нескольких видео, где я пытался узнать больше о том, как обрабатываются пакеты, но я не нахожу много фактической документации, называющей это «запрашиваемыми» и «незапрошенными» данными. Rudy 7 лет назад 0
Эти термины не так часто встречаются, по крайней мере, по моему опыту. Я чаще слышал термин «ответ». Но я не думаю, что есть какой-либо общий термин для пакета, который не является ответом. David Schwartz 7 лет назад 1
-1
mtak

Для входящих соединений (обратите внимание, что я использую слово соединения, а не пакеты), без какой-либо переадресации порта / настройки UPnP он отклонит или отбросит пакет.

Для исходящих соединений (с использованием SNAT) маршрутизатор будет сохранять «состояние». Он будет проверять все исходящие соединения (для простоты пакет TCP, идущий изнутри наружу с флагом SYN), переписывает исходный адрес / порт в соединение WAN и отправляет пакет дальше. Он знает, для чего он переписал исходный адрес / порт, и когда пакет возвращается, он обратит этот процесс к исходному адресу / порту.

Так что для моего маршрутизатора NAT я бы получил следующую таблицу:

TCP state codes: SS - SYN SENT, SR - SYN RECEIVED, ES - ESTABLISHED, FW - FIN WAIT, CW - CLOSE WAIT, LA - LAST ACK, TW - TIME WAIT, CL - CLOSE, LI - LISTEN  CONN ID Source Destination Protocol TIMEOUT  201805472 10.100.0.95:62110 83.69.0.50:42018 udp [17] 7  213891648 10.100.0.95:43327 176.68.233.117:53228 tcp [6] ES 4631  213891928 10.100.0.95:38139 213.101.14.165:54764 tcp [6] ES 6995  213223160 10.100.0.95:35725 176.68.233.117:53228 tcp [6] ES 386  215913952 10.100.0.1:38340 10.100.0.11:53 udp [17] 8  205319000 10.100.0.95:62110 95.22.94.199:22634 udp [17] 41  214931472 10.100.0.95:60500 213.101.14.165:5524 tcp [6] ES 6478  205547536 10.100.1.26:37992 141.138.198.177:993 tcp [6] ES 7118  387202720 10.100.1.26:58156 141.138.198.177:993 tcp [6] ES 7122  [output omitted] 

Если есть пакет, возвращающийся с 176.68.233.117 с портом назначения 53228, он перезапишет адрес / порт назначения на 10 10.100.0.95:43327.

Это распространяет опасный миф о том, что разрешающего NAT не существует. David Schwartz 7 лет назад 0
Он также делает около 150 других предположений, но мы здесь не для того, чтобы писать полные RFC-совместимые технические руководства ... mtak 7 лет назад 0
За исключением того, что OP * специально * спросил о чем-то, на что влияет разрешающий NAT таким образом, что это может быть удивительно и опасно. David Schwartz 7 лет назад 0

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