Проверяйте IPv4 и IPv6 при проверке VPN

Страница проверки публичного адреса может показать другой IPv4 после включения VPN, оставив важный вопрос без ответа: что произойдёт, когда приложение использует IPv6? Многие повседневные подключения поддерживают больше одного семейства адресов, а некоторые сети предоставляют лишь одно. Полезная проверка учитывает доступные возможности и то, для чего предназначена выбранная конфигурация. Цель — не принудительно включить IPv6 везде или повсюду отключить его, а не принимать один успешный запрос за полное описание всех возможных маршрутов устройства.

Начинайте проверку IPv6 с ожидаемого результата

Уточните, должен ли клиент с данной конфигурацией передавать IPv6, блокировать его вне туннеля или использовать другую документированную схему. Это разные правила. Отсутствие результата IPv6 может быть нормой в одной конфигурации и неисправностью в другой. Без знания ожидаемого поведения тест трудно трактовать.

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

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

Выясните возможности обычной сети

Если допустимо выполнить сравнение без VPN, не затрагивая чувствительные данные, установите, работает ли в исходной сети IPv4, IPv6 или оба семейства. Не отключайте обязательный рабочий туннель и не раскрывайте чувствительную активность только ради исходного замера. Если правила запрещают сравнение, отметьте ограничение и попросите администратора предложить разрешённый способ.

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

Привязывайте наблюдение к конкретной сети. Домашний Wi-Fi ничего не говорит о мобильном интернете, а ноутбук через раздачу не всегда равнозначен телефону, который её предоставляет. Укажите способ доступа и время. Если тест сообщает о недоступном IPv6, не придумывайте адрес и не называйте отсутствие утечкой только ради заполнения таблицы.

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

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

Браузерный тест измеряет запросы браузера. Если важно другое приложение, используйте подходящую для него диагностику или попросите её у поддержки. Исключения, системные прокси и особенности приложения способны менять охват. Руководство по проверке состояния VPN объясняет, почему индикатор подключения — только отправная точка, а не доказательство защищённости каждой последующей связи.

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

Проверяйте адреса внимательнее, чем подписи стран

Сервис определения адреса может приписывать ему организацию или страну. Такие подписи полезны как контекст, но не являются точным измерением физического местоположения. Базы могут расходиться, а IPv4 и IPv6 одного сервиса — получать разные географические отметки.

При проверке маршрутизации сравнивайте адреса с тем, что провайдер ожидает от данной конфигурации. Географическое поведение рассматривайте отдельно. Статья о стране VPN и языке сайта объясняет, почему языковое предпочтение сайта само по себе не отвечает на вопрос. Русский интерфейс или английская поисковая страница не заменяют проверку семейств адресов.

Ведите простую запись из четырёх пунктов: обычный IPv4, обычный IPv6, IPv4 через туннель и IPv6 через туннель. Явно помечайте недоступные и непроверенные пункты. Ниже укажите ожидаемые правила. Так проще различать неподдерживаемое семейство, неожиданный прямой маршрут и расхождение геолокационной метки, не сводя всё к «VPN сломан».

Не исправляйте маршруты угадыванием полей конфига

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

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

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

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

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

Если вопрос не решён, отправьте в поддержку Lumeraya версию клиента, тип сети, ожидаемые правила и отдельные результаты двух семейств. Сообщите, удалось ли получить исходный замер без VPN. Не включайте приватные ключи и не заявляйте о всеобщем сбое, если проверено лишь одно приложение.

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