IPv6 в мобильных сетях: 464XLAT, NAT64 и DNS64 простыми словами

Представьте странную картину. Вы открываете на телефоне сервис проверки IP, и он показывает адрес IPv4. Но если заглянуть в настройки сетевого интерфейса того же устройства, там будет красоваться длинный адрес IPv6. Как так? Устройство живет в мире IPv6, а сайт в своих логах уверенно записывает четыре десятичных числа через точку. Где же произошла подмена?

Это не баг и не магия. Это тщательно спроектированная система трансляции, которую операторы связи разворачивают по всему миру уже больше десяти лет. И если вы работаете с мобильными прокси, парсингом, мультиаккаунтингом или просто хотите понимать, что происходит с вашим трафиком, разобраться в этой механике критически важно.

В этом руководстве мы пройдем весь путь пакета от приложения на телефоне до целевого сайта. Разберем 464XLAT по компонентам, поймем роль NAT64 и DNS64, увидим, где именно рождается выходной IPv4-адрес, и научимся диагностировать стек соединения своими руками. Это не поверхностный обзор. Это глубокое погружение для тех, кто хочет знать не только что происходит, но и как, и почему.

Введение: почему телефон получает IPv6, а сайт видит IPv4

Начнем с сути парадокса. Современный смартфон в мобильной сети крупного оператора почти наверняка подключен по IPv6. Более того, у него зачастую вообще нет настоящего адреса IPv4 на радиоинтерфейсе. Оператор просто не выдает его. И это осознанное решение, продиктованное жестким дефицитом адресного пространства.

Но интернет неоднороден. Огромное количество сайтов, API и сервисов до сих пор доступны только по IPv4. У них нет AAAA-записи в DNS, их серверы не слушают IPv6. Если бы телефон умел говорить исключительно на IPv6, он не смог бы открыть половину интернета. Возникает противоречие: устройство говорит на новом языке, а собеседник понимает только старый.

Решение этого противоречия и есть главная тема нашего разговора. Технология под названием 464XLAT вместе с механизмами NAT64 и DNS64 создает невидимый мост. Устройство отправляет пакеты по IPv6, а где-то в глубине сети оператора эти пакеты превращаются в IPv4 и уходят к целевому серверу уже с настоящим IPv4-адресом. Сервер отвечает, и обратный путь проходит ту же трансформацию в зеркальном порядке.

Именно поэтому целевой сайт видит IPv4. Именно поэтому мобильный прокси, построенный на реальном телефоне или модеме оператора, отдает наружу адрес IPv4, хотя внутри устройства царит IPv6. Подмена происходит не на телефоне и не на сайте. Она происходит в промежуточном узле сети оператора, который называется PLAT.

Что вы узнаете, дочитав до конца:

• Как устроен дефицит адресов IPv4 и почему он заставил операторов перейти на IPv6
• Что такое типы APN и чем IPv4v6 отличается от чистого IPv6
• Как работает 464XLAT по шагам, где живет CLAT, а где PLAT
• Как NAT64 и DNS64 делают доступным сайт без AAAA-записи
• Откуда берется выходной IPv4-адрес мобильного прокси
• Как happy eyeballs заставляет сервис проверки показывать то IPv4, то IPv6
• Практические команды диагностики стека соединения
• Почему подсеть /64 воспринимается как один клиент и что это значит для аккаунтов

Договоримся сразу о границах. Мы говорим исключительно про сетевую механику. Мы не обсуждаем, что выгоднее покупать и какой протокол лучше с коммерческой точки зрения. Это инженерное руководство, а не рыночный обзор.

Основы: дефицит IPv4, переход на IPv6 и типы APN

Чтобы понять всю конструкцию, начнем с фундамента. А фундамент здесь один - катастрофическая нехватка адресов IPv4.

Почему IPv4 закончился

Протокол IPv4 использует 32-битные адреса. Это дает около 4,3 миллиарда уникальных комбинаций. В 1981 году, когда протокол стандартизировали, это казалось астрономическим числом. Кто мог представить, что устройств станет больше, чем людей на планете?

Реальность оказалась суровой. Смартфоны, планшеты, умные часы, холодильники, камеры, автомобили - все требует адреса. К началу 2010-х годов региональные интернет-регистраторы начали исчерпывать свободные блоки. Сегодня получить крупный блок белых IPv4-адресов практически невозможно, а на вторичном рынке они торгуются по десятки долларов за штуку.

Для мобильного оператора с десятками миллионов абонентов это фундаментальная проблема. Выдать каждому смартфону персональный публичный IPv4 нереально физически. Адресов просто не хватит.

Как IPv6 решает проблему

Протокол IPv6 использует 128-битные адреса. Число возможных комбинаций настолько велико, что человеческий мозг отказывается его воспринимать - это примерно 340 ундециллионов адресов. Условно говоря, можно выдать по несколько адресов на каждый атом на поверхности Земли и еще останется.

Оператор получает от регистратора огромный блок IPv6 и раздает абонентам с колоссальным запасом. Типичная практика - выделить каждому абонентскому устройству целую подсеть /64. Это, на минуточку, 18 квинтиллионов адресов на один телефон. Запомните этот факт, он сыграет важную роль в разделе про мультиаккаунтинг.

Что такое APN и зачем нужны его типы

APN расшифровывается как Access Point Name, то есть имя точки доступа. Это конфигурационный профиль, который сообщает телефону, как подключаться к пакетной сети оператора. Когда смартфон устанавливает передачу данных, он запрашивает у сети создание сессии с определенным типом протокола.

Существует три основных типа PDN или PDP-контекста:

