NAT в потребительских маршрутизаторах заставляет маршрутизатор преобразовывать запрос от внутреннего устройства по частному IP (скажем, dev0) и конкретному исходному порту X в запрос от своего собственного общедоступного IP-адреса через другой исходный порт Y. Затем он сохраняет таблицу со списком трансляции, поэтому он знает, что пакет, поступающий в открытый интерфейс через порт Y, должен быть отправлен dev0 на порт X. Это также называется трансляцией адреса порта.

Теперь, насколько я знаю, порт Y будет случайным, неиспользуемым портом на маршрутизаторе. Допустим, на потребительском маршрутизаторе запущена DMZ, указывающая на другое устройство, dev1. Скажем, dev1 запускает приложение на порту Z.

Что происходит, когда NAT в маршрутизаторе преобразует запрос от dev0 в запрос от публичного IP-адреса через порт Z? Я бы предположил, что входящие запросы из публичной сети через порт Z будут перенаправлены на dev0, эффективно отключая эффект DMZ? Как этого можно избежать?

2 ответа2

1

Ваше описание сценария практически безупречно. Однако вы упустили важный момент.

Когда маршрутизатор получает пакет через общедоступный порт (WAN), он переводит не только на основе исходного порта, но и комбинированного IP/ порта источника, это сокет.

Если честно, существует множество различных NAT, я предлагаю вам внимательно прочитать NAT .

0

("1-NAT") Когда входящий трафик получен, NAT будет перенаправлять трафик только тогда, когда входящий трафик поступает с IP-адреса, который является частью того, что обеспечивает таблица NAT. Таким образом, IP-адрес W локального публичного интерфейса на порту Y должен отправляться на dev0 на порту X, но только если трафик поступает от удаленного публичного интерфейса IP T порт U. IP T порт U был помещен в таблицу NAPT (трансляция порта сетевого адреса, также называемая PAT или NAT), когда было установлено первое исходящее TCP-соединение.

Этот фрагмент моего ответа во многом просто перехватывает то, что сказал Даниэль в своем ответе, и (надеюсь) немного больше деталей для ясности. Однако это объяснение все еще оставляет возможность конфликта портов, поскольку, по-видимому, не существует пути для трафика от IP-адреса T к общему интерфейсу W-порт Y, чтобы сделать его в DMZ.

Ну, в дополнение к этому подходу ("1-NAT") я добавляю два других метода ("2-LSTN") и ("3-EPH") , которые могут помочь предотвратить проблему, о которой вы говорите.

Вкратце, в моем последнем абзаце вы увидите, что эта потенциальная проблема вряд ли когда-либо затронет статистически мало людей. (Большинство маршрутизаторов, проданных для дома, предназначены для людей, которые не используют свои собственные серверы.) Те, кто запускает важные серверы, часто не просто перенаправляют все TCP-порты, и поэтому они также не столкнутся с проблемой. Из меньшего числа людей, которые действительно могут быть затронуты, есть варианты, которые технически доступны для тех, кто действительно заботится о настройке параметров конфигурации.

("2-LSTN") Прежде всего, если маршрутизатор настроен с правилом переадресации порта с общедоступным IP-адресом W порт Y, то этот адрес используется TCP. Возможно, не установлено соединение "ESTABLISHED", но оно будет "LISTENING" на порту. Для сравнения попробуйте запустить «netstat -na» в Unix или Microsoft Windows, и вы увидите, что трафик "LISTENING" в *.*.*.*:# (например, *.*.*.*:443 если прослушивается порт HTTPS). Таким образом, маршрутизатор, вероятно, избежал бы отправки трафика через порт Y, если бы он имел это правило переадресации портов для DMZ.

Этот ответ предполагает, что вы только отправляете выбранные порты в тот раздел сети, который обрабатывается как DMZ, и делаете это через переадресацию портов. Если вы просто перенаправляете все порты TCP в DMZ, что является техникой, используемой опцией "DMZ" на некоторых экранах конфигурации маршрутизатора, то это, очевидно, не работает, поскольку маршрутизатор не знает о конкретных службах, которые могут быть предоставляется сервером DMZ. К счастью, у нас есть еще одна потенциальная хитрость.

("3-EPH") Другая вещь, которая помогает в этом, заключается в том, что исходящий порт Y обычно выбирается из списка возможных временных портов (возможно, также известных как "динамические порты"). Исходящий трафик обычно использует случайное число из диапазона эфемерных номеров портов. Диапазон кратковременных портов может варьироваться: IANA предлагает TCP-порт 49152 или выше (до максимального значения 65535 для TCP), и он используется в Microsoft Windows Vista и более поздних версиях и FreeBSD 4.6 и более новых. XP использует, а системы BSD могут использовать от 1025 до 5000 в соответствии со страницей Википедии о портах Ephemeral, или от 1024 до 4999 в соответствии со страницей NcFTP о портах Ephemeral (раздел Microsoft Windows). Linux может использовать от 32768 до 61000. Эти значения настраиваются, как описано более подробно на той странице NcFTP, на которую я ссылался.

Пока устройство выбирает эфемерный диапазон портов, который не конфликтует с услугами, предоставляемыми DMZ, у вас не будет конфликта портов.

Теперь, поскольку большинство людей не вмешиваются в диапазон эфемерного порта своего маршрутизатора, то что абсолютно предотвращает конфликт?

На мой взгляд, ответ "ничего". Однако риск представляется довольно приемлемым с точки зрения бизнеса (например, компании, которая произвела ваш маршрутизатор). Давайте рассмотрим это быстро. Ваши наиболее важные службы (например, HTTP (S) и SSH), вероятно, имеют номера портов в "общеизвестном" диапазоне портов (0-1023), и поэтому эфемерные порты маршрутизатора, вероятно, не будут конфликтовать ("1-NAT") , Для других сервисов, да, существует потенциальная проблема, заключающаяся в том, что исходящий трафик из DMZ может привести к тому, что NAT использует порт, который вы хотите, чтобы DMZ могла слушать. Это повлияет только на систему, к которой подключен исходящий трафик (через NAT), и ваши шансы равны примерно 1 из 16 384, если маршрутизатор использует рекомендованный IANA диапазон портов Ephemeral ("3-EPH") . Это, вероятно, рассматривается как приемлемая игра для статистически небольшого числа людей, которые используют DMZ для портов за пределами хорошо известного (0-1023) диапазона портов, многие из которых, вероятно, используют его для отдельного игрового сеанса (который, вероятно, делает не имеют серьезных финансовых последствий, стоит подать в суд). Если на игрока повлияло, то магия вуду (пробуя случайные вещи, такие как перезагрузка оборудования) вполне может привести к тому, что шанс 1/16384 не произойдет. Для профессиональных соединений, где этот материал имеет значение, у них есть опции, такие как изменение (или настройка) значений, используемых для эфемерного диапазона портов, или, чаще, использование более строгих правил брандмауэра, которые пересылают только определенные необходимые порты, что, вероятно, заставит маршрутизатор знать не использовать этот номер порта ("2-LSTN") .

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .