NAT: как десятки устройств выходят в интернет через один адрес

Публичных адресов IPv4 на всех не хватило — это выяснилось ещё в девяностых, когда стало понятно, что четырёх миллиардов адресов миру мало. Провайдер выдаёт абоненту один адрес, а устройств за роутером может быть два или двадцать.

NAT решает это подменой: роутер на границе сети переписывает в пакетах внутренний адрес на свой публичный, а в ответах проделывает обратную операцию. Для устройств внутри всё прозрачно — они уверены, что общаются с интернетом напрямую. Для интернета все они выглядят как один узел.

• Статический NAT — жёсткое соответствие «один внутренний адрес к одному внешнему». Нужен, когда сервер должен быть доступен снаружи по постоянному адресу.

• Динамический NAT — адреса берутся из пула по мере надобности. Встречается там, где публичных адресов несколько, но меньше, чем устройств.

• PAT — та самая трансляция, которая работает у вас дома. Все внутренние узлы выходят через один адрес, а различаются по номеру порта.

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

Когда приходит ответ на порт 40002, роутер смотрит в таблицу и понимает, что вернуть его нужно на 192.168.1.22. Портов хватает с запасом, поэтому на одном адресе спокойно живут тысячи одновременных соединений.

Записи в таблице создаются в момент, когда кто-то изнутри инициирует соединение. Пакет, прилетевший снаружи сам по себе, роутеру сопоставить не с чем — и он его отбрасывает. Отсюда прямое следствие: ваш домашний сервер не виден из интернета просто потому, что никто не объяснил роутеру, кому передавать входящие.

Попутно это работает как фаервол: неинициированные подключения снаружи не проходят по самой механике трансляции. Считать это полноценной защитой всё же не стоит — NAT не анализирует содержимое и не мешает вредоносному трафику прийти в ответ на ваш же запрос.

Проброс портов

Объясняют роутеру, кому отдавать входящие, правилом проброса: «всё, что пришло на такой-то порт, передавай вот этому внутреннему адресу и порту». Механизм рабочий, но каждое такое правило — открытая дверь наружу.

Минимальная гигиена: пробрасывать только нужные порты, не выставлять наружу панели управления и базы данных, держать службу обновлённой и менять пароли по умолчанию. Отдельно про UPnP — механизм, позволяющий приложениям открывать себе порты самостоятельно. Удобно для игр, но по сути это разрешение любому устройству в сети проделать дыру наружу без вашего ведома.

• Протоколы, передающие адрес внутри данных (классический пример — FTP в активном режиме), через NAT работают криво и требуют отдельных модулей на роутере.

• Прямые соединения между двумя устройствами за разными NAT без посредника не устанавливаются. Отсюда STUN и TURN в видеозвонках и релей-серверы в мессенджерах.

• Сессии живут ограниченное время. Соединение, в котором долго ничего не передаётся, может быть тихо забыто — отсюда keepalive в SSH и мессенджерах.

• В логах внешнего сервиса все ваши устройства выглядят одинаково. Заблокировали по адресу одного — прилетело всем. По той же причине капча иногда требуется всему офису сразу.

• Диагностика усложняется. По дампу на внешнем интерфейсе невозможно понять, какое внутреннее устройство сгенерировало трафик, — нужна таблица трансляций с роутера.

Ситуация, которая ставит в тупик почти каждого, кто впервые пробросил порт. Снаружи всё работает: коллега открывает ваш сервер по публичному адресу без проблем. А из дома, с того же ноутбука, что стоит за тем же роутером, — не открывается.

Причина в маршруте. Пакет с внутреннего адреса уходит на публичный адрес своего же роутера, тот честно транслирует его на внутренний сервер, но сервер отвечает напрямую — он видит, что адрес отправителя из его же сети, и шлюз ему не нужен. Клиент при этом ждёт ответа от публичного адреса, получает его от внутреннего и отбрасывает как неотносящийся к делу.

Решается это функцией, которую называют hairpin NAT или NAT loopback: роутер подменяет ещё и адрес отправителя, чтобы ответ вернулся обратно через него. Часть домашних роутеров умеет это из коробки, часть не умеет вовсе. Обходной путь без настройки роутера — прописать внутренний адрес сервера в локальном DNS или в файле hosts, тогда внутри сети имя будет разрешаться сразу в локальный адрес.

Многие провайдеры выдают абонентам не публичные, а тоже приватные адреса, и трансляция происходит ещё раз уже на их оборудовании. Это CGNAT — carrier-grade NAT.

Узнаётся он просто: адрес на WAN-интерфейсе роутера не совпадает с тем, что показывают сервисы «какой у меня IP», или лежит в специально отведённом диапазоне 100.64.0.0/10. Ещё признак — сервисы вроде удалённого доступа к камерам работают только через облако производителя и наотрез отказываются работать напрямую.

Что с этим делать

Проброс портов в такой схеме не поможет — вы не управляете верхним NAT. Вариантов два. Первый: заказать у провайдера публичный адрес, обычно это небольшая ежемесячная доплата. Второй: пробрасывать доступ через VPN или туннель до внешнего сервера — подойдёт любой дешёвый VPS.

Второй путь нередко оказывается и удобнее, и безопаснее: наружу торчит только защищённый вход, а не набор проброшенных портов к домашним устройствам. Плюс он не зависит от смены провайдера и работает одинаково из любой сети.

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

Мягкий вариант: роутер открыл порт наружу для вашего соединения и принимает на него пакеты от кого угодно. Строгий: принимает только от того адреса и порта, к которому вы обращались изначально. Второй безопаснее, но ломает прямое соединение между игроками — каждый ждёт, что другой обратится первым.

Приложения обходят это через промежуточный сервер: он подсказывает обеим сторонам их внешние адреса и порты, после чего те одновременно шлют пакеты навстречу друг другу, пробивая трансляцию с обеих сторон. Механизм называется STUN. Когда он не срабатывает, трафик идёт через ретранслятор — работает всегда, но добавляет задержку и нагружает чужой сервер.

Если игра или видеосвязь упорно жалуется, порядок действий обычный: проверить, нет ли CGNAT со стороны провайдера, убедиться, что на пути не стоят два NAT подряд (роутер провайдера плюс свой), и при необходимости пробросить нужные порты вручную.