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

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