• IPv4 - устройству назначается только адрес IPv4. Классическая устаревшая схема. Работает, но требует адресов, которых нет.
• IPv6 - устройству назначается только префикс IPv6. Никакого IPv4 на интерфейсе нет вообще. Максимально экономно для оператора.
• IPv4v6 - двойной стек. Устройство запрашивает оба типа адресов сразу в рамках одной сессии.

Вот тут возникает тонкость. Даже если телефон запрашивает IPv4v6, оператор может отдать только IPv6-часть, а в IPv4-части отказать или выдать частный адрес через механизм трансляции. Многие крупные операторы настроены так, что абонент по умолчанию получает чистый IPv6, а совместимость с IPv4-интернетом обеспечивается уже описанной технологией 464XLAT.

Аналогия, которая помогает. Представьте, что весь мир перешел на новый язык общения, но множество старых учреждений принимают документы только на старом. Государство не может выдать каждому гражданину персональный старый паспорт - их не хватает. Поэтому оно выдает всем новые документы, а на входе в старые учреждения ставит переводчика. Этот переводчик и есть 464XLAT.

Глубокое погружение: 464XLAT по компонентам

Теперь мы готовы препарировать саму технологию. Название 464XLAT читается как four-six-four translation. Цифры отражают суть: пакет начинает жизнь как IPv4 внутри приложения, путешествует по сети как IPv6, а затем снова становится IPv4 на выходе. XLAT - это сокращение от translation, трансляция.

В основе лежит стандарт трансляции адресов между протоколами, описанный в спецификациях IETF. Но 464XLAT добавляет к нему архитектуру из двух компонентов, работающих в паре.

CLAT - переводчик на устройстве

CLAT означает Customer-side translator, то есть транслятор на стороне клиента. Он живет прямо на вашем смартфоне, встроенный в операционную систему. В Android эту функцию выполняет специальный демон, в других системах - аналогичные модули.

Задача CLAT одна, но важная. Когда приложение на телефоне хочет отправить пакет по IPv4 - например, оно жестко использует IPv4-сокет или обращается к IP-адресу напрямую - CLAT перехватывает этот IPv4-пакет и заворачивает его в IPv6. Технически он выполняет трансляцию заголовков по алгоритму stateless-трансляции, преобразуя IPv4-адрес источника и назначения в соответствующие IPv6-адреса с использованием заранее известного префикса.

CLAT создает на устройстве виртуальный сетевой интерфейс, которому назначен приватный IPv4-адрес. Приложения видят этот адрес и думают, что живут в нормальной IPv4-среде. Они даже не подозревают, что под капотом все давно переехало на IPv6.

PLAT - переводчик в сети оператора

PLAT означает Provider-side translator, транслятор на стороне провайдера. Это мощный узел где-то в ядре сети оператора, реализующий функцию NAT64. Именно здесь происходит финальное превращение.

PLAT принимает IPv6-пакеты, которые пришли от устройства, и извлекает из них информацию об исходном IPv4-назначении. Затем он выполняет stateful-трансляцию: превращает IPv6-пакет обратно в IPv4-пакет, подставляет в качестве адреса источника один из публичных IPv4-адресов оператора из своего пула и отправляет пакет в обычный IPv4-интернет.

Ключевое слово - stateful, то есть с сохранением состояния. PLAT ведет таблицу соответствий, чтобы обратные пакеты от сервера правильно вернулись именно тому устройству, которое инициировало соединение. Это по сути тот же принцип, что в классическом NAT, только между разными протоколами.

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

Возникает резонный вопрос: зачем нужен CLAT на устройстве, если PLAT все равно все переведет? Ответ в приложениях, которые не умеют в IPv6.

Многие приложения написаны с жестким использованием IPv4. Они запрашивают IPv4-сокет, работают с IPv4-литералами адресов, некоторые протоколы вроде старых реализаций передают IP-адреса внутри полезной нагрузки. Если бы на устройстве был только чистый IPv6, такие приложения просто сломались бы. CLAT дает им иллюзию полноценной IPv4-среды, оставаясь при этом невидимым.

Таким образом, связка работает так: CLAT решает проблему совместимости на устройстве, PLAT решает проблему совместимости в интернете. Вместе они образуют бесшовный мост.

NAT64 и DNS64: как оживает сайт без AAAA-записи

Мы разобрались с трансляцией пакетов. Но есть еще одна фундаментальная проблема - как устройство вообще узнает, куда отправлять IPv6-пакет, если целевой сайт существует только в IPv4-мире и не имеет никакой IPv6-записи?

Здесь на сцену выходит дуэт NAT64 и DNS64. Они работают в тесной связке, и понять один без другого невозможно.

Проблема отсутствующей AAAA-записи

В системе доменных имен адреса разных протоколов хранятся в разных типах записей. Адрес IPv4 хранится в записи типа A. Адрес IPv6 хранится в записи типа AAAA, которую произносят как quad-A.

Когда чисто-IPv6 устройство хочет открыть сайт, оно запрашивает у DNS запись AAAA. Но если у сайта нет IPv6-инфраструктуры, то и AAAA-записи у него нет. Есть только запись A с IPv4-адресом. Устройство получает пустой ответ и в теории должно сказать: сайт недоступен. Но этого не происходит благодаря DNS64.

Как работает DNS64

DNS64 - это специальный DNS-резолвер оператора с суперспособностью. Когда устройство запрашивает AAAA-запись для домена, а настоящей AAAA-записи не существует, DNS64 не сдается. Он делает следующее:

