Мережа лише з IPv6 ламає VPN ще до запуску тунелю

Ноутбук підключається до Wi-Fi конференції, який роздає лише IPv6, клієнт VPN крутиться й падає, а той самий профіль працював у готелі годину тому. У даних входу нічого не змінилося. Змінилося те, що клієнт тепер має досягти адресата IPv4 через мережу, яка несе лише IPv6, і не кожен клієнт знає, як це зробити.

Пройдіть ті самі п’ять кроків, які проходять пакети.

Крок 1: спостерігайте за пошуком імені

Якщо профіль використовує ім’я хоста, перше питання — що повертає резолвер. dig AAAA vpn.example.com у мережі лише з IPv6 повертає справжній запис AAAA, синтезований із DNS64 або взагалі нічого. Синтезована відповідь кодує адресата IPv4 усередині префікса трансляції, і лише тоді клієнт без адресата IPv6 може до нього дістатися. Профіль із жорстко заданим адресом IPv4 ніколи не доходить до цього, бо немає імені для синтезу.

Ця єдина різниця пояснює більшість звітів «там працює, тут падає», і щоб це побачити, достатньо однієї команди.

Крок 2: подивіться, яку родину викликав клієнт

Дивіться на сокет, а не на індикатор поступу. Клієнт, який відкриває сокет IPv4 до адреси IPv4 на каналі лише з IPv6, не має куди його надіслати, і збій проявляється як тайм-аут, а не як помилка імені. ss -tanp під час підключення клієнта показує віддалену адресу та родину, яку він спробував. Порівняйте це з ip -6 route, щоб переконатися, що маршрут за замовчуванням — справжній наступний хоп IPv6.

Родина адрес у таблиці сокетів — це факт. Індикатор поступу — це підсумок, який написав хтось інший.

Крок 3: відокремте трансляцію від тунелю

NAT64 і DNS64 — це те, як мережа доступу досягає адресатів IPv4, і після підняття тунелю вони для нього нічого не роблять. Тунель, побудований поверх трансльованого шляху, усе одно узгоджує власну внутрішню адресацію, а внутрішнє покриття IPv4 або IPv6 — окреме питання політики. Якщо клієнт підключається і потім нічого не досягає, ви вже пройшли трансляцію і перебуваєте в маршрутизації, а це інше розслідування з іншими доказами.

Збій трансляції виглядає як відсутність підключення. Збій внутрішнього покриття виглядає як підключення без досягнення чогось.

Крок 4: перевірте той самий профіль в іншій мережі

Візьміть той самий профіль, версію клієнта й дані входу в мережу з подвійним стеком і повторіть. Якщо там працює, а на шляху лише з IPv6 падає, змінна — мережа доступу, а не профіль. Запишіть у тікет версію клієнта й стан мережі, бо остаточним виправленням є оновлення клієнта або інший адресат.

Звіт «VPN зламано» не дає змоги діяти. Звіт «падає лише за доступу лише з IPv6» — це звіт про помилку.

Крок 5: виправте шлях, а не налаштування безпеки

Усі спокусливі виправлення роблять гірше. Вимкнення IPv6 прибирає єдиний шлях, який пропонує мережа. Спрямування клієнта на публічний резолвер ламає синтез DNS64, бо цей синтез має надходити від резолвера за транслятором. Вимкнення перевірки сертифіката дає з’єднання з чимось, що ви не можете розпізнати. Жодне з них не є виправленням, а два — регресії безпеки, які переживуть інцидент.

Реальні варіанти — клієнт із підтримкою моделі мережевої трансляції або адресат із доступною адресою IPv6. Попросіть один із них.