Ваш розділений тунель досягає застосунку, але не його DNS-сервера
Розділений тунель може маршрутизувати підмережу застосунку й усе ж залишити резолвер поруч поза ним. Додайте маршрут до хоста, а потім перевірте, який сервер Windows насправді вибирає.
Маршрутизація підмережі застосунку — очевидна частина розділеного тунелю, і це не вся робота. Резолвер часто розташований за іншою адресою, ніж застосунок, якому він служить, тому робочий тунель усе одно може залишити запит поза ним. Профіль, який несе 10.80.0.0/16 і більше нічого, надсилає запит для 10.90.0.53 через локальний інтерфейс, де приватної зони не існує. Додайте шлях до резолвера, потім подивіться на другу половину проблеми: який сервер клієнт насправді вибирає.
Міф: один маршрут покриває всю службу
Розділений тунель — це список призначень, які йдуть через з'єднання, а не опис служби. Підмережа застосунку й адреса резолвера — два призначення, і профіль може нести одне без іншого. Коли так стається, застосунок доступний за адресою, а його ім'я не розв'язується, що виглядає як збій DNS, а не як прогалина в маршрутизації.
Підмережа навколо резолвера теж не охоплюється автоматично. Маршруту до хоста на одну адресу достатньо для цього резолвера, і він не відкриває сусідів. У цьому сенс маршруту до хоста: вузький за задумом і легко забуваний, коли наступна служба з'являється в тій самій підмережі.
Щоб пошук працював, мають виконуватися три умови: клієнт маршрутизує адресу резолвера через тунель, шлюз приймає й пересилає цей запит, а резолвер приймає отримане джерело. Відповідь теж має повернутися узгодженим шляхом. Якщо бракує бодай одного, симптом той самий, тому таблицю адрес варто записати до того, як торкатися конфігурації.
Визначте, які адреси профіль має нести
Перелічіть призначення за порядком: мережа застосунку, адреса резолвера й публічна кінцева точка, що завершує сам тунель. Третє ніколи не можна маршрутизувати в тунель, бо зовнішньому з'єднанню потрібен шлях, який існує до тунелю.
| Destination | Coverage this example needs |
|---|---|
| Application network | 10.80.0.0/16 through the VPN |
| Private resolver | 10.90.0.53/32 through the VPN |
| Public VPN endpoint | Normal internet path, outside the tunnel |
Уключіть і UDP, і TCP для DNS, оскільки від реалізацій очікується підтримка TCP поряд з UDP, а заблокований шлях TCP дає повільні, часткові збої замість чистих. Якщо приватна зона обслуговується й через IPv6, еквівалентний виняток для хоста використовує адресу й префікс IPv6 і є окремим записом.
Запишіть, що профіль уже охоплює, перш ніж щось додавати. Дубльований маршрут нешкідливий, але неочікуваний наявний маршрут говорить, що профіль розрахований на інший план адрес, ніж той, який вам дали.
Додайте маршрут до хоста через власника з'єднання
Для локально керованого власного профілю Windows маршрут належить з'єднанню, а не глобальній таблиці маршрутизації машини. Спершу перегляньте додавання, потім застосуйте його з тією самою областю, яку використовує профіль.
Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes
Перша команда показує зміну в попередньому перегляді, нічого не встановлюючи, а друга перелічує маршрути, які профіль несе зараз. Довідка Microsoft щодо Add-VpnConnectionRoute описує області для окремого користувача й для всіх користувачів; профілю для всіх користувачів потрібен власний параметр області, а команда для окремого користувача проти профілю для всіх користувачів завершується помилкою або потрапляє не туди.
Коли профіль керований або надходить від клієнта постачальника, зміна належить тому власникові. Накладання постійного системного маршруту на політику з'єднання працює, доки політику не застосують знову і маршрут не зникне, що зазвичай трапляється під час дзвінка в підтримку, а не під час тестування. Цей збій тихий: маршрут зникає, ім'я перестає розв'язуватися, і ніхто не пов'язує дві події. Помістіть зміну у власний запис власника, щоб наступне повторне застосування несло її, а не стирало.
Після застосування перепідключіть профіль, а не припускайте, що маршрут набув чинності. Зміни маршрутів на живому з'єднанні не завжди підхоплюються, а перепідключення також відтворює стан, який ваші користувачі реально матимуть.
Перевірте, який резолвер клієнт насправді використав
Маршрут керує пакетами, адресованими резолверу. Він не вирішує, які імена туди надсилати, і цей вибір — окремий механізм. У Windows чинні правила простору імен можуть вибирати резолвер для кожного домену, а параметри DNS профілю дають значення за замовчуванням. Ці два шари можуть розходитися, не породжуючи жодної помилки, тому прямий запит — лише половина доказу.
Get-DnsClientNrptPolicy Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A
Перша команда друкує чинну політику простору імен, а друга запитує приватний резолвер безпосередньо про ім'я застосунку. Пряма відповідь доводить, що шлях і резолвер працюють; вона не доводить, що власний пошук застосунку вибрав цей сервер. Порівняйте її зі звичайним пошуком того самого імені та з відповіддю, яку отримує застосунок.
Враховуйте кеші та безпечний DNS на рівні браузера, який може повністю обійти системний резолвер для імен, набраних користувачем. Суфікс пошуку — ще одна хибна підказка: він розширює коротке ім'я до повного й не має нічого спільного з тим, який сервер відповідає.
Завершіть перепідключенням і повторенням звичайного пошуку, а потім підтвердьте, що звичайний перегляд досі дотримується затвердженої політики. Заміна приватного резолвера публічним, щоб розв'язалося стороннє ім'я, — не виправлення, і вона тихо переносить приватні запити туди, куди вони ніколи не мали потрапляти.