1. Запрашивает у авторитетного сервера обычную запись A и получает IPv4-адрес сайта
2. Берет этот IPv4-адрес и синтезирует из него искусственную AAAA-запись
3. Для синтеза он встраивает 32 бита IPv4-адреса в специальный IPv6-префикс
4. Возвращает эту синтезированную AAAA-запись устройству как ни в чем не бывало

Устройство получает валидный IPv6-адрес и радостно отправляет по нему пакеты. Оно не знает и не должно знать, что этот адрес искусственный.

Синтезированный префикс 64:ff9b::/96

Вот мы и добрались до одного из самых узнаваемых артефактов всей системы. Для синтеза адресов используется специально зарезервированный префикс 64:ff9b::/96. Он называется Well-Known Prefix, то есть общеизвестный префикс, и стандартизирован именно для трансляции NAT64.

Механика проста и элегантна. Префикс занимает первые 96 бит адреса. Оставшиеся 32 бита - это ровно размер IPv4-адреса. DNS64 просто дописывает IPv4-адрес сайта в конец префикса.

Например, если у сайта IPv4-адрес выражается четырьмя числами, то синтезированный IPv6-адрес будет выглядеть как префикс 64:ff9b, за которым в последних 32 битах закодированы эти четыре числа. Когда такой пакет доходит до PLAT, узел видит знакомый префикс, понимает, что это трансляция NAT64, извлекает последние 32 бита и получает настоящий IPv4-адрес назначения. Дальше он отправляет обычный IPv4-пакет.

Некоторые операторы вместо общеизвестного префикса используют собственный сетевой префикс из своего адресного пространства. Логика та же, меняется только конкретное значение первых битов.

Как связка работает вместе

Сложим пазл. DNS64 отвечает за то, чтобы устройство получило IPv6-адрес для похода в IPv4-интернет. NAT64 в лице PLAT отвечает за то, чтобы пакет по этому адресу реально дошел до IPv4-сервера. Один без другого бесполезен: DNS64 создает адрес, который умеет обработать только NAT64, а NAT64 обрабатывает только те адреса, которые синтезировал DNS64.

А что происходит с сайтами, у которых есть настоящая AAAA-запись? Здесь все проще. DNS64 видит реальную AAAA-запись и просто отдает ее без всякого синтеза. Устройство соединяется с сайтом напрямую по IPv6, минуя всю трансляционную машинерию. Это оптимальный сквозной путь.

Путь пакета от приложения до сайта при 464XLAT: схема словами

Настало время собрать всю механику в единую пошаговую схему. Проследим за одним пакетом от момента рождения в приложении до прибытия на целевой IPv4-сервер и обратно. Это тот самый маршрут, который проходит трафик мобильного прокси.

Прямой путь: от телефона к сайту

1. Шаг 1. Приложение хочет соединиться. Приложение на телефоне решает открыть сайт, у которого только IPv4. Оно обращается к DNS за адресом.
2. Шаг 2. DNS64 синтезирует адрес. Резолвер оператора не находит настоящей AAAA-записи, берет запись A, встраивает IPv4-адрес в префикс 64:ff9b::/96 и возвращает синтезированную AAAA-запись.
3. Шаг 3. Приложение отправляет пакет. Есть два варианта. Если приложение работает по IPv6, оно сразу шлет IPv6-пакет на синтезированный адрес. Если приложение жестко привязано к IPv4, оно шлет IPv4-пакет на виртуальный интерфейс CLAT.
4. Шаг 4. CLAT транслирует IPv4 в IPv6. В случае IPv4-приложения демон CLAT перехватывает пакет и по правилам stateless-трансляции превращает его в IPv6-пакет, используя тот же NAT64-префикс.
5. Шаг 5. Пакет летит по радиосети. Теперь это чистый IPv6-пакет. Он проходит через базовую станцию и ядро мобильной сети оператора. Внутри всей радиочасти живет только IPv6.
6. Шаг 6. Пакет достигает PLAT. В ядре сети стоит узел PLAT с функцией NAT64. Он видит пакет с назначением, начинающимся с NAT64-префикса.
7. Шаг 7. PLAT транслирует IPv6 в IPv4. Узел извлекает последние 32 бита адреса назначения - это настоящий IPv4 сайта. Затем подставляет в качестве источника публичный IPv4 из своего пула, записывает соответствие в таблицу состояний.
8. Шаг 8. Пакет уходит в интернет. Теперь это обычный IPv4-пакет. Он путешествует по глобальной сети к целевому серверу.
9. Шаг 9. Сайт видит IPv4. Сервер получает соединение с публичного IPv4-адреса оператора. В логах он записывает именно этот IPv4. Вот момент истины: сайт никогда не узнает, что изначально пакет родился в IPv6-среде.

Обратный путь: от сайта к телефону

1. Шаг 10. Сервер отвечает. Сайт отправляет ответный IPv4-пакет на тот публичный адрес, который увидел.
2. Шаг 11. PLAT находит соответствие. Узел NAT64 смотрит в свою таблицу состояний, определяет, какому устройству принадлежит соединение, и восстанавливает IPv6-адрес.
3. Шаг 12. Обратная трансляция в IPv6. PLAT превращает IPv4-ответ в IPv6-пакет и отправляет его через ядро сети обратно к телефону.
4. Шаг 13. CLAT возвращает IPv4 приложению. Если исходно приложение работало по IPv4, CLAT на устройстве транслирует IPv6-ответ обратно в IPv4 и отдает его приложению через виртуальный интерфейс.
5. Шаг 14. Приложение получает ответ. Для приложения все выглядит как нормальный IPv4-обмен. Круг замкнулся.

