Витік DNS через VPN у Windows: чому метрика важливіша за маршрут

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

Два пояснення одного витоку

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

Пояснення через ранжування каже, що трафік повністю в тунелі, а запит усе одно надсилається іншому резолверу. Windows розглядає вибір резолвера як властивість кожного інтерфейсу з порядком, тому фізичний адаптер із кращою метрикою може давати DNS для імені, хоча пакети до розв’язаної адреси йдуть через тунель. Обидва пояснення дають однаковий симптом на сторінці перевірки витоку, тому перевірка не є діагнозом. Лише одне з них виправляється редагуванням маршрутів.

Порівняйте метрики й резолвери разом

Запишіть інтерфейси, їхні метрики та налаштовані сервери, поки тунель активний. Читайте їх як таблицю, а не як два окремі списки, бо питання в тому, який резолвер перший, а не які резолвери існують.

Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric | Select-Object InterfaceIndex, InterfaceAlias, InterfaceMetric
Get-DnsClientServerAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, ServerAddresses

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

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

Підніміть тунель і перевірте знову

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

Set-NetIPInterface -InterfaceIndex 27 -InterfaceMetric 1
Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric

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

Потім запитайте одне внутрішнє і одне публічне ім’я та перевірте, який сервер відповів. Довідка Microsoft довідка про автоматичні метрики пояснює, чому перевага надається найменшому значенню і як виводиться автоматичне призначення.

Зробіть так, щоб це пережило перепідключення

Ручна метрика на адаптері, який щоразу створюється заново, — це параметр, що зникає. Якщо клієнт перебудовує інтерфейс, перевизначенню потрібен скрипт після підключення, політика або конфігурація клієнта, яка володіє DNS протягом з’єднання.

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