Перейти к содержанию

NAT — трансляция сетевых адресов

Домашний роутер выпускает десятки устройств в интернет через один адрес провайдера. Для этого он подменяет адреса и порты в каждом пакете и запоминает, кому вернуть ответ. Обратная сторона: устройство за NAT не принимает соединения извне и теряет «тихие» сеансы по таймауту.

Обновлено Редакция GAW

NAT (Network Address Translation, трансляция сетевых адресов) — подмена IP-адресов в пакетах на границе частной сети, чтобы узлы с частными адресами могли обращаться во внешнюю сеть. RFC 3022 называет это «традиционным NAT» и различает два варианта: Basic NAT меняет только адреса, а NAPT (Network Address Port Translation) ещё и транспортный идентификатор — порт TCP или UDP либо идентификатор запроса ICMP. Благодаря NAPT много устройств выходят в интернет через один адрес провайдера; именно он стоит в домашних роутерах.

Как работает привязка

Сеанс TCP или UDP NAT различает по четвёрке «адрес и порт источника, адрес и порт назначения», сеанс ICMP — по адресам и идентификатору запроса (RFC 2663, разд. 2.3). Привязка создаётся при первом исходящем пакете (RFC 3022, разд. 3.1): NAPT запоминает, что паре «локальный адрес, локальный порт» соответствует пара «внешний адрес, назначенный порт», переписывает в пакете адрес источника и порт, пересчитывает суммы заголовка IP и транспортного уровня — в последнюю входит псевдозаголовок с адресами, как у контрольной суммы UDP. Ответный пакет приходит на внешний адрес и назначенный порт, NAT находит привязку и выполняет обратную замену. Когда последний сеанс по привязке завершён, её можно снять (разд. 3.3).

Отсюда главное ограничение: сеансы однонаправленные, из частной сети наружу. Входящий пакет, для которого привязки нет, отбросить проще всего, и RFC 3022 допускает входящие сеансы лишь в порядке исключения — через статическое отображение порта внешнего адреса на конкретный локальный узел. Это и есть «проброс порта» в настройках роутера.

Что NAT требует от устройства

СитуацияЧто происходитИсточник
Сервер хочет подключиться к датчикупривязки нет, SYN отброшен или отфильтрованRFC 3022 разд. 2, RFC 5382 разд. 4.3
Сеанс UDP молчитотображение живёт не меньше 2 мин, рекомендуется 5 мин и болееRFC 4787 REQ-5
Установленный TCP молчитне меньше 2 ч 4 мин, если NAT не умеет проверять концыRFC 5382 REQ-5
TCP в стадии открытия или закрытияне меньше 4 минRFC 5382 REQ-5
Исходящие фрагменты через NAPTпорт есть только в первом фрагменте, трансляция «обречена на отказ»RFC 3022 разд. 6.3

Для контроллера это означает две вещи. Во-первых, соединение всегда инициирует устройство: датчик сам подключается к брокеру MQTT или серверу и держит соединение открытым. Во-вторых, тишина опасна: RFC 4787 требует обновлять таймер отображения исходящими пакетами (REQ-6), а минимальные таймауты из RFC — это требования к роутерам, которым они следуют не всегда. Поэтому долгоживущие соединения поддерживают периодическими пакетами — TCP keep-alive или прикладным механизмом вроде keep alive в MQTT, — и повторно подключаются, если ответ не пришёл. Ещё RFC 4787 требует (REQ-1) одно и то же внешнее отображение для одного локального порта независимо от адресата — на этом строятся методы обхода NAT, когда два устройства узнают свои внешние адреса от третьей стороны.

Что NAT не скрывает и не защищает

Снаружи виден только адрес роутера, адреса частных узлов не видны (RFC 3022, разд. 6.1), но это побочный эффект, а не межсетевой экран: статический проброс открывает узел целиком. Кроме того, NAT лишает адрес IP сквозного значения, поэтому протоколы, передающие адреса внутри данных, через него не работают без помощи шлюза уровня приложения (RFC 3022, разд. 1). Проверка связи командой ping из интернета к устройству за NAT тоже ничего не покажет: ответит в лучшем случае роутер. Маршрут наружу устройство узнаёт через шлюз по умолчанию, которым обычно и является роутер с NAT.

Частые вопросы

Почему к устройству за NAT нельзя подключиться из интернета?

Потому что NAT создаёт привязку адреса и порта только по первому исходящему пакету (RFC 3022, разд. 3.1): пока устройство ничего не отправило, маршрутизатор не знает, кому отдать входящий пакет, и отбрасывает его. По RFC 3022 сеансы традиционного NAT однонаправленные — из частной сети наружу, а входящие допускаются только через статическое отображение порта на конкретный узел («проброс порта»). Поэтому датчик на ESP32 сам подключается к брокеру MQTT или серверу, а не ждёт соединений.

Как долго NAT помнит соединение, если данных нет?