Задержитесь на секунду и оцените изящество этой конструкции. Пакет четыре раза сменил протокольную личность, прошел через два транслятора, а конечные точки - приложение и сайт - об этом даже не подозревают. Каждый видит только свой знакомый IPv4-мир.

Что всё это значит для прокси: где рождается выходной адрес

Теперь применим всю теорию к практике мобильных прокси. Это самый важный раздел для тех, кто работает с трафиком.

Где рождается выходной адрес

Мобильный прокси - это, по сути, точка входа в сеть через реальное мобильное устройство или модем, подключенный к оператору. Когда вы направляете трафик через такой прокси, он выходит в интернет так же, как выходил бы трафик с телефона.

А мы уже знаем, что происходит с этим трафиком. Он проходит через 464XLAT, достигает PLAT, и там ему присваивается публичный IPv4-адрес из пула оператора. Именно этот адрес PLAT становится выходным адресом вашего прокси. Он рождается не на устройстве, не на модеме, а в узле NAT64 в ядре сети оператора.

Вот почему у мобильного выхода обычно IPv4. Само устройство живет в IPv6, но точка, откуда трафик выходит в глобальный интернет к IPv4-сайтам, - это PLAT, отдающий IPv4.

Что в итоге видит целевой сайт

Целевой сайт видит публичный IPv4-адрес оператора. Это адрес узла CGN или NAT64, за которым может скрываться множество абонентов. Сайт не видит ни внутренний IPv6-адрес устройства, ни виртуальный IPv4 интерфейса CLAT. Только внешний IPv4 PLAT.

Это принципиальный момент. Мобильные прокси ценятся за то, что их IPv4-адреса выглядят как адреса живых абонентов - потому что технически так и есть. Множество реальных пользователей делят один и тот же публичный IPv4 через один PLAT. С точки зрения целевого сайта такой адрес неотличим от обычного мобильного клиента.

Когда сайт может увидеть IPv6

Но не всегда выходной адрес будет IPv4. Если целевой сайт имеет настоящую AAAA-запись и полноценную IPv6-инфраструктуру, устройство соединится с ним напрямую по IPv6, минуя PLAT. В этом случае сайт увидит IPv6-адрес из подсети, выделенной абоненту оператором.

Именно поэтому один и тот же мобильный прокси может отдавать разным сайтам разные типы адресов. Сайту без IPv6 - публичный IPv4 через NAT64. Сайту с IPv6 - настоящий IPv6 напрямую. Это не сбой, а нормальное поведение системы двойного стека.

Чек-лист понимания выходного адреса

• Устройство в IPv6-сети - да, почти всегда у крупных операторов
• Выходной адрес к IPv4-сайту - публичный IPv4 узла PLAT оператора
• Выходной адрес к IPv6-сайту - настоящий IPv6 из подсети абонента
• Где происходит трансляция - в PLAT в ядре сети, не на устройстве
• Что видит IPv4-сайт - общий IPv4-адрес оператора, разделяемый абонентами

Двойной стек и happy eyeballs: почему проверка показывает то IPv4, то IPv6

Вы наверняка сталкивались с тем, что сервис проверки IP при повторных запросах показывает разные адреса - то IPv4, то IPv6. Это озадачивает. Разберемся, почему так происходит.

Что такое двойной стек

Двойной стек означает, что устройство одновременно располагает и IPv4-адресом, и IPv6-адресом и может использовать оба протокола. В мобильной среде это часто реализуется через IPv4v6 APN или через комбинацию нативного IPv6 плюс CLAT, дающий локальный IPv4.

Когда у клиента есть выбор из двух протоколов, встает вопрос: какой использовать для конкретного соединения? Раньше это решалось топорно и приводило к задержкам. Если IPv6-путь был сломан, браузер долго ждал таймаута, прежде чем откатиться на IPv4. Пользователи страдали от медленной загрузки.

Алгоритм happy eyeballs

Чтобы решить эту проблему, придумали алгоритм happy eyeballs, что можно перевести как счастливые глаза. Его суть - не гадать заранее, какой протокол лучше, а устроить соревнование.

Вот как он работает в общих чертах:

1. Клиент запрашивает для домена и запись A, и запись AAAA одновременно
2. Получив адреса обоих протоколов, он начинает устанавливать соединения почти параллельно
3. IPv6-попытка обычно стартует первой с небольшой форой в несколько десятков или сотен миллисекунд
4. Если IPv6-соединение устанавливается быстро, используется оно
5. Если IPv6 тормозит или не отвечает, клиент почти мгновенно переключается на IPv4
6. Победитель гонки используется для передачи данных, проигравшее соединение закрывается

Алгоритм отдает предпочтение IPv6, когда тот работает хорошо, но не позволяет ему тормозить работу, если что-то пошло не так. Отсюда и название - глаза остаются счастливыми, потому что задержек нет.

Почему проверка показывает разные адреса

Теперь понятно, откуда берется непостоянство. Когда вы открываете сервис проверки IP, происходит следующее:

• Если сервис имеет и A, и AAAA-записи, срабатывает happy eyeballs
• В зависимости от того, какое соединение победило в гонке в конкретный момент, вы увидите либо IPv4, либо IPv6
• Состояние сети, загруженность, кэш соединений - все это влияет на исход гонки
• При следующем запросе гонка может завершиться иначе, и адрес изменится

Это не ошибка прокси и не нестабильность соединения. Это ожидаемое поведение двойного стека под управлением happy eyeballs. Если вам нужен предсказуемый результат, надо принудительно зафиксировать версию протокола - об этом в следующем разделе.

