Почему ответы DNS64 меняются, как только подключается VPN?

Ответы DNS64 описывают сетевую конфигурацию, а не свойство сервера. Резолвер синтезирует адрес IPv6 из адреса IPv4, и результат работает только там, где в конце этого префикса стоит транслятор. Введите VPN в путь, и такая конфигурация может сохраниться, измениться или перестать быть верной в зависимости от трёх условий.

Эти условия — ответивший резолвер, маршрут, который есть у вашего устройства к синтезированному префиксу, и то, выполняет ли что-либо на этом маршруте трансляцию. Каждое из них наблюдаемо, и именно это делает сбой диагностируемым.

На что на самом деле указывает синтезированная запись AAAA

Резолвер DNS64 отвечает на запрос AAAA для имени, у которого есть только IPv4, встраивая адрес IPv4 в префикс, который он настроен использовать, а общеизвестный префикс для этой задачи — 64:ff9b::/96, как описано в RFC 6147. Для приложения запись выглядит как любая другая запись AAAA, и в этом суть: клиент с одним лишь IPv6 может попытаться установить соединение, не зная, что у назначения никогда не было IPv6. Затем это соединение зависит от функции NAT64, которая где-то на пути транслирует между двумя семействами. Без такого транслятора синтезированный адрес — правдоподобно выглядящее назначение, которое никуда не ведёт.

Итак, запись кодирует две вещи сразу: исходный адрес IPv4 и предположение о том, что транслятор доступен. Только первое видно в самом ответе.

Три условия решают, работает ли это до сих пор

Первое условие — какой резолвер создал запись, поскольку резолвер без настроенного DNS64 ничего не возвращает для этого имени, и приложение отказывает иначе. Второе — есть ли у вашего устройства маршрут к синтезированному префиксу, потому что ответ может быть действительным, пока путь к нему отсутствует. Третье — находится ли транслятор, владеющий этим префиксом, на том пути, который вы бы использовали, поскольку туннель, уносящий 64:ff9b::/96 в другое место, достигает другой функции или ничего. Все три могут выполняться до туннеля и нарушаться после него, и поэтому симптом выглядит как внезапная регрессия.

Проверяйте их в этом порядке. Отсутствующий ответ и отсутствующий маршрут выглядят одинаково в браузере и совершенно по-разному в журнале резолвера.

Когда резолвер меняется, ответ меняется

Клиент VPN часто навязывает свой резолвер или полностью перехватывает путь запроса, и этот резолвер может ничего не синтезировать. Запросы для имён, у которых есть только IPv4, тогда не возвращают запись AAAA, и клиент с одним лишь IPv6 переживает это как имя, до которого нельзя добраться. Бывает и обратное: резолвер, который действительно синтезирует, может выдать префикс, который ваш туннельный путь не несёт.

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

Проверяйте запрос и путь по отдельности

Спросите имя напрямую, прежде чем подключать приложение, и отметьте, какой сервер ответил. Приведённые ниже команды показывают запись AAAA, используемый резолвер и наличие маршрута к синтезированному префиксу. Запустите их с опущенным туннелем, а затем снова с поднятым.

dig AAAA ipv4only.example.com +short
dig AAAA ipv4only.example.com | grep -E '^;; SERVER'
ip -6 route get 64:ff9b::c000:0216
curl -6 -sS -o /dev/null -w '%{http_code} %{time_connect}\n' --max-time 8 http://ipv4only.example.com/

Читайте результаты как цепочку. Отсутствие записи AAAA означает, что резолвер перед вами не синтезирует, поэтому путь с одним лишь IPv6 не сработает для этого имени, что бы ни делал клиент. Запись есть, а маршрута нет — префикс не несёт текущий путь, и это решение о маршрутизации, а не сбой резолвера. Маршрут есть, а запрос всё ещё не проходит — это указывает на сам транслятор, и он принадлежит другому владельцу.

Запишите резолвер, сетевой контекст и семейство адресов рядом с каждым результатом. Именно эта заметка позволяет следующему сравнению отделить смену резолвера от смены маршрутизации.