NAT или не NAT
«…хотели как лучше, а получилось, как всегда…»
(будем считать, что автор — В.М. Черномырдин)
Не хотелось бы включаться в «религиозные» споры, но с такой темой это становится неизбежным.
Network Address Translation обычно определяют просто: механизм, при котором сетевые адреса в пакетах изменяются при прохождении через границу сети. В классическом варианте — подмена внутреннего IP-адреса и порта на внешний и обратная операция для ответного трафика. В основе лежала идея повторного использования IPv4-адресов в условиях нарастающего дефицита.
Это корректное определение, но оно описывает лишь поверхность. По сути, NAT — это не столько про адреса, сколько про трансляцию идентификаторов между разными доменами управления. Адрес в этом смысле — всего лишь удобный носитель.
Именно поэтому NAT как концепция не ограничен IP.
Задолго до IPv4-дефицита подобная логика использовалась в телефонии, где номер абонента не совпадал с физическим подключением, а сопоставление поддерживалось коммутаторами в состоянии вызова. IPv4 лишь сделал этот подход массовым и наглядным. В нём адрес был одновременно и идентификатором, и маршрутизируемым объектом.
Эта логика и опыт приводились в пример и при обосновании архитектуры, как тогда пытались называть двухуровневые сети в RFC 1287 и RFC 1335, которая привела к возможности появления NAT.
Когда адресов реально стало не хватать, трансляция перестала быть экзотикой и превратилась в норму.
Позже аналогичный метод стал использоваться в корпоративных сетях, прокси-системах, шлюзах приложений. Современные CDN, балансировщики нагрузки, API-шлюзы делают, по сути, то же самое: принимают запрос под одним идентификатором и пересылают его дальше под другим, сохраняя иллюзию прямого соединения.
Пришло время для гнилых помидоров и тухлых яиц…
При этом IETF продолжает игнорировать стандартизацию NAT и включение его в архитектуру сети. При разработке новых стандартов по-прежнему используется принцип прозрачной сквозной связной сети и игнорируется сложившаяся практика и опыт.
Формально NAT был описан в RFC 1631, далее — в RFC 3022. И на этом, по сути, всё. Дальше этой темы лишний раз боялись касаться, она считалась временной мерой/заплаткой, и место в архитектуре формально не было определено. Её по-прежнему боятся, как чёрт ладана, а обсуждение считается дурным вкусом.
Место NAT было переопределено как механизма трансляции между IPv4 и IPv6 и временной меры на момент перехода на «новый» протокол.
Первоначальную аргументацию «за» и «против» перевернули с ног на голову – точнее, все «за» были сведены к нулю, и всё свелось к мантре — полный переход на IPv6 решит все наши проблемы…
Но скорость перехода на IPv6 была явно переоценена, как и возможность построения так называемой идеальной сети по единственному лекалу.
Плюсы NAT изначально формулировали прагматично.
Во-первых, экономия адресного пространства. Это исторически главный мотив. NAT позволил продлить жизнь IPv4 на десятилетия без немедленного пересмотра архитектуры сети. Да и есть ли реальные предпосылки для полного отказа использования в мире IPv4?
Во-вторых, управляемость. NAT создаёт чёткую границу между «внутри» и «снаружи». Эта граница упрощает администрирование, делегирование ответственности и эксплуатацию. Сеть становится объектом управления, а не просто средой передачи.
В-третьих, эксплуатационная устойчивость. За NAT можно менять внутреннюю топологию, адресацию, хосты, не затрагивая внешние сети. Для операторов и платформ это важнее архитектурной чистоты.
Наконец, есть психологический эффект безопасности. Входящие соединения по умолчанию закрыты, и это воспринимается как защита, даже если реальные угрозы давно сместились на уровень приложений и идентичностей.
При этом редко проговаривается, что вместе с границей появляется и асимметрия ролей. Одни узлы могут быть доступными по умолчанию, другие — только инициировать соединения. Эта асимметрия не декларируется как архитектурный принцип, но именно она становится нормой эксплуатации.
Минусы NAT тоже хорошо известны, но важнее то, как именно они проявляются.
Главный из них — разрушение сквозной связности сети. Узел больше не является полноправным участником сети. Он существует лишь постольку, поскольку поддерживается состояние трансляции. Связность становится условной и временной.
Следствие этого — усложнение протоколов. Всё, что требует входящих соединений, сквозной адресации или предсказуемости, начинает нуждаться в обходных механизмах. Эти костыли постепенно перемещаются из сети в приложения, делая их более тяжёлыми и хрупкими.
Ещё один эффект — утрата прозрачности. Когда адрес перестаёт быть устойчивым идентификатором, диагностика, трассировка ответственности и даже правовая атрибуция усложняются. Особенно это заметно в средах с CGNAT, где один внешний адрес разделяют тысячи абонентов. В этот момент NAT перестаёт быть частным инженерным решением и становится частью инфраструктуры — с собственными эксплуатационными, юридическими и социальными последствиями.
Важно то, что NAT нормализует сам факт подмены. Когда трансляция идентификаторов становится базовой практикой, исчезает ожидание прямоты. Приложения проектируются сразу с учётом того, что сеть «нечестная», а адрес — не более чем временная маска.
В этом смысле роль NAT симметрична роли DNS: если DNS решает, какое имя существует в глобальной сети, то NAT решает, какой адрес становится доступным другим сетям.
Попытка заменить NAT чистым IPv6 выглядела логичным ответом: достаточно адресов, возвращение end-to-end, упрощение архитектуры. Но IPv6 пришёл в Интернет, где end-to-end уже перестал быть ценностью сам по себе. В результате NAT как идея не исчез, а просто сменил форму: брандмауэры с поддержкой состояния соединений, префиксная трансляция, сложные политики доступа.
IPv6 устраняет дефицит адресов, но не устраняет необходимость трансляции между доменами управления.
Разные адресные планы будут существовать всегда — а значит, механизмы сопоставления и подмены никуда не денутся, как бы их ни называли.
Поэтому вопрос «NAT или не NAT» давно перестал быть выбором архитектуры. Можно ставить вопрос о том, какой Интернет считается нормальным: сеть автономных узлов или сеть управляемых доменов, соединённых условной связностью.
Практика уже дала ответ. NAT стал не исключением и не ошибкой, а рабочим компромиссом, который слишком хорошо вписался в реальность, чтобы от него отказаться. Он не создал эту реальность, но точно помог её зафиксировать.
Именно поэтому спор вокруг NAT продолжается — не потому, что неясна техника, а потому что за ней стоит выбор, который давно сделан, но до конца не определён.
Вопрос больше не в том, нужен ли NAT. Вопрос в том, готовы ли мы признать, что он стал архитектурной нормой.
Хотя мне непонятно это отрицание очевидного. Для присоединения сетей с разной адресацией (а такие будут всегда) всё равно потребуются шлюзы с трансляцией адресов. Как его ни назови, а NAT останется NATом.
Image for illustration only. Image source: Wikimedia. License: CC BY-SA 4.0