Практический инсайт

Многие ошибочно считают, что мобильный прокси нестабилен, увидев прыгающие адреса в проверочном сервисе. На деле это здоровое поведение современной сети. Если хотите видеть только IPv4-выход, обращайтесь к сервисам без AAAA-записи или форсируйте IPv4 на уровне клиента. Тогда картина стабилизируется.

Практика: как посмотреть, какой стек у соединения

Теория без практики мертва. Давайте вооружимся конкретными командами, чтобы своими глазами увидеть, что происходит с вашим соединением. Все инструменты стандартны и доступны в большинстве систем.

Смотрим адреса интерфейса

Первое, что нужно сделать, - посмотреть, какие адреса назначены сетевым интерфейсам. Для IPv6 используйте команду:

• ip -6 addr - показывает все IPv6-адреса на всех интерфейсах
• ip -4 addr - аналогично для IPv4
• ip addr - показывает сразу все

Обратите внимание на типы адресов. Глобальные IPv6-адреса начинаются обычно с 2000::/3. Локальные адреса канала начинаются с fe80 и не маршрутизируются наружу. Если вы видите глобальный IPv6, устройство имеет полноценную IPv6-связность. Если также видите приватный IPv4 на отдельном интерфейсе, это, скорее всего, интерфейс CLAT.

Проверяем достижимость через ping

Проверить, работает ли конкретный протокол, помогает ping:

• ping6 адрес или ping -6 адрес - проверка связности по IPv6
• ping -4 адрес - проверка связности по IPv4

Если ping по IPv6 до глобального узла проходит, значит, у вас есть рабочая IPv6-связность. Если проходит только IPv4, то IPv6 либо не настроен, либо не работает.

Форсируем протокол в curl

Самый мощный инструмент диагностики для веб-трафика - это curl с ключами принудительного выбора протокола:

• curl -4 адрес - принудительно использовать только IPv4
• curl -6 адрес - принудительно использовать только IPv6
• curl -v адрес - подробный режим, показывает, к какому адресу реально подключились

Комбинируя ключи, можно точно узнать, какой адрес видит удаленный сайт. Отправьте запрос с ключом -4 на сервис, возвращающий ваш IP, и вы увидите чистый IPv4-выход. Отправьте с -6 - увидите IPv6, если он доступен. Так вы отделяете влияние happy eyeballs и видите реальную картину по каждому протоколу.

Проверка на эндпоинте только для IPv6

Особенно ценный прием - обратиться к сервису, который доступен исключительно по IPv6, без всякой A-записи. Если такое соединение устанавливается, у вас гарантированно есть нативная IPv6-связность, а не только трансляция. Если соединение не проходит даже при форсировании -6, значит, реального IPv6-выхода наружу нет, и вся ваша IPv6-активность крутится вокруг NAT64-префикса.

Практический сценарий проверки:

1. Выполните curl -6 на IPv6-only эндпоинт - проверяете нативную IPv6-связность
2. Выполните curl -4 на сервис определения IP - видите выходной IPv4 через PLAT
3. Сравните адреса - если IPv6-выход из подсети абонента, а IPv4 из пула оператора, значит, работает полноценный двойной стек с 464XLAT

Как определить наличие NAT64-префикса

Чтобы понять, использует ли ваша сеть NAT64, можно посмотреть на синтезированные адреса. Запросите AAAA-запись для домена, у которого точно нет IPv6, и посмотрите на ответ. Если вернется адрес, начинающийся с 64:ff9b, - это явный признак работы DNS64 и NAT64. Некоторые системы имеют встроенные механизмы обнаружения NAT64-префикса, которые именно так и работают: запрашивают известное имя и смотрят на структуру ответа.

Чек-лист диагностики стека

• ip -6 addr - есть ли глобальный IPv6
• ip -4 addr - есть ли IPv4 и не является ли он приватным CLAT-адресом
• ping -6 до глобального узла - работает ли IPv6-связность
• curl -4 на сервис IP - какой IPv4 видит сайт
• curl -6 на IPv6-only эндпоинт - есть ли нативный IPv6
• AAAA-запрос для IPv4-only домена - виден ли префикс 64:ff9b

Совместимость: почему подсеть /64 воспринимается как один клиент

Переходим к вопросу, который имеет огромное практическое значение для всех, кто работает с несколькими аккаунтами. Речь о том, как площадки относятся к IPv6-подключениям.

Почему некоторые площадки хуже относятся к IPv6

Исторически многие крупные платформы строили свои системы антифрода и репутации адресов вокруг IPv4. Накопленные базы данных, репутационные скоринги, правила ограничения частоты - все было заточено под 32-битные адреса. IPv6 пришел позже, и не все системы адаптировались одинаково хорошо.

Есть и структурная причина. В IPv4 каждый адрес - это дефицитный ресурс, за которым обычно стоит один узел или узел за NAT. В IPv6 адресов настолько много, что один клиент может легко менять свой адрес хоть тысячу раз в час в пределах своей подсети. Это ломает привычную логику, где адрес = идентификатор клиента.

Поэтому платформы выработали особый подход к IPv6, и понимать его критически важно.

Как трактуется подсеть /64

Вспомните, что мы говорили в разделе про основы: оператор выделяет каждому абоненту целую подсеть /64. Это гигантское количество адресов на одно устройство.

Умные системы репутации это понимают. Вместо того чтобы оценивать каждый отдельный IPv6-адрес, они агрегируют всю подсеть /64 и рассматривают ее как единый идентификатор. Логика проста: раз вся эта подсеть принадлежит одному абоненту, то и относиться к ней надо как к одному клиенту.

