Чому RDP зависає, коли віддалений комп’ютер підключається до VPN

Ви всередині вікна RDP, робочий стіл на екрані, і ви натискаєте Connect у клієнті VPN, що працює на тій віддаленій машині. За кілька секунд вікно завмирає і потім закривається. Тунель піднявся, саме це й запише журнал VPN, і це найменш корисний факт у всій події. Сеанс загинув, бо машина, з якою ви розмовляли, змінила спосіб відповіді вам, тому перевірте зворотний шлях, перш ніж чіпати тунель.

Запишіть кінцеву точку, яку ваш сеанс справді використовує

Адреса, введена в клієнт RDP, не обов’язково та адреса, на яку відповідає віддалений комп’ютер. NAT, RD Gateway або балансувальник навантаження перед хостом можуть її переписати, а зворотний шлях визначає адреса джерела, яку віддалена машина бачить на встановленому з’єднанні. Помилка тут змусить вас шукати маршрут, який ніколи не брав участі.

На віддаленому комп’ютері, поки VPN не підключено, перелічіть встановлені сеанси і прочитайте адресу партнера з таблиці. Потім запишіть її десь поза цією машиною, бо після падіння сеансу ви її вже не прочитаєте.

Get-NetTCPConnection -LocalPort 3389 -State Established |
  Select-Object LocalAddress, RemoteAddress, RemotePort

Ставтеся до цієї адреси як до того, що має залишатися доступним. Якщо це приватна адреса в керівному VLAN, тунель має залишити цей шлях у спокої. Якщо це публічна адреса, відповідь має виходити через той самий інтерфейс, що приніс запит усередину.

Прочитайте маршрут, який відповідає цій кінцевій точці

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

Find-NetRoute -RemoteIPAddress 203.0.113.24
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric
Get-VpnConnection -Name "Work VPN" | Select-Object SplitTunneling, Routes

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

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

Стежте за зміною профілю брандмауера

Новий інтерфейс класифікується, коли з’являється, і класифікація визначає, за яким профілем брандмауера оцінюється його трафік. Тунельний адаптер, що потрапив у категорію Public, може тихо зупинити вхідний RDP, навіть якщо таблиця маршрутизації виглядає бездоганно. Це другий режим відмови, і він дає інший симптом: маршрут правильний, пакети надходять, а хост відмовляє в з’єднанні.

Get-NetConnectionProfile
Get-NetFirewallProfile | Select-Object Name, Enabled
Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Select-Object Name, Enabled, Profile

Порівняйте профіль, прив’язаний до тунельного інтерфейсу, з профілями, на які націлені правила Remote Desktop. Правило, увімкнене лише для Domain і Private, нічого не робить для інтерфейсу, класифікованого як Public, і жодне виправлення маршруту цього не змінює. Деякі клієнти VPN за задумом обмежують і доступ до локальної підмережі, що створює ту саму форму відмови від іншого механізму.

Перевірте перехід із місця, звідки можна відновитися

Виконайте всю послідовність із зовнішньої консолі або другого шляху керування в такому порядку: підтвердьте наявний сеанс, підключіть VPN, відкрийте новий сеанс, потім від’єднайте VPN і відкрийте ще один. Кожен крок перевіряє інший перехід, і перший невдалий підказує, який механізм відповідальний.

Заплануйте відкат до початку, наприклад заплановане завдання, яке запускає rasdial "Work VPN" /disconnect через заданий інтервал. Це перетворює втрачений сеанс на п’ятихвилинну перерву замість виїзду на місце, і це найдешевша страховка в усій процедурі.

Поверніться всередину, коли сеанс уже зник

Якщо хост уже недоступний, припиніть пробувати нові з’єднання RDP з того самого клієнта і використайте канал відновлення, який уже має середовище: RD Gateway, консоль гіпервізора або зовнішній інтерфейс керування. Попросіть людину з доступом до консолі виконати ті самі команди Find-NetRoute і Get-NetConnectionProfile, щоб докази пережили відновлення.

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