NAT и таблицы NAT

Question

Я пытаюсь понять, как работают таблицы NAT и NAT, но не могу найти ответы в Интернете. У меня есть несколько вопросов относительно NAT. Предположим, TCP соединение установлено.

Предположим, что маршрутизатор имеет WAN 201.22.14.15

1) Допустим, устройство с IP 192.168.1.1 хочет подключиться к серверу с IP 137.132.1.15. Сначала устройство инкапсулирует данные в дейтаграмму IP с IP-адресом источника 192.168.1.1 и IP-адресом назначения 137.132.1.15?

2) После чего дейтаграмма отправляется на маршрутизатор, где происходит NAT. Предполагая, что это первый пакет, отправляемый в частной сети, таблица NAT изначально пуста?

3) Теперь в таблице есть запись, которая отображает 192.168.1.1:1234 на 201.22.14.15:2345. ?

192.168.1.1:1234 -> 201.22.14.15:2345

IP-датаграмма перед отправкой повторно упаковывается с соответствующим адресом маршрутизатора (201.22.14.15) и номером порта 2345. Есть ли отдельное TCP соединение от роутера до сервера? Или запись назначена только виртуальному номеру порта?

4) Данные возвращаются с сервера 137.132.1.15 с IP-адресом dst 201.22.14.15 и портом Dest 2345. Маршрутизатор просматривает таблицу и обнаруживает, что 201.22.14.15:2345 сопоставлен с 192.168.1.1:1234. Таким образом, он перепаковывает IP-датаграмму с адресом src 137.132.1.15:80 и адресом dst 192.168.1.1:1234.

Я не уверен, что шаги, которые я выделил, верны.

Answer 1

Я постараюсь быть простым в объяснении. У вас есть в основном два типа NAT:

• Исходный NAT: обычно известный как «маскарад», он маскирует ваш локальный IP-адрес под его адрес, чтобы он мог связываться с хостами в сетях, которые не знают маршрут к вашей локальной сети.
• NAT назначения: обычно известный как «переадресация портов», он преобразует сетевой адрес назначения в локальный адрес в чужой сети.

Я думаю, что вы описываете источник NAT, ваше общение из локальной сети с сервером в Интернете. И что происходит, как вы сказали, но позвольте мне немного перефразировать:

1. Вы генерируете соединение из локальной сети в Интернет: 192.168.1.1 -> 137.132.1.15:PORT , ваш порт источника является случайным.
2. Исходя из вашей таблицы маршрутизации, на локальном хосте с IP 192.168.1.1 ваш пакет перейдет на следующий переход, обычно это шлюз по умолчанию для интернет-адресов.
3. Когда ваш пакет прибывает на устройство с настроенным NAT источника, он преобразует адрес источника, маскируя источник пакета и преобразуя его в 201.22.14.15 -> 137.132.1.15:PORT . И он будет помнить, что это соединение с вашего локального IP 192.168.1.1.
4. Предположим, что, как и в большинстве случаев, 137.132.1.15 - это брандмауэр, который будет преобразовывать порт назначения PORT в чужую локальную сеть, например 10.0.0.1, и предположим, что это веб-сервер, поэтому он будет транслировать пакет. как 201.22.14.15 -> 10.0.0.1:80 .
5. Затем сервер на 10.0.0.1 получит запрос от 201.22.14.15, и при возврате то же самое произойдет в другом направлении, на основе своей таблицы маршрутизации он вернется к 201.22.14.15.
6. Маршрутизатор / межсетевой экран должен будет маскироваться по-другому, изменяя адреса пакетов как 137.132.1.15 -> 201.22.14.15 .
7. Ваш маршрутизатор на 201.22.14.15 получит пакет, сможет обнаружить, что связано с потоком, сгенерированным 192.168.1.1, и возвратит ответ. 192.168.1.1 увидит пакет из 137.132.1.15, так как 10.0.0.1 был маскирован.

Надеюсь, что это помогает, и это не вызывает больше путаницы.

Примечание

TCP-соединения не организованы в дейтаграммы, они являются потоками. Дейтаграммы являются UDP.

Answer 2

Следующее относится к ядру Linux, но я предполагаю, что MacOS и Windows работают аналогично.

То, что вы называете "таблицей NAT", для краткости называется трекером соединения или conntrack . Есть инструменты, которые вы можете использовать для проверки этой таблицы.

1) да.

2) Да. Если быть точным, таблица отслеживания соединений не имеет записи для этого соединения, она не должна быть пустой. Соединение характеризуется адресом источника, портом источника, адресом назначения и портом назначения; номер порта, к которому он нужен, является дополнительной записью.

3a) Да, где 2345 - это порт, который еще не используется. IIRC по умолчанию использует исходный порт источника. Запись трекера соединения сделана, потому что есть правило iptables с целью SNAT (исходный NAT).

б) Нет, это соединение не отслеживается как обычное TCP-соединение. Трекер соединений netfilter и таблица состояний соединений TCP совершенно разные.

4) Да. Обратите внимание, что не должно быть обратного правила iptables ; это смущает многих людей.