Трафик 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 покрывает всё.