NAT: как решение проблемы IP-адресов случайно централизовало интернет

NAT (Network Address Translation, трансляция сетевых адресов) была впервые формально предложена в RFC 1631 в 1994 году как краткосрочное решение проблемы нехватки IP-адресов и масштабирования маршрутизации. Автор эссе цитирует аннотацию RFC 1631: две самые насущные проблемы IP-интернета, истощение адресного пространства и масштабирование маршрутизации; краткосрочным решением была названа CIDR (бесклассовая междоменная маршрутизация), а долгосрочным, переход на новые протоколы с более длинными адресами, то есть IPv6.

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

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

Проброс портов (port forwarding), ручная настройка маршрутизатора, чтобы пакеты с заданного порта уходили на конкретное устройство. Один публичный IP+порт может быть привязан только к одному устройству одновременно, поэтому на крупных корпоративных и университетских сетях, сведённых к малому числу приватных адресов, обычный проброс портов фактически не работает. Если же провайдер сам держит клиента за NAT (carrier-grade NAT, CGNAT), пользователь не управляет устройством, которое выполняет трансляцию, и пробросить порт не может вовсе.
UPnP и его аналоги (NAT-PMP, PCP), позволяют программам самим просить маршрутизатор открыть порт, но по-прежнему зависят от провайдера и часто отключены из соображений безопасности.
STUN, сервер в публичном интернете сообщает устройству, каким его пакет выглядит снаружи (публичный IP и порт). При «конусном» NAT, где внешнее отображение порта одинаково для всех исходящих соединений, это работает и позволяет установить прямое соединение («пробивание дыр», hole punching). При «симметричном» NAT, распространённом на CGNAT и в институциональных сетях, для каждого нового адресата назначается новый публичный порт, и данные STUN-сервера для установления прямого соединения становятся бесполезны.
TURN, трафик просто пускают через сервер-ретранслятор, к которому оба участника подключаются исходящими соединениями. Работает почти везде, но требует отдельного сервера и добавляет задержку на каждый пакет.
ICE, перебирает все варианты по порядку предпочтения (прямое соединение, адрес от STUN, ретранслятор TURN) и использует первый, который сработал; именно так устроен WebRTC. По оценке автора, это лучшее, что доступно в сегодняшнем интернете, но взамен простого прямого соединения приходится полагаться на внешнюю инфраструктуру.

Долгосрочным решением, на которое рассчитывал RFC 1631, был IPv6, с адресным пространством, достаточным, чтобы дать каждому устройству по-настоящему уникальный глобальный адрес и сделать NAT ненужным. Но, по словам автора, темп внедрения IPv6 как будто застопорился слишком рано, и даже там, где IPv6 внедрён, многие провайдеры и институциональные сети по инерции продолжают делать NAT-подобные вещи: блокировать входящие соединения просто потому что «так делает NAT», или применять настоящий NAT даже к IPv6-адресам, например, разворачивать Unique Local Addresses (fc00::/7) так же, как приватные адреса RFC 1918 в IPv4-сетях, что автор называет странным решением.

Вывод автора: среди множества причин, убивших открытый пиринговый интернет и приведших к господству закрытых централизованных платформ, NAT был одной из самых ранних. Раньше запустить сервер было тривиально: запустить исполняемый файл, сообщить людям адрес, и всё. Сейчас, в лучшем случае, нужно настраивать проброс портов, а за CGNAT или в институциональной сети это часто вообще невозможно. NAT также приучил всех считать модель «клиент, облако» естественной, хотя на деле это лишь следствие нехватки адресов. При этом NAT парадоксально стали воспринимать как средство защиты («ваши устройства скрыты!»), и именно это заставляло людей сопротивляться решению (IPv6), которое могло бы всё исправить. Из-за NAT, по мнению автора, сложно просто отправить файл другому человеку напрямую, поэтому почти никто не держит почту на своём компьютере, а держать собственные сервисы вообще дорого и сложно: если провайдер не даёт пробросить порт с домашнего подключения, приходится покупать VPS вместо того, чтобы использовать уже имеющееся дома железо.

Ключевые факты

NAT впервые формально предложена в RFC 1631 (1994) как краткосрочное решение нехватки IP-адресов; долгосрочным решением задумывался переход на IPv6.
NAT мешает внешнему серверу первым установить соединение с устройством за ним, отсюда экосистема обходных технологий: проброс портов, UPnP, STUN, TURN, ICE.
При симметричном NAT (в том числе carrier-grade NAT у провайдеров) STUN не помогает, потому что каждому новому адресату присваивается новый публичный порт.
IPv6, который должен был устранить NAT, по словам автора, внедряется медленнее ожидаемого, а некоторые сети применяют NAT-подобные ограничения даже к IPv6-адресам.
Автор считает NAT одной из самых ранних причин централизации интернета: без него запуск личного сервера был бы обычным делом, а не тем, что требует покупки VPS.

Почему это важно

Эссе показывает конкретный технический механизм, из-за которого сегодняшний интернет устроен вокруг центральных «облачных» сервисов, а не прямых соединений между пользователями. NAT, решение временной проблемы 1994 года (нехватки IPv4-адресов), стало, по мнению автора, одной из первых причин, приучивших индустрию и пользователей к модели «клиент, центральный сервер», хотя изначальная архитектура интернета была пиринговой.

Кому это важно

Сетевым инженерам и разработчикам, работающим с P2P-протоколами, WebRTC и самостоятельным хостингом; людям, которые хотят держать личный, игровой или почтовый сервер дома, но упираются в CGNAT или ограничения институциональной сети; тем, кто интересуется историей и архитектурой интернета и причинами его сегодняшней централизации вокруг больших облачных платформ.

Как это применить

Для установления прямого соединения между двумя устройствами за NAT автор описывает набор техник по возрастанию сложности: проброс портов или UPnP/NAT-PMP/PCP на маршрутизаторе, если провайдер это позволяет; STUN, для «конусного» NAT; TURN-релей как резервный вариант; либо связка ICE, которая перебирает все варианты сама (именно так работает WebRTC). Если провайдер держит подключение за carrier-grade NAT, ни проброс портов, ни UPnP не сработают, остаются только STUN/TURN/ICE или переход на VPS.

Можно ли доверять

Это личное эссе на персональном сайте автора (dreamstation.systems), а не публикация в рецензируемом издании, оценка роли NAT в централизации интернета отражает точку зрения автора и не подкреплена внешними источниками или цифрами. При этом историческая часть (год и номер RFC, формулировка проблемы в его аннотации) точна и проверяема, а описание технологий NAT, UPnP, STUN, TURN и ICE соответствует их реальному устройству. Имя автора в тексте не указано.

Риски и подводные камни

Автор прямо признаёт, что NAT, не единственная причина централизации интернета, а лишь одна из самых ранних; вклад NAT по сравнению с другими факторами (экономика облачных платформ, соображения безопасности, удобство) в эссе не измеряется и остаётся оценочным утверждением. Конкретных цифр по текущему уровню внедрения IPv6 в тексте нет, тезис о «застопорившемся росте» не подкреплён статистикой.

«Две самые насущные проблемы IP-интернета, истощение адресного пространства и масштабирование маршрутизации. Разрабатываются как долгосрочные, так и краткосрочные решения этих проблем. Краткосрочное решение, CIDR (бесклассовая междоменная маршрутизация). Долгосрочные решения, это различные предложения по новым интернет-протоколам с более длинными адресами.»

— RFC 1631 (1994), в цитате автора эссе