NAT, адресация и развёртывание IPv6

WebRTC видеозвонки требуют прямого соединения обеих сторон — но типичный пользователь находится за двумя слоями NAT. STUN-сервер должен сообщить каждой стороне её публичный IP и порт. TURN-сервер ретранслирует звонок если прямое соединение не удаётся. Понимание почему существует NAT, как он работает и что он ломает — обязательно для любого фулстек-инженера создающего peer-to-peer или real-time функциональность.

Приватная адресация RFC 1918

32-битное адресное пространство IPv4 вмещает ~4,3 млрд адресов. Они закончились. RFC 1918 зарезервировал три диапазона для приватного использования:

Хосты на приватных адресах не могут быть напрямую достигнуты из публичного Интернета. Они могут только инициировать исходящие соединения (после чего NAT-таблица хранит маппинг для ответов).

Network Address Translation (NAT)

NAT (RFC 2663) перезаписывает пакеты на границе сети:

1. Исходящий пакет: source IP (приватный, например 192.168.1.10) + source port (например 45231) → перезаписывается на публичный IP роутера + уникальный source port (например 203.0.113.5:12345). Роутер сохраняет этот маппинг.
2. Входящий ответ: destination IP + port (203.0.113.5:12345) → роутер ищет в NAT-таблице → перезаписывает обратно на 192.168.1.10:45231 и форвардит к внутреннему хосту.

NAT позволил IPv4-интернету вырасти за пределы лимита адресов, но фундаментально сломал end-to-end адресацию: публичный Интернет видит один IP для многих внутренних хостов, и внутренние хосты не могут принимать незапрошенные входящие соединения.

Что ломает NAT:

• Peer-to-peer протоколы (BitTorrent, VoIP, WebRTC): каждая сторона должна иметь возможность инициировать — NAT разрешает только исходящие соединения.
• Port forwarding: нужно настраивать вручную для каждого сервиса который должен быть доступен снаружи.
• Отслеживание злоупотреблений: единственный публичный IP может скрывать сотни несвязанных пользователей.

Carrier-Grade NAT (CGNAT)

Мобильные операторы и ISP развёртывают CGNAT чтобы делить один публичный IPv4-адрес между сотнями или тысячами клиентов:

1. Домашний роутер клиента делает NAT в 100.64.x.x (RFC 6598 shared address space — «пространство адресов NAT64 оператора»).
2. CGNAT оператора делает ещё один NAT на публичный IP.

Двойной NAT усугубляет P2P-проблему. Пользователи CGNAT не могут хостить никакие сервисы на своём IP, и P2P NAT traversal сложнее. Rate-limiting по IP бессмысленен (сотни несвязанных пользователей делят один IP).

Обход NAT: STUN/TURN/ICE

WebRTC и современные P2P-протоколы используют трёхуровневый подход:

• STUN (Session Traversal Utilities for NAT): STUN-сервер сообщает каждому пиру его публичный IP и порт как они видны снаружи NAT. Пиры пытаются соединиться напрямую используя эту информацию.
• TURN (Traversal Using Relays around NAT): если прямое соединение невозможно (например симметричный NAT, CGNAT), TURN-сервер ретранслирует весь трафик. Штраф задержки; только fallback.
• ICE (Interactive Connectivity Establishment): фреймворк который итерирует через STUN-кандидатов, прямые адреса и TURN пока не найдёт работающий путь.

IPv6-адреса: структура и SLAAC

IPv6-адреса — 128 бит, записываются как восемь разделённых двоеточиями hex-групп. Сокращения: ведущие нули опускаются, самый длинный пробег нулей заменяется ::. Пример: 2001:db8::1.

Типичное выделение: префикс /48 для сайта → /64 на подсеть внутри сайта. SLAAC (Stateless Address Autoconfiguration, RFC 4862) позволяет хосту самостоятельно формировать свой адрес:

1. Роутер широковещательно анонсирует /64-префикс в Router Advertisement сообщениях.
2. Хост генерирует нижние 64 бита (interface ID) — изначально EUI-64 из MAC-адреса, теперь случайный для приватности (расширения приватности RFC 8981).
3. Хост проверяет дубликаты (Duplicate Address Detection), затем начинает использовать адрес.
4. DHCP не требуется для базового подключения.

Расширения приватности (RFC 8981) рандомизируют interface ID per site для предотвращения кросс-сайтового отслеживания через IPv6-адреса. Современные ОС включают это по умолчанию.

Anycast: один IP, много локаций

Anycast анонсирует один и тот же IP-префикс из нескольких географических локаций. BGP маршрутизирует каждого пользователя в POP с наикратчайшим AS-path. Применения: DNS-резолверы (1.1.1.1, 8.8.8.8), CDN edge’ы, корневые серверы имён, сервисы защищённые от DDoS.

Anycast хорошо работает для stateless-сервисов (UDP DNS) — каждый пакет может идти в другой POP. Для stateful-сервисов (TCP, TLS) короткие флоу нормальны (BGP-маршрутизация стабильна в течение соединения), но длинные флоу требуют либо стабильного BGP, либо репликации состояния сессии между POP’ами (Cloudflare поэтому глобально реплицирует TLS-сессионные тикеты).

Dual-stack и Happy Eyeballs

Большинство текущих развёртываний работают на dual-stack: одновременно включены IPv4 и IPv6. IPv6 в приоритете для доставки контента, IPv4 как fallback.

Happy Eyeballs v2 (RFC 8305): когда dual-stack хост резолвит имя хоста, он параллельно запускает попытки подключения по IPv4 и IPv6 с небольшим форой для IPv6. Если IPv6 успевает первым — использовать его; если IPv4 побеждает или IPv6 зависает — использовать IPv4, незаметно, без видимой пользователю задержки. Это делает принятие IPv6 безопасным даже когда пути IPv6 имеют периодические проблемы.