Dlaczego RDP się zawiesza, gdy zdalny komputer łączy się z VPN

Jesteś w oknie RDP, pulpit jest na ekranie, i naciskasz Connect w kliencie VPN działającym na tej zdalnej maszynie. Kilka sekund później okno się zawiesza, a potem zamyka. Tunel się podniósł, dokładnie to zgłosi log VPN, i to jest najmniej użyteczny fakt w całym incydencie. Sesja umarła, ponieważ maszyna, z którą rozmawiałeś, zmieniła sposób, w jaki ci odpowiada, więc prześledź drogę powrotną, zanim dotkniesz tunelu.

Zapisz punkt końcowy, którego Twoja sesja naprawdę używa

Adres wpisany w klienta RDP niekoniecznie jest adresem, na który odpowiada zdalny komputer. NAT, RD Gateway albo równoważenie obciążenia przed hostem mogą go przepisać, a drogę powrotną wyznacza adres źródłowy, który zdalna maszyna widzi na ustanowionym połączeniu. Pomylenie się tutaj wysyła cię na poszukiwanie trasy, która nigdy nie brała udziału.

Na zdalnym komputerze, zanim VPN będzie podłączony, wylistuj ustanowione sesje i odczytaj adres peera z tabeli. Potem zapisz go gdzieś poza tą maszyną, ponieważ po zerwaniu sesji nie będziesz mógł go odczytać.

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

Traktuj ten adres jako to, co musi pozostać osiągalne. Jeśli to adres prywatny w VLAN-ie zarządzania, tunel musi zostawić tę drogę w spokoju. Jeśli to adres publiczny, odpowiedź musi wyjść przez ten sam interfejs, który wniósł żądanie do środka.

Odczytaj trasę, która odpowiada temu punktowi końcowemu

Windows wybiera interfejs dla każdego celu, a Find-NetRoute pokazuje decyzję, którą podjąłby teraz. Uruchom go na adres peera przed połączeniem, potem ponownie z podniesionym tunelem, i porównaj indeks interfejsu oraz następny przeskok w obu odpowiedziach. Zmiana interfejsu to cały błąd w jednej linii wyjścia.

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

Profil pełnego tunelu instaluje trasę domyślną przez tunel, jak opisuje przewodnik Windows dotyczący routingu VPN, więc każda odpowiedź wychodzi teraz przez VPN i zależy od tego, czy druga strona routuje z powrotem do twojego klienta. Profil tunelu dzielonego jest domyślnie bezpieczniejszy, ale nie odporny, ponieważ konkretna trasa obejmująca adres peera wciąż może wygrać z fizyczną trasą domyślną. Tak czy inaczej pytanie jest identyczne: po podniesieniu tunelu czy adres peera nadal rozwiązuje się do interfejsu, który wniósł sesję do środka?

Jeśli nie, poprawka należy do profilu albo do jawnej trasy wyjątku zatwierdzonej przez właściciela polityki VPN. Ręczne edytowanie tabeli routingu na hoście produkcyjnym podczas incydentu to sposób, w jaki obejście tymczasowe staje się nieudokumentowaną konfiguracją.

Obserwuj zmianę profilu zapory

Nowy interfejs jest klasyfikowany, gdy się pojawia, a klasyfikacja decyduje, według którego profilu zapory oceniany jest jego ruch. Karta tunelu, która trafi do kategorii Public, może po cichu zatrzymać przychodzący RDP, nawet gdy tabela routingu wygląda idealnie. To drugi tryb awarii i daje inny objaw: trasa jest poprawna, pakiety dochodzą, a host odmawia połączenia.

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

Porównaj profil przypisany do interfejsu tunelu z profilami, na które ukierunkowane są reguły Remote Desktop. Reguła włączona tylko dla Domain i Private nic nie robi dla interfejsu sklasyfikowanego jako Public, i żadna korekta trasy tego nie zmienia. Niektóre klienty VPN z założenia ograniczają też dostęp do lokalnej podsieci, co daje ten sam kształt awarii z innego mechanizmu.

Przetestuj przejście z miejsca, z którego możesz wrócić

Wykonaj całą sekwencję z konsoli out-of-band albo drugą ścieżką zarządzania, w tej kolejności: potwierdź istniejącą sesję, podłącz VPN, otwórz nową sesję, potem rozłącz VPN i otwórz jeszcze jedną. Każdy krok testuje inne przejście, a pierwszy, który zawiedzie, mówi ci, który mechanizm jest odpowiedzialny.

Zaplanuj wycofanie przed rozpoczęciem, na przykład zaplanowane zadanie, które uruchamia rasdial "Work VPN" /disconnect po ustalonym interwale. To zamienia utraconą sesję w pięciominutową przerwę zamiast wizyty na miejscu, i jest to najtańsze ubezpieczenie w całej procedurze.

Wróć do środka, gdy sesja już zniknęła

Jeśli host jest już nieosiągalny, przestań próbować nowych połączeń RDP z tego samego klienta i użyj kanału odzyskiwania, który środowisko już ma: RD Gateway, konsoli hipervisora albo interfejsu zarządzania out-of-band. Poproś osobę z dostępem do konsoli o uruchomienie tych samych poleceń Find-NetRoute i Get-NetConnectionProfile, aby dowody przetrwały odzyskiwanie.

Potem zdecyduj o stałym układzie, a nie o najszybszym. Albo ścieżka zarządzania jest wyraźnie zachowana przez profil VPN, albo zarządzanie przenosi się na kanał, który nie zależy od trasy domyślnej hosta. Oba są do obrony; trasa hosta z odgadniętą bramą nie jest. Zapisz, którą wybrałeś, i odnotuj adres peera, który musiał przetrwać.