в предыдущей заметке я рассказал о некоторых преимуществах использования IPv6. теоретически конечно такую сеть можно построить и на IPv4, но у большинства регистраторов IPv4 уже закончились, а для такого подхода нужно большое количество адресов, особенно если вы хотите обойтись без NAT.
в IPv6 эта проблема решается сама собой: один префикс /64 это 1.8*10^19 адресов. учитывая что вы для каждой подсети используете /64, а регистрируете достаточно много таких префиксов получается очень удобно: вы один раз зарегистрировали префикс скажем /56 это 64-56 бит префиксов /64 что составляет 256 префиксов /64. такого количества префиксов вам скорей всего хватит навсегда — не нужно что-то перерегистрировать или перенумеровывать сеть.
ну что же отлично IPv6 это удобно, а что делать если мы уже сейчас хотим использовать преимущества IPv6, но нужно сохранить доступ к ресурсам IPv4?
на помощь приходит NAT64. который подменяет старые IPv4 адреса на IPv6. первый этап подмены IPv4 на IPv6 происходит на уровне DNS. второй этап это трансляция на роутере.
т.е. вы набираете в браузере https://vk.ru. на DNS сервер уходит запроc на разрешение адреса vk.ru. возвращаются только записи A (IPv4 адреса). DNS сервер подменяет их записями AAAA (IPv6). т.е. из 32 битного адреса делается 128 битный, дописыванием старших 96 битов. для такой операции обычно используется префикс 64:ff9b::/96, 64:ff9b:1::/48 или ваш собственный. т.е. если вы зарегистрировали префикс 2001:db8:1::/48, то для NAT64 можно зарезервировать префикс 2001:db8:1:ffff::/96.
следующий этап происходит на роутере. работает это так:
узел(клиент) оправляет запрос на «поддельный» IPv6 адрес. пакет с «поддельным» IPv6 попадает на роутер. роутер выполняет обратную операцию. извлекает из «поддельного» IPv6 адреса IPv4 адрес и делает запись в таблице. запись заносится в таблицу трансляции и хранится там до истечения таймаута неактивности. для приходящих на роутер пакетов делается обратная операция: просматривается таблица, запись находится и происходит снова подмена IPv4 адреса на «поддельный» IPv6 адрес из таблицы.
описанная схема (Stateful NAT64) в теории работает безупречно. но на практике нас ждут привычные для любой технологии трансляции «шероховатости», некоторые из которых являются фундаментальными.
первое это конечно что IPv4 адрес может возвращаться не только в A записи.
запись HTTPS (и SVCB). DNS64 должен обрабатывать и эти записи. современные браузеры и приложения используют их для опережающего установления соединения (ESNI, ECH) и указания приоритетных протоколов. и в записи HTTPS могут быть указаны IPv4-адреса (параметр ipv4hint). DNS64 должен просканировать запись HTTPS, найти ipv4hint, синтезировать из них IPv6-адреса (аналогично записи A) и подставить в этот адрес параметр ipv6hint. Это позволяет клиенту сразу установить соединение по IPv6 через NAT64, без лишних DNS-запросов.
не все DNS-серверы с функцией DNS64 умеют корректно обрабатывать записи HTTPS. Это может ломать соединение с некоторыми современными сайтами.
некоторая проблема - запись PTR (обратный DNS): когда кто-то смотрит логи на сервере за NAT64, он видит не настоящий IPv6-адрес клиента, а IPv4-адрес из пула трансляции. как вариант можно настроить в зоне ip6.arpa делегирование для вашего NAT64-префикса на ваш рекурсивный DNS-сервер, который сможет делать обратные запросы для этих синтезированных адресов.
надеюсь понятно, что это все будет работать только с вашим DNS сервером, который выполняет необходимые манипуляции, но клиент может использовать другой DNS сервер. пол беды если сервер использует «открытый» протокол — вам надо просто поймать все такие пакеты и перенаправить на свой сервер. и выполнять необходимые операции принудительно. например правилом:
ip6tables -t nat -A PREROUTING -p udp --dport 53 -j DNAT --to [2001:db8::1]:53
для DoT/DoH такой фокус просто так не пройдёт. клиент может настроить DoH в браузере. проблема в том, что даже если вы поднимите свой DоH сервер и перенаправите туда трафик, то сервер не пройдёт проверку аутентичности, т.к. используются сертификаты обычные для https.
впрочем можно оставить возможность пользователям пользоваться альтернативными DNS серверами по DoT/DoH. но в этом случае пользователь лишится доступа к IPv4-интернету, так как внешние DNS-серверы будут возвращать ему только «родные» IPv4-адреса (A-записи), которые IPv6-only клиент не сможет обработать.
ну и последнее это когда жёстко прописан IPv4 адрес (IP-литерал) например приложение или скрипт обращается к ресурсу не по доменному имени, а напрямую по IP-адресу.
нормального решения для этого случая нет. только частные случаи когда можно что-то подменить и отредактировать на роутере не поломав например при этом проверку аутентичности.
ещё существует проблема протоколов со множественными соединениями: VoIP (SIP), активный режим FTP, некоторые онлайн-игры могут передавать свои IP-адреса и порты внутри служебных сообщений. NAT64 должен иметь редактор для этих протоколов, чтобы подменять эту информацию, что усложняет его и является точкой отказа.
так же возможны проблемы с геолокацией в CDN. т.е вы транслируете географически распределённую сеть из множества префиксов IPv4 в один префикс IPv6.
кроме того например узел p2p имеющий только IPv4 не cможет подключатся к узлам имеющие только IPv6 адрес. впрочем эта проблема не зависит от использования NAT64/DNS64.
т.е. получается что NAT64/DNS64 — это элегантное решение, но это костыль, хоть и достаточно продуманный. решение идеально подходит для доступа к контенту (веб-серфинг, стриминг), но может ломать приложения, работающие с IP-литералами или сложными протоколами.
написано в соавторстве с deepseek.