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