Матвей Чернов

Поставили новый роутер, запустили онлайн-игру или развернули облачный сервер — и снова натыкаетесь на «двойной NAT», бесконечный порт-форвардинг и вместо своего IP видите чей-то 203.0.113.45. Причем железо и провайдеры уже готовы к IPv6, а мы все еще буксуем в прошлом. Зачем вообще понадобился NAT Все уже порядком устали от клише «всемирная паутина» — звучит как старый рингтон. На самом деле интернет — не паутина и даже не улей. Скорее бесконечный гипермаркет, где вместо ценников на товарах приклеены ссылки, а вместо охранников — боты, которые периодически кричат «Вы не пройдете без капчи». Заметили, как они изменились в последнее время? Уже не просто «Найди машину», а «Подумай, что издаст такой же звук» или «Перетащи детали так, чтобы получилась фигура». Но что действительно важно: за всей этой шумихой скрывается набор прописанных договоренностей между нашими устройствами — протоколов, адресов и портов, которые позволяют нам обмениваться данными. IPv4 был создан в эпоху, когда компьютеры считались роскошью, а сеть не была похожа но то, что есть сейчас. 32-битное адресное пространство, 4,3 миллиарда IP-адресов. На бумаге — более чем достаточно. На практике — кризис уже в 1990-х. Почему? Потому что никто не предполагал, что каждая колонка, смарт-часы и даже умная лампочка потребуют собственный IP. NAT (Network Address Translation) появился как ответ на быстрое исчерпание IPv4-адресов. И должен был стать временным решением. Всего лишь костыль, чтобы выиграть время до перехода на IPv6. Но все пошло иначе: костыль превратился в протокол де-факто, а временная мера стала стандартом. Основная идея NAT заключалась в том, чтобы позволить множеству устройств внутри локальной сети использовать один публичный IP-адрес для выхода в интернет. При этом каждому устройству внутри сети выделяется частный IP-адрес из зарезервированных диапазонов (RFC 1918), которые не выгружаются в глобальную сеть. Маршрутизатор с NAT преобразует внутренние адреса в один внешний адрес, подменяя IP-адрес и номер порта в пакетах, что позволяет сотням и даже тысячам клиентов делить один публичный IP. Подход позволил сэкономить ограниченный пул IPv4-адресов и упростил маршрутизацию, так как внешняя сеть видит лишь один адрес, а внутренние устройства остаются скрытыми. Это решение стало важным для продолжения роста интернета в 1990-х и 2000-х годах. Тогда массовое распространение компьютеров и мобильных устройств резко увеличило количество подключенных узлов. Таким образом, большинство сетей работают через NAT, даже если уже поддерживают IPv6. Почему? Привычка. Инерция. Комфорт. Потому что «все работает, значит, менять не нужно». Темная сторона костылей Хороший старый NAT, который долгое время служил спасением, имеет и свою темную сторону, проявляющуюся особенно остро. Одной из главных проблем является так называемый Double NAT. Это ситуация, когда два уровня трансляции адресов накладываются друг на друга. Например, когда домашний роутер подключен к модему провайдера, который тоже работает в режиме NAT. Онлайн-игры, голосовые чаты, P2P — все это начинает работать с перебоями. Проблема не в игре, а в том, что ваш IP «утоплен» под двойной маской, и серверы просто не могут установить прямое соединение. Игроки получают «жесткий» тип NAT, а виртуальные частные сети — нестабильные соединения с повышенной задержкой. И это не баг, а особенность архитектуры, которую мы вынуждены терпеть. Процесс работы CGNAT. Источник. Еще глубже — CGNAT (Carrier-Grade NAT) на уровне провайдеров. Эта технология позволяет провайдерам экономить IPv4-адреса, распределяя один публичный IP сразу на сотни или тысячи абонентов. Результат — вы не можете хостить сервис, потому что порты не принадлежат вам, геолокационные сервисы начинают ошибаться, а VoIP-звонки теряют стабильность. CGNAT не просто усложняет жизнь — он делает пользователей зависимыми от прозрачности инфраструктуры, которой нет. NAT64 — это режим функционирования CGNAT для трансляции адресов IPv6 клиента в публичные (белые) адреса IPv4 из заданного пула. Большинство онлайн-сервисов все еще поддерживают только IPv4. Режим NAT64 необходим для обеспечения прозрачного доступа клиентам, которые используют оборудование IPv6. Источник. А что насчет безопасности? Многие считают, что NAT защищает внутренние устройства, скрывая их за общим IP. Это как аварийный выход на высоте 30 метров — иллюзия безопасности. NAT не шифрует трафик, не аутентифицирует пользователей и не предотвращает атаки на приложения или устройства. Лишь маскирует IP-адреса, создавая ложное чувство защищенности. Особенно уязвимы устройства IoT, которые часто подключаются к интернету за CGNAT и не имеют собственных механизмов безопасности. Классический пример — сотни «умных» лампочек, объединенных под одним CGNAT-адресом. Они могут быть захвачены злоумышленниками и использованы для создания мощных ботнетов, способных запускать масштабные DDoS-атаки. Подробнее про взлом домашних приборов и не только я писал в одной из предыдущих статей. Таким образом, несмотря на свои преимущества в экономии адресов и упрощении маршрутизации, NAT и особенно его операторские варианты создают значительные проблемы для современных сетевых приложений. Это одна из причин, почему переход на IPv6, который избавляет от необходимости в NAT, остается актуальной и необходимой задачей для индустрии. IPv6: переход не по щелчку Когда-то IPv6 обещал интернет без трюков: уникальный адрес на каждое устройство, никакого NAT, прямая маршрутизация. Но реальность оказалась проще и, вместе с тем, сложнее. В 2025 году мы все еще живем в мире, где IPv4 доминирует, а IPv6 — это «ну, типа, поддерживаем». Глобально лишь около 40% хостов способны работать по IPv6. В России этот разрыв еще заметнее. Сети массово используют NAT, а только 10% пользователей могут нативно подключаться по IPv6. Источник. Хотя большинство современных устройств и операционных систем уже много лет поддерживают IPv6 «из коробки», ключевой барьер — инерция провайдеров. Многие ISP, особенно региональные и небольшие, не спешат внедрять IPv6. Они предпочитают экономить ресурсы и использовать NAT для продления жизни IPv4. Это связано и с затратами на обновление инфраструктуры, и с отсутствием прямых стимулов: спрос на IPv6 со стороны конечных пользователей пока невысок, а для бизнеса переход часто означает дорогой апгрейд маршрутизаторов, коммутаторов и обучающих программ для персонала. Даже если провайдер предлагает IPv6, на практике часто встречается полумеры. Например, домашние роутеры, выпущенные за последние 10 лет, формально умеют в IPv6, но их прошивки могут содержать баги, неправильно обрабатывать ICMPv6 или фрагментацию пакетов, а файерволы и IDS иногда некорректно фильтруют новый трафик, что приводит к сбоям и падению производительности. Главный тормоз — огромный пласт старого контента и сервисов, не имеющих IPv6-версий. Десятки миллиардов устройств (особенно IoT, промышленные системы, старые серверы) и тысячи веб-сервисов продолжают работать только по IPv4. Это вынуждает поддерживать dual-stack-сети и арендовать или покупать дорогие IPv4-адреса. Это поддерживает спрос и замедляет отказ от старого протокола. Внедрение IPv6 в каждой стране. Источник. Перспективы, однако, не безоблачны. Крупные игроки — от Google до Cloudflare — давно перешли на IPv6. Это позволяет им снижать задержки и упрощать маршрутизацию. Азия уже достигла 50% возможностей IPv6 благодаря активным инвестициям и государственным инициативам APNIC Blog. По мере исчерпания адресного пула IPv4 и старения legacy-сетей, рост IPv6 станет лавинообразным: со временем среды, поддерживающие только IPv6, заменят dual-stack, а NAT и прокси уйдут в историю. Итак, основные препятствия для внедрения IPv6 заключаются в том, что: региональные ISP продлевают жизнь IPv4 через NAT, поскольку замена инфраструктуры, а также обучение персонала начисто «съедают» бюджет; даже при официально включенном IPv6 многие выбирают IPv4 из-за ошибок первого; миллиарды устройств по всему миру не умеют в IPv6, поэтому сети переключаются в dual-stack, что удваивает сложность и расходы; пользователи не замечают, по какому IP «дают» им тот или иной сайт, а значит, спроса на полноценный IPv6-доступ практически нет. Между двух миров: гибридные решения Dual-stack и его цена Поддержка dual-stack требует, чтобы каждый роутер, сервер и конечное устройство умели «говорить» и по IPv4, и по IPv6 — а значит, дублировать: конфигурации, мониторинг, логирование и администрирование. На примере облачных IP у провайдеров в Европе это выливается в реальные деньги: ежемесячная аренда одного IPv4-адреса стоит до €3 (плавающий IPv4) или €0.50 (статичный IPv4), в то время как IPv6-адрес выделяется бесплатно или за символическую цену в €1 за /64-подсеть. В итоге аренда IPv4 может обходиться в 3, а то и в 10 раз дороже, чем IPv6. Переходные технологии Есть несколько механизмов, призванных снизить нагрузку и отложить «полный» dual-stack. DS-Lite (Dual-Stack Lite) DS-Lite инкапсулирует IPv4-пакеты внутри IPv6-туннеля и выполняет централизованный Carrier-Grade NAT (CGN) на стороне провайдера (AFTR), а на CPE-устройстве (B4) ограничивается только tunneling’ом. Плюсы: не нужно выделять каждому абоненту публичный IPv4-адрес, вся транслитерация сосредоточена в одном месте. Минусы: дополнительные 40 байт overhead на туннель (MTU-проблемы), отсутствие поддержки multicast, зависимость от стабильности AFTR. Архитектура DSL. Источник. NAT64/DNS64 Стандарт для мобильных операторов и провайдеров. DNS64 синтезирует AAAA-записи для IPv6-клиентов на основе A-записей старых сервисов, а NAT64 на граничном маршрутизаторе транслирует IPv6-пакеты в IPv4 и обратно. Плюсы: позволяет IPv6-only хостам обращаться к большинству IPv4-сервисов без туннелей. Минусы: не работает с протоколами, «вшивающими» IPv4-литералы в payload (SIP, FTP без ALG), требует точной настройки MTU и stateful NAT64. 464XLAT Расширяет возможности NAT64: на клиенте (CLAT) применяется stateless SIIT (RFC 6145) для преобразования IPv4-трафика в IPv6, а на стороне провайдера (PLAT) — stateful NAT64 (RFC 6146) обратно в IPv4. Плюсы: поддержка приложений, «жестко» завязанных на IPv4-сокеты и IP-литералы; активно используется в мобильных сетях (3GPP). Минусы: добавляет дополнительный перевал (двойная трансляция), сложнее отлаживать в enterprise-сетях. Путь к чистому IPv6 В случае провайдера необходимо зарегистрировать собственные IPv6-префиксы в BGP, чтобы обеспечить глобальную маршрутизацию новых адресов. Дальше — внедрение автоматической адресации: SLAAC (Stateless Address Autoconfiguration) или DHCPv6, чтобы абоненты получали уникальные IPv6-адреса без ручной настройки. Важно корректно организовать рассылку Router Advertisement (RA) для работы локальных сетей, а для мобильных клиентов — реализовать поддержку PDP (Packet Data Protocol). При этом безопасность должна быть встроена на каждом этапе: фильтрация RA, защита от rogue DHCPv6, настройка firewall для IPv6 — все это уже стандарт индустрии. Важно помнить, что обновление оборудования и программного обеспечения - ключевой этап, иначе часть абонентов останется за бортом современного интернета. Для разработчика приложения нового поколения должны быть нативно готовы к IPv6. Это значит — никаких жестко прописанных IPv4-адресов, только универсальные вызовы, поддержка IPv6-сокетов и правильная реализация socket.bind() для dual-stack или IPv6-only. WebSockets, REST API, peer-to-peer — все должно работать в среде, где IPv4 уже недоступен. Необходимо тестировать приложения на IPv6-only стендах и использовать современные библиотеки, которые корректно работают с обоими протоколами. Такой подход ускоряет отказ от NAT и открывает доступ к новым возможностям сетевой архитектуры. Пользователя может проверить готовность к IPv6 за пару минут. Убедитесь, что ваш провайдер поддерживает IPv6 (например, через test-ipv6.com). Войдите в веб-интерфейс роутера (обычно 192.168.0.1 или 192.168.1.1) и включите поддержку IPv6 в соответствующем разделе настроек. На большинстве моделей это делается буквально одним переключателем. Выберите тип подключения: если провайдер поддерживает «родной» IPv6, используйте Native. Если нет — рассмотрите варианты туннелирования (6to4, 6in4). После активации проверьте, что ваши устройства получают глобальные IPv6-адреса и имеют доступ к сайтам, работающим только по IPv6 (например, ipv6.google.com). Если что-то не работает, обновите прошивку роутера или обратитесь к провайдеру за консультацией. В современных роутерах (TP-Link, ASUS, Netgear, Huawei и др.) настройка IPv6 реализована максимально просто, а подробные инструкции есть на сайтах производителей и у операторов. Взгляд в будущее: IPv6-only и децентрализованная сеть Переход на IPv6-only уничтожит барьер NAT и вернет интернету истинную архитектуру end-to-end. В таких чистых сетях каждый узел получает глобальный адрес и может инициировать прямое соединение без прокладок CGNAT или порт-форвардинга. Это открывает дорогу для WebRTC-пирингов без TURN-серверов, стабильных P2P-приложений и Mesh-сервисов на базе протоколов BATMAN или Babel, где каждый роутер обладает «липким» адресом и участвует в равноправном обмене. Сегодня лидерами по доле IPv6-трафика являются Саудовская Аравия (65,5 %) и Япония (57,7 %), где операторы включают IPv6 по умолчанию и фактически отказались от CGNAT. Эти страны уже зафиксировали в P2P-сценариях двукратное снижение задержек и полный отказ от сложных overlay-решений для multicast. Ключевые технологии будущего «без NAT» уже встроены в IPv6 SLAAC + CGA позволяют узлам авто конфигурироваться и доказывать принадлежность адреса с помощью криптографических ключей, что важно для децентрализованных PKI и безопасной адресации. Secure Neighbor Discovery (SEND) защищает от ARP-спуфинга и rogue-анонсов, обеспечивая проверку подлинности Neighbor Discovery сообщений на уровне железа. Если к 2030 году в IPv6-only сети окажется 60–70 % новых IoT-устройств, то мы станем свидетелями взрывного роста распределенных систем: edge-computing-кластеров, блокчейнов без центральных нод и P2P-хранилищ с нативным шифрованием на сетевом уровне. При этом важно заранее адаптировать системы защиты — масштабировать DDoS-защиту, обновить IDS/IPS для поддержки ICMPv6 и SEND, а также автоматизировать аудит IPv6-ACL.

Матвей Чернов

Материалы автора

Почему многокластерные решения становятся стандартом

Как Kubernetes стал стандартом управления инфраструктурой

Изоляция процессов и минимизация привилегий: Linux namespaces и seccomp

Дерзкие фишинговые схемы, которые сработали