Это означает, что смена IPv6-адреса внутри одной /64 не создает нового идентификатора для таких платформ. Вы можете тасовать последние биты адреса сколько угодно, но с точки зрения площадки это все тот же один клиент, потому что префикс /64 не меняется.

Что это значит для работы с несколькими аккаунтами

Отсюда следует важный практический вывод. Если вы пытаетесь разделить аккаунты по разным IPv6-адресам внутри одной подсети /64, для продвинутых платформ они будут выглядеть как один клиент. Разные адреса не дают разделения, если общий префикс совпадает.

Сравните это с поведением IPv4 через NAT64. Публичный IPv4 узла PLAT разделяется множеством разных абонентов оператора. С точки зрения площадки за одним IPv4 стоят десятки реальных людей. Это дает совершенно другую картину смешивания трафика.

Ключевые выводы для мультиаккаунтинга:

• Смена последних битов IPv6 внутри одной /64 не меняет идентификатор для умных платформ
• Значимой единицей для IPv6 является префикс /64, а не отдельный адрес
• Разделение должно происходить на уровне разных подсетей /64, а не адресов внутри одной
• IPv4 через NAT64 смешивает вас с другими абонентами оператора, что дает иную репутационную динамику
• Всегда понимайте, какой протокол реально используется для соединения с конкретной площадкой

Практическая рекомендация по контролю протокола

Учитывая все это, разумно контролировать, по какому протоколу идет ваше соединение с целевой площадкой. Если вы точно знаете, что нужен IPv4-выход через мобильный оператор, форсируйте IPv4 на уровне клиента. Тогда вы гарантированно получаете разделяемый публичный адрес PLAT, а не привязанную к вашему устройству подсеть IPv6.

Типичные ошибки при работе с IPv6 в мобильных сетях

Теперь соберем в одном месте самые распространенные заблуждения и ошибки. Изучите их внимательно - каждая способна испортить работу или привести к неверным выводам.

Ошибка первая: считать, что IPv6-адрес на телефоне означает IPv6-выход

Многие видят глобальный IPv6 на интерфейсе и делают вывод, что весь трафик идет по IPv6. На деле трафик к IPv4-сайтам все равно превращается в IPv4 на PLAT. IPv6 на устройстве - это транспорт внутри сети оператора, а не гарантия IPv6-выхода к конкретному сайту.

Ошибка вторая: путать выходной адрес и адрес интерфейса

Адрес на сетевом интерфейсе устройства и адрес, который видит сайт, - это разные вещи. Между ними стоят CLAT и PLAT с трансляцией и NAT. Никогда не судите о выходном адресе по тому, что показывает ip addr. Всегда проверяйте на реальном внешнем сервисе.

Ошибка третья: паниковать из-за прыгающих адресов в проверке

Мы уже разобрали, что happy eyeballs заставляет двойной стек показывать то IPv4, то IPv6. Это норма. Не считайте это признаком поломки прокси. Если нужна стабильность, форсируйте протокол.

Ошибка четвертая: думать, что смена IPv6 внутри /64 дает новый идентификатор

Это одна из самых дорогих ошибок в мультиаккаунтинге. Умные платформы агрегируют всю /64. Смена последних битов адреса бессмысленна с точки зрения разделения аккаунтов. Значимой единицей выступает префикс.

Ошибка пятая: игнорировать тип APN

Тип APN - IPv4, IPv6 или IPv4v6 - напрямую определяет, что будет с трафиком. Не понимая, какой тип используется, вы работаете вслепую. Всегда выясняйте конфигурацию сессии.

Ошибка шестая: тестировать связность только по одному протоколу

Проверив только IPv4 или только IPv6, вы получаете неполную картину. Настоящая диагностика требует проверки обоих протоколов раздельно с помощью ключей -4 и -6, а также обращения к IPv6-only эндпоинту.

Ошибка седьмая: путать NAT64-префикс с настоящим IPv6-сайтом

Синтезированный адрес с префиксом 64:ff9b выглядит как IPv6, но за ним стоит IPv4-сервер. Если вы соединяетесь по такому адресу, вы фактически идете через NAT64 к IPv4-серверу, а не общаетесь с настоящим IPv6-узлом. Не делайте выводов о наличии нативного IPv6 у сайта по факту синтезированного адреса.

Ошибка восьмая: считать CLAT и PLAT одним и тем же

CLAT живет на устройстве и делает stateless-трансляцию для приложений. PLAT живет в сети оператора и делает stateful-трансляцию с NAT. Это разные компоненты с разными задачами. Путаница между ними мешает понять, где именно рождается выходной адрес.

Инструменты и ресурсы для работы со стеком протоколов

Соберем арсенал инструментов, которые помогут вам диагностировать и понимать сетевой стек в мобильной среде. Все они стандартны и не требуют экзотики.

Командная строка

• ip addr и его варианты ip -4 addr, ip -6 addr - базовый инструмент для просмотра адресов интерфейсов
• ping и ping6 - проверка связности по конкретному протоколу
• curl с ключами -4 и -6 - главный инструмент диагностики веб-соединений и проверки выходного адреса
• traceroute и traceroute6 - трассировка маршрута, помогает увидеть, через какие узлы идет трафик
• dig и nslookup - запросы к DNS для проверки записей A и AAAA, обнаружение синтезированных адресов
• ip route - просмотр таблицы маршрутизации для обоих протоколов

Онлайн-сервисы проверки