Для UDP RFC 4787 (REQ-5) требует не меньше 2 минут и рекомендует по умолчанию 5 минут и более; обновляет таймер исходящий пакет. Для установленного TCP RFC 5382 (REQ-5) требует не меньше 2 часов 4 минут — это стандартный keep-alive раз в 2 часа плюс 4 минуты на пакеты в пути; для соединений в стадии открытия или закрытия — не меньше 4 минут. Реальные роутеры этим требованиям следуют не всегда, поэтому устройства шлют keep-alive чаще: у MQTT для этого есть свой интервал.

Чем NAT отличается от NAPT?

Basic NAT заменяет только IP-адреса: каждому частному узлу на время сеанса достаётся отдельный внешний адрес из пула. NAPT (Network Address Port Translation) дополнительно переписывает порт TCP/UDP или идентификатор запроса ICMP, поэтому множество узлов делит один внешний адрес — как правило, адрес внешнего интерфейса роутера (RFC 2663, разд. 4.1.2). В домашних и офисных сетях работает именно NAPT, хотя в обиходе его называют просто NAT.

Источники

  1. IETF. RFC 3022 Traditional IP Network Address Translator (Traditional NAT). P. Srisuresh, K. Egevang, January 2001 — разд. 1: все запросы и ответы сеанса должны проходить через один и тот же NAT; NAT лишает IP-адрес сквозного значения; разд. 2: в традиционном NAT сеансы однонаправленные, исходящие из частной сети, входящие допускаются в порядке исключения через статические привязки; Basic NAT транслирует только адреса, NAPT — адрес плюс транспортный идентификатор (порт TCP/UDP или ID запроса ICMP); разд. 2.2: NAPT отображает пары (локальный адрес, локальный порт) в (зарегистрированный адрес, назначенный порт), модель для SOHO с одним адресом от провайдера, входящий доступ возможен статическим отображением локального узла на порт службы; разд. 3.1: привязка создаётся при первом исходящем сеансе; разд. 3.3: когда последний сеанс привязки завершён, привязка может быть снята; разд. 4.1: в каждом пакете меняется адрес IP и сумма IP, в TCP/UDP — сумма (псевдозаголовок содержит адреса), UDP с нулевой суммой не трогают, в NAPT дополнительно порт и ID запроса ICMP; разд. 6.1: адреса частных узлов снаружи не видны; разд. 6.3: исходящие фрагменты TCP/UDP через NAPT обречены на отказ — порт есть только в первом фрагменте
  2. IETF. RFC 2663 IP Network Address Translator (NAT) Terminology and Considerations. P. Srisuresh, M. Holdrege, August 1999 — разд. 2.3: сеанс TCP/UDP однозначно задаётся четвёркой (адрес источника, порт источника, адрес назначения, порт назначения), сеанс запросов ICMP — тройкой с ID запроса; направление сеанса определяет первый пакет; разд. 2.4: TU ports — порты TCP/UDP, диапазон 0–1023 обычно у серверов, клиенты выбирают порт источника из 1024–65535; разд. 4.1.1–4.1.2: Basic NAT и NAPT, в NAPT транспортные идентификаторы многих частных узлов мультиплексируются в один внешний адрес, часто это адрес внешнего интерфейса маршрутизатора
  3. IETF. RFC 4787 (BCP 127) Network Address Translation (NAT) Behavioral Requirements for Unicast UDP. F. Audet, C. Jennings, January 2007 — разд. 4.1, REQ-1: NAT обязан иметь Endpoint-Independent Mapping — одно внешнее отображение для X:x независимо от внешнего адресата; разд. 4.3, REQ-5: таймер отображения UDP не должен истекать раньше 2 минут, рекомендуемое значение по умолчанию — 5 минут и более, исключение — короче для отдельных известных портов 0–1023; REQ-6: исходящий пакет обязан обновлять таймер, входящий — может; разд. 5: фильтрация Endpoint-Independent, Address-Dependent, Address and Port-Dependent; REQ-8: рекомендуется Endpoint-Independent или Address-Dependent
  4. IETF. RFC 5382 (BCP 142) NAT Behavioral Requirements for TCP. S. Guha, K. Biswas, B. Ford, S. Sivakumar, P. Srisuresh, October 2008 — разд. 4.3: NAT может разрешить или отфильтровать входящий SYN на существующее отображение; разд. 5: установленное соединение TCP может молчать неограниченно долго; keep-alive по умолчанию раз в 2 часа (RFC 1122); REQ-5: если NAT не может определить активность концов, таймаут простоя установленного соединения не должен быть меньше 2 часов 4 минут, таймаут переходных фаз (открытие, закрытие) — не меньше 4 минут; обоснование — keep-alive раз в 2 часа плюс 4 минуты на пакеты в пути; при сбросе сеанса NAT может послать RST или молча забыть соединение
Страница помогла?

Нашли ошибку? ·