Для пользователей TCP и UDP NAT информация о порте. Для других протоколов, таких как ICMP, он может использовать специальные приемы протокола. Что произойдет, если используется протокол IP, который не обслуживается или не распознается?
Может ли такой пакет даже покинуть целевой интерфейс? Если так, что происходит? IP источника просто меняется? Что происходит на обратном пути? Возможно ли, что возвращаемый пакет может перейти на неправильный IP? Возможно даже все ips доступны?
Для пользователей TCP и UDP NAT информация о порте. Для других протоколов, таких как ICMP, он может использовать специальные приемы протокола.
Ну, те же TCP и UDP также являются "специфическими для протокола" приемами - они на самом деле ничем не отличаются от "идентификаторов запросов" ICMP Echo или "SPI" IPsec. (Сам по себе NAT - это трюк.)
Может ли такой пакет даже покинуть целевой интерфейс? Если так, что происходит? IP источника просто меняется?
Обычно да. Большинство NAT проходят через такие пакеты, даже если они не распознают внутренний протокол, так как у него все же больше шансов на работу, чем "отбросить все".
Что происходит на обратном пути?
Зависит от того, действительно ли NAT отслеживал исходящий пакет. (Различается.)
Даже если NAT не понимает, как извлечь порты или идентификаторы из внутреннего протокола, он все равно может отслеживать тип протокола, что может быть достаточно для некоторых ситуаций. (Каждый IP-пакет имеет поле типа протокола, поэтому то, что вы называете «необработанным IP-адресом», является просто случаем "неизвестного типа протокола IP".)
Например, соединение TCP (протокол IP 6) и пинг ICMP (протокол IP 1, тип ICMP 8) будут отслеживаться как:
host 192.168.1.2 (as 42.0.2.1) → 62.205.132.12 , протокол proto 6 , port 21445 → 80host 192.168.1.2 (as 42.0.2.1) → 62.205.132.12 , proto 1 , type 8 code 0 id 1227Между тем, нераспознанный протокол, такой как 6in4 туннель , будет отслеживаться как:
host 192.168.1.2 (as 42.0.2.1) → 62.205.132.12 , proto 41 , —Следовательно, все входящие пакеты протокола-41 будут перенаправлены обратно на 192.168.1.2 . Это означает, что один компьютер все еще мог говорить по протоколу, но два компьютера одновременно, вероятно, не могли. (Как и в случае с UDP, некоторые NAT также проверяют IP-адрес источника, но многие заботятся только о протоколе и порте.)
В то время как я использовал 6in4 в приведенном выше примере, то же самое будет происходить и со всеми протоколами , что NAT не понимает, даже если у них есть порты (например , UDP-Lite или SCTP).
conntrack -L или cat /proc/net/nf_conntrack чтобы увидеть все отслеживаемые состояния. Некоторые маршрутизаторы даже показывают это в своем веб-интерфейсе.Наконец, если NAT вообще не сохранял никакого состояния, предполагается, что пакет предназначен для самого маршрутизатора (так же, как и для любого другого неотслеживаемого входящего пакета), и обычно отбрасывается на пол.
Возможно ли, что возвращаемый пакет может перейти на неправильный IP?
В простейшем случае нет. Либо NAT может связать возвращаемый пакет с некоторым известным состоянием, либо он не может, но он не будет случайным образом составлять мусор. (Обычно.)
Однако, если два компьютера за локальной сетью пытаются передать один и тот же протокол одному и тому же удаленному хосту, их состояния могут конфликтовать. Победа может отличаться - либо используется самое старое состояние до истечения срока его действия (поэтому ответы на оба компьютера переходят на 1-й), либо они переопределяют друг друга каждые несколько минут (т. Е. Происходит переключение между обоими). Это ситуация, в которой динамический NAT определенно не был предназначен для ...
Возможно даже все ips доступны?
Нет. Теоретически это возможно - например, некоторые люди делают это со статической конфигурацией переадресации портов для Wake-on-LAN - но делать это по умолчанию не очень полезно. Во всяком случае, это сделает вашу локальную сеть более уязвимой для поддельных пакетов.
(Хотя, как это и бывает, именно так работает коммутация Ethernet - пакеты для неизвестных MAC-адресов передаются через все физические порты.)
Как примечание, это фактически не специфично для NAT IPv4. Отслеживание состояния является неотъемлемой частью межсетевого экрана с отслеживанием состояния, используемого как IPv4, так и IPv6. Даже без NAT/PAT отслеживание состояния также позволяет брандмауэру автоматически принимать все известные пакеты и отклонять неизвестные.
Поэтому, когда люди утверждают, что "NAT добавляет безопасность", они на самом деле говорят о конфигурации брандмауэра, которая обычно идет с ним (и может использоваться одинаково хорошо без NAT).
NAT интересная тема.
Существует три типа NAT:
PAT - это то, что используют большинство потребительских маршрутизаторов, так что давайте перейдем к этому.
Давайте представим, что у меня есть этот макет дома:
Router 192.168.0.1
PC 1 192.168.0.2
PC 2 192.168.0.3
External IP 1.1.1.1 (Lets assume I have that one)
Оба моих компьютера хотят подключиться к www.superuser.com с IP-адресом 151.101.65.69.
Я загружаю свой браузер на ПК1 и набираю www.superuser.com, и происходит следующее:
В то же время ПК 2 может перейти на тот же процесс, но, скорее всего, выберет отдельный порт. Маршрутизатор хранит записи об этих номерах портов и перенаправляет трафик по мере необходимости в правильный пункт назначения.
Маршрутизатор будет вести таблицу примерно так:
Source Destination
192.168.0.2:40000 151.101.65.69:80
192.168.0.3:56944 151.101.65:69:80
Теперь вы спрашиваете: «Но, Листер, что произойдет, если выбранный вами случайный номер порта уже используется? Вы сломали систему Lister!«Это совершенно нормально, маршрутизатор увеличивает номер порта в своем списке до следующего доступного, но не забывает отправлять информацию о правильном порте на ПК.