• Сервисы определения внешнего IP - показывают, что видит удаленный сайт
• IPv6-only тестовые эндпоинты - проверяют наличие нативной IPv6-связности
• Сервисы, показывающие раздельно IPv4 и IPv6 - помогают увидеть двойной стек
• Инструменты проверки поддержки IPv6 у домена - показывают наличие AAAA-записи

Диагностика DNS

Запросы к DNS помогают понять, работает ли DNS64. Запросите AAAA-запись для домена, у которого нет IPv6, и посмотрите на структуру ответа. Наличие префикса 64:ff9b выдает работу синтеза. Это самый прямой способ убедиться в присутствии механизма NAT64 в сети.

Фреймворк системной диагностики стека

Предлагаю пошаговый фреймворк, который стоит выполнять при первом знакомстве с любой мобильной сетью:

1. Инвентаризация адресов. Выполните ip addr, определите наличие глобального IPv6 и характер IPv4
2. Определение CLAT. Найдите виртуальный интерфейс с приватным IPv4 - это признак 464XLAT
3. Проверка NAT64. Запросите AAAA для IPv4-only домена, ищите префикс 64:ff9b
4. Тест нативного IPv6. curl -6 на IPv6-only эндпоинт
5. Определение выходного IPv4. curl -4 на сервис определения IP
6. Определение выходного IPv6. curl -6 на сервис, поддерживающий IPv6
7. Анализ поведения двойного стека. Обычный запрос без форсирования протокола, наблюдение за happy eyeballs

Пройдя все семь шагов, вы получите исчерпывающую картину: какой тип связности у сети, работает ли трансляция, какие адреса видят разные типы сайтов и как ведет себя двойной стек. Это ваш стандартный аудит.

Кейсы и результаты: разбор реальных сценариев

Абстрактная механика лучше усваивается на конкретных примерах. Разберем несколько типичных сценариев, с которыми сталкиваются на практике.

Кейс первый: сайт в логах видит один IPv4 на многих клиентов

Ситуация. Аналитик изучает логи сайта и замечает, что с одного IPv4-адреса приходит огромное количество разных пользователей с разным поведением. Первая мысль - это прокси или ботнет.

Разбор. На самом деле это классический публичный IPv4 узла NAT64 или CGN крупного мобильного оператора. За одним таким адресом действительно стоят десятки и сотни реальных абонентов. Их трафик выходит через один PLAT. Это не аномалия, а штатная работа 464XLAT в условиях дефицита IPv4.

Вывод. Оценивать мобильных клиентов только по IPv4-адресу неэффективно. Один адрес не равен одному пользователю в мобильной среде. Именно эта особенность делает мобильные IPv4-адреса такими характерными - высокая плотность реальных пользователей за одним адресом.

Кейс второй: непостоянный ответ проверочного сервиса

Ситуация. Оператор мобильного прокси жалуется, что сервис проверки IP показывает то IPv4, то IPv6, и делает вывод о нестабильности прокси.

Разбор. Проверочный сервис имеет и A, и AAAA-записи. Клиент работает в двойном стеке. Каждый запрос запускает happy eyeballs, и в зависимости от исхода гонки соединений возвращается разный тип адреса. Прокси работает абсолютно стабильно, меняется лишь протокол, выбранный алгоритмом.

Решение. Форсировать протокол через curl -4 или соответствующие настройки клиента. После фиксации IPv4 адрес стал предсказуемым. Проблема нестабильности оказалась мнимой.

Кейс третий: аккаунты слиплись несмотря на разные IPv6

Ситуация. Работа с несколькими аккаунтами через IPv6, каждому аккаунту назначен отдельный IPv6-адрес. Тем не менее платформа связывает аккаунты между собой.

Разбор. Все назначенные адреса находились внутри одной подсети /64, выделенной оператором на устройство. Продвинутая система репутации агрегировала всю /64 и трактовала ее как единый идентификатор. Разные адреса внутри одного префикса не дали никакого разделения.

Вывод. Для IPv6 значимой единицей является префикс /64, а не отдельный адрес. Разделение требует разных префиксов. В данном случае разумнее было работать через IPv4-выход NAT64, где трафик смешивается с другими абонентами оператора.

Кейс четвертый: приложение, которое не умеет в IPv6

Ситуация. Старое приложение обращается напрямую к IPv4-литералу адреса и должно бы сломаться в чисто-IPv6 сети. Но оно работает.

Разбор. На устройстве работает CLAT. Приложение отправляет IPv4-пакет на виртуальный интерфейс, CLAT транслирует его в IPv6, дальше пакет идет через PLAT в IPv4-интернет. Приложение живет в иллюзии полноценного IPv4 и не подозревает о трансляции. Это ровно та задача, ради которой CLAT и существует.

Вывод. 464XLAT обеспечивает совместимость для устаревших приложений прозрачно. Именно поэтому переход операторов на IPv6 не сломал экосистему IPv4-софта.

FAQ: часто задаваемые вопросы

Почему мой телефон показывает IPv6, а сайт в логах фиксирует IPv4?

Потому что подмена происходит в узле PLAT в ядре сети оператора. Устройство отправляет трафик по IPv6, но при выходе к IPv4-сайту узел NAT64 транслирует пакет в IPv4 и подставляет публичный адрес оператора. Сайт видит именно этот выходной IPv4, а не внутренний IPv6 устройства.

Что такое префикс 64:ff9b и откуда он берется?

Это стандартизированный общеизвестный префикс для трансляции NAT64. DNS64 использует его, чтобы синтезировать искусственные IPv6-адреса из IPv4-адресов сайтов без AAAA-записи. Последние 32 бита такого адреса содержат настоящий IPv4, который PLAT извлекает при трансляции.

