Перевіряйте 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 версію клієнта, тип мережі, очікувану політику й окремі результати обох сімейств. Зазначте, чи було можливим початкове порівняння. Не додавайте приватних ключів і не заявляйте про загальний збій після тесту лише однієї програми.

Зрозуміла перевірка двох сімейств завершується обмеженим висновком: спостережений IPv4 працював як очікувалося, IPv6 теж або був навмисно недоступним, а невизначеність зазначена. Це корисніше за одну заспокійливу адресу, бо пов’язує результат зі справжньою конфігурацією та трафіком, який потрібно захистити.