Трафік IPv6 повз VPN: знайти маршрут, що протікає

Дві тестові сторінки розходяться: одна повідомляє адресу провайдера через тунель, друга повідомляє ваш домашній префікс, і очевидний висновок — VPN протікає. Цей висновок пропускає один крок, бо два звіти задіяли два різні рішення маршрутизації, і лише одне з них мало потрапити в тунель. Діра зазвичай реальна, і це проблема покриття, а не зламаний тунель. Три питання вирішують справу: який потік справді вийшов, який маршрут обрало для нього ядро і яку поведінку мав на увазі клієнт.

Працюйте в цьому порядку. Відповіді не по порядку дають довгу суперечку про те, чи клієнт несправний, тоді як справжня відповідь — маршрут IPv6 ніколи не встановлювався.

Який потік справді вийшов і через який адаптер

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

Надсилайте по одному запиту на сімейство замість того, щоб завантажувати сторінку й читати її результат. Одна сторінка може змішувати ресурси v6 і v4, фоновий процес може поводитися інакше, ніж вкладка перед вами, а відповідь із кешу може пережити ту зміну мережі, яку ви перевіряєте. Зафіксуйте адресата, який перевіряєте, і запишіть його, щоб повторний запуск вимірював те саме.

Читання маршруту, обраного ядром

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

ip -6 route get 2606:4700:4700::1111
ip -6 rule show
ip -6 route show table all

Конкретніший префікс — звичайна причина того, що один адресат лишається поза тунелем, поки все інше всередині, а правило політики може зробити те саме з вищим пріоритетом за будь-який маршрут. Читайте й метрику, бо два записи для того самого префікса вирішуються за метрикою, а не за їхнім порядком на екрані. У Windows еквівалентний список — Get-NetRoute -AddressFamily IPv6, відсортований за метрикою, щоб відповідати порядку рішення. Правило, яке в таблиці виглядає правильним, усе одно може програти правилу політики з меншим номером, тому список правил іде в одному подиху зі списком маршрутів.

Звідки береться політика IPv6 у клієнта

Клієнт може бути побудований так, щоб проводити v6 через тунель, щоб відмовлятися від нього або дозволяти іменований виняток, і ці три наміри дають три різні правильні результати. Прочитайте профіль і документацію самого клієнта, перш ніж називати спостереження витоком, бо клієнт, який блокує v6, поки операційна система все ще надсилає виявлення сусідів фізичним каналом, поводиться як задумано.

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

Вузьке спостереження, коли таблиця суперечить

Коли пошук маршруту неоднозначний, одне спостереження інтерфейсу на хості може його розв’язати, але лише якщо воно націлене на питання. Трафік до самої кінцевої точки VPN пройде фізичним адаптером за задумом; важливо, чи з’являється там самий потік застосунку, адресований зовсім в інше місце. Фільтруйте запис за адресатом, який перевіряєте, а не збирайте все.

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

Три способи закрити діру

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

Повторіть перевірку після перепідключення і після переходу між мережами, бо маршрут, встановлений для попереднього каналу, може пережити зміну. Потім запишіть адресата, вибраний маршрут, політику клієнта і сімейство, яке використав тест, щоб наступна людина прочитала рішення, а не виводила його заново. RFC 7359 описує витік подвійного стека як проблему проєктування, а не помилку, і це те посилання, на яке спираються, коли хтось твердить, що робочий тунель v4 покриває все.