Чем CLAT отличается от PLAT?

CLAT работает на устройстве и делает stateless-трансляцию IPv4 в IPv6 для приложений, которым нужен IPv4. PLAT работает в сети оператора и делает stateful-трансляцию IPv6 в IPv4 с NAT, подставляя публичный адрес. CLAT решает совместимость на устройстве, PLAT - совместимость с IPv4-интернетом.

Почему сервис проверки IP показывает разные адреса при обновлении?

Из-за алгоритма happy eyeballs в среде двойного стека. Если проверочный сервис доступен и по IPv4, и по IPv6, клиент запускает гонку соединений, и в разные моменты побеждает разный протокол. Это нормальное поведение, а не сбой. Форсируйте протокол ключом для стабильного результата.

Как узнать, есть ли у меня настоящий IPv6-выход, а не только NAT64?

Обратитесь к эндпоинту, доступному исключительно по IPv6, командой curl -6. Если соединение устанавливается, у вас есть нативная IPv6-связность. Если не проходит даже при форсировании -6, значит, реального IPv6-выхода нет, и вся IPv6-активность крутится вокруг синтезированного NAT64-префикса.

Почему смена IPv6-адреса не помогает разделить аккаунты?

Потому что оператор выделяет устройству целую подсеть /64, и продвинутые платформы агрегируют всю эту подсеть как единый идентификатор. Смена последних битов адреса не меняет префикс, поэтому для площадки это по-прежнему один клиент. Значимой единицей является именно /64, а не отдельный адрес.

Почему у мобильного прокси обычно выходной IPv4, а не IPv6?

Потому что большинство целевых сайтов не имеют IPv6-инфраструктуры, и трафик к ним проходит через NAT64. Узел PLAT транслирует пакеты в IPv4 и присваивает публичный адрес оператора. Этот адрес и становится выходным. К сайтам с настоящей AAAA-записью прокси может выходить и по IPv6 напрямую.

Как принудительно заставить клиент использовать нужную версию протокола?

На уровне curl используйте ключи -4 для IPv4 и -6 для IPv6. Многие приложения и библиотеки имеют аналогичные настройки предпочтения протокола. Также можно управлять через системные настройки приоритета политики адресов. Это отключает недетерминированность happy eyeballs и дает предсказуемый выход.

Что видит целевой сайт при соединении через мобильную сеть?

Если у сайта только IPv4, он видит публичный IPv4-адрес узла NAT64 оператора, разделяемый множеством абонентов. Если у сайта есть настоящий IPv6, он видит IPv6-адрес из подсети, выделенной абоненту. Внутренние адреса устройства и виртуальный CLAT-адрес сайт не видит никогда.

Влияет ли тип APN на то, какой адрес увидит сайт?

Косвенно да. Тип APN определяет, какие протоколы доступны устройству. При IPv4v6 или чистом IPv6 с CLAT работает вся описанная трансляционная механика. При чистом IPv4 APN трансляция не нужна, но такой вариант у крупных операторов встречается редко из-за дефицита адресов.

Заключение: главное о механике IPv6 в мобильных сетях

Мы прошли большой путь. Начали с загадки - телефон в IPv6, а сайт видит IPv4 - и полностью ее разгадали. Давайте закрепим ключевые выводы.

Первое и главное. Дефицит адресов IPv4 заставил операторов перейти на IPv6. Устройства живут в IPv6-среде, часто вообще без публичного IPv4 на радиоинтерфейсе. Совместимость со старым IPv4-интернетом обеспечивает технология 464XLAT.

Второе. 464XLAT состоит из двух трансляторов. CLAT на устройстве превращает IPv4-трафик приложений в IPv6. PLAT в сети оператора превращает IPv6 обратно в IPv4 и присваивает публичный адрес. Именно в PLAT рождается выходной IPv4-адрес, который видит сайт.

Третье. NAT64 и DNS64 работают в паре. DNS64 синтезирует IPv6-адреса из IPv4 для сайтов без AAAA-записи, используя префикс 64:ff9b. NAT64 в лице PLAT доставляет пакеты по этим адресам до реальных IPv4-серверов. Вместе они делают весь IPv4-интернет доступным для чисто-IPv6 устройства.

Четвертое. Двойной стек и happy eyeballs объясняют, почему проверка показывает то один протокол, то другой. Клиент устраивает гонку соединений и выбирает победителя. Для стабильности форсируйте протокол ключами -4 или -6.

Пятое. Для мультиаккаунтинга критически важно понимать: подсеть /64 воспринимается умными платформами как один клиент. Смена адреса внутри одной /64 бесполезна для разделения. IPv4 через NAT64, наоборот, смешивает вас с другими абонентами оператора.

Какие следующие шаги? Возьмите за правило проводить системную диагностику стека в любой новой мобильной сети по нашему фреймворку из семи шагов. Освойте curl с ключами -4 и -6 как основной инструмент. Всегда проверяйте выходной адрес на реальном внешнем сервисе, а не по интерфейсу устройства. И держите в голове разницу между тем, где живет устройство, и тем, откуда трафик реально выходит в интернет.

Понимание этой механики превращает вас из пользователя, который недоумевает над прыгающими адресами, в инженера, который точно знает, что происходит с каждым пакетом. А знание, как известно, - это контроль. Пусть эта статья станет вашей настольной шпаргалкой по устройству IPv6 в мобильных сетях. Возвращайтесь к ней всякий раз, когда столкнетесь с очередной сетевой загадкой - и она перестанет быть загадкой.