LINUX.ORG.RU
решено ФорумAdmin

Тупой вопрос про NAT

 , ,


0

1

Предположим, у нас есть роутер. Внешний IP у роутера 132.15.16.17, и он создают локальную подсеть за NAT с диапазоном 192.168.1.0/24.

В этой подсети два устройства: комп 198.168.1.2 и планшет 198.168.1.3. Комп связывается по TCP-IP с внешним IP 80.70.60.50.

При этом с компа отправляется пакет, где отправителем указан 198.168.1.2, а получателем 80.70.60.50. Роутер (NAT), естественно, при отправке пакета во внешнюю сеть меняет отправителя на 132.15.16.17.

Потом 80.70.60.50 шлет ответный пакет, где отправителем указан 80.70.60.50, а получателем 132.15.16.17. Роутер, получив этот пакет, меняет получателя на 198.168.1.2, благодаря чему комп и получает ответ.

Итак, собственно вопрос: откуда роутер (NAT) знает, что получателя в пакете нужно сменить именно с 132.15.16.17 на 198.168.1.2, а не на 198.168.1.3, например?

UPD: изначально я писал про пинги, тогда не знал, что это не то, что обычно в TCP/IP.

★★★★★

Последнее исправление: Vsevolod-linuxoid (всего исправлений: 3)

Потому что соединению соответстует сокет. То есть пара значений: адрес+порт. Соответственно роутер меняет внутренний адрес клиента (192.168.1.2) на свой и клиентский порт (33333) на новый (55555). После чего добавляет у себя в таблицу запись, что то, что придёт ему на этот самый порт надо отправлять внутрь сети на внутренний адрес клиента + клиентский порт. То есть 55555->192.168.1.2:33333.

imul ★★★★★
()
Ответ на: комментарий от imul

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

Vsevolod-linuxoid ★★★★★
() автор топика
Последнее исправление: Vsevolod-linuxoid (всего исправлений: 1)
Ответ на: комментарий от Vsevolod-linuxoid

Разницы нет как использовать. По порядку, с шагом, случайно. Главное что эта информация хранится в таблице и потом по таймауту записи удаляются. Для тебя это важно, случайно, или нет? Залезь в исходники и посмотри.

imul ★★★★★
()

на роутере ядро держит таблицу extip:outport -> intip:port. По ней и определяет, это если по простому.

На самом деле всё несколько сложнее, но тебе это знать не требуется.

Dark_SavanT ★★★★★
()
Ответ на: комментарий от imul

Потому что соединению соответстует сокет.

Сокеты там ни при чем, они не участвуют в этом процессе. Есть всего лишь таблица соответствия до/после трансляции.

И если это ICMP, то матчинг может происходить либо по полю Identifier, либо по данным в пакете, в зависимости от типа.

Deleted
()
Ответ на: комментарий от imul

Ну, вообще-то ты сказал мне, что я хотел узнать: я не знал, что ping по-иному работает. Там другие пакеты?

UPD: да, другие, это отдельный протокол.

Vsevolod-linuxoid ★★★★★
() автор топика
Последнее исправление: Vsevolod-linuxoid (всего исправлений: 1)
Ответ на: комментарий от Vsevolod-linuxoid

ping умеет не только icmp.
Но с icmp там действительно чуть по другому, выше человек написал в чём разница.

imul ★★★★★
()

Роутер (NAT), естественно, при отправке пакета во внешнюю сеть меняет получателя на 132.15.16.17

Наверно отправителя все таки меняет? Или я как то неправильно представляю механизм ната.

N-N
()
Ответ на: комментарий от Dark_SavanT

На самом деле всё несколько сложнее

Какого характера сложность?

Я вроде Таненбаума на эту (и не только) тему читал, особо сложностей не помню)

Twissel ★★★★★
()

Twissel

Более глобально (тут, кажется, про это никто не писал), в Linux есть такой механизм, как connection tracking. Задача этого механизма — сопоставлять пакеты логическим соединениям. В случае (TCP,UDP)/IP это делается по комбинации адресов и портов отправителя и получателя, в случае других протоколов — другими методами.

В Linux информация о применённых (к соединению) NAT-преобразованиях хранится именно внутри этого механизма. Когда приходит ответный пакет, netfilter восстанавливает его принадлежность к конкретному соединению и применяет обратное преобразование.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от intelfx

Дополню.

в Linux есть такой механизм, как connection tracking

Все верно. Даже команда есть conntrack.

В случае (TCP,UDP)/IP это делается по комбинации адресов и портов отправителя и получателя

Плюс всякие «радости» жизни (отдельные модули разбирающие пакеты) для RELATED.

в случае других протоколов — другими методами

И иногда без возможности идентификации, например gre который для двух клиентов через один нат к одному внешнему хосту работать не будет.

anc ★★★★★
()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от intelfx

+ ещё по поводу conntrack. Он умеет NAT'ить довольно сложные штуки типа FTP, анализируя передаваемые данные. Может, например, пропустить входящее related соединение внутрь NAT, если того требует протокол.

Black_Shadow ★★★★★
()
Ответ на: комментарий от Twissel

Ну не учитываются conntrack, детали реализации с udp пакетами и т.д.

Dark_SavanT ★★★★★
()
Ответ на: комментарий от anc

GRE ходить будет, если выставить различные значения поля key.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.