Miért fagy le az RDP, amikor a távoli gép VPN-hez csatlakozik

Az RDP ablakán belül van, az asztal a képernyőn látszik, és megnyomja a Connect gombot a VPN-kliensben, amely azon a távoli gépen fut. Néhány másodperc múlva az ablak lefagy, majd bezárul. Az alagút feljött, pontosan ezt fogja jelenteni a VPN naplója, és ez az egész incidens legkevésbé hasznos ténye. A munkamenet azért halt meg, mert a gép, amellyel beszélt, megváltoztatta a válaszadás módját, ezért vizsgálja meg a visszautat, mielőtt az alagúthoz nyúl.

Jegyezze fel a végpontot, amelyet a munkamenete valóban használ

Az RDP-kliensbe írt cím nem feltétlenül az a cím, amelyre a távoli gép válaszol. A NAT, egy RD Gateway vagy a gazdagép előtti terheléselosztó átírhatja, a visszautat pedig az a forráscím határozza meg, amelyet a távoli gép a létrejött kapcsolaton lát. Ha itt hibázik, olyan útvonalat keres, amely sosem vett részt a dologban.

A távoli gépen, mielőtt a VPN csatlakozna, listázza a létrejött munkameneteket, és olvassa ki a partner címét a táblázatból. Utána jegyezze fel valahol azon a gépen kívül, mert a munkamenet megszakadása után már nem tudja kiolvasni.

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

Tekintse ezt a címet annak, aminek elérhetőnek kell maradnia. Ha privát cím egy felügyeleti VLAN-on, az alagútnak békén kell hagynia azt az útvonalat. Ha nyilvános cím, a válasznak ugyanazon a hálózati csatolón kell kifelé mennie, amely a kérést behozta.

Olvassa ki az útvonalat, amely erre a végpontra válaszol

A Windows célonként egy hálózati csatolót választ, és a Find-NetRoute megmutatja a döntést, amelyet most hozna. Futtassa a partner címére csatlakozás előtt, majd újra, amikor az alagút feláll, és hasonlítsa össze a csatoló indexét és a következő ugrást a két válaszban. A csatoló megváltozása az egész hiba egyetlen kimeneti sorban.

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

A teljes alagút profil egy alapértelmezett útvonalat telepít az alagúton keresztül, ahogy a Windows VPN-útválasztási útmutatója leírja, tehát minden válasz most a VPN-en keresztül megy ki, és attól függ, hogy a túloldal visszairányít-e a klienséhez. A megosztott alagút profil alapértelmezés szerint biztonságosabb, de nem immunis, mert egy konkrét, a partner címét lefedő útvonal még mindig legyőzheti a fizikai alapértelmezett útvonalat. Akárhogy is, a kérdés ugyanaz: az alagút felállása után a partner címe még mindig arra a csatolóra oldódik fel, amely a munkamenetet behozta?

Ha nem, a javítás a profilba vagy a VPN-szabályzat tulajdonosa által jóváhagyott kifejezett kivétel-útvonalba tartozik. Az útválasztási táblázat kézi szerkesztése egy termelési gazdagépen incidens közben az az út, amelyen egy ideiglenes megoldás dokumentálatlan konfigurációvá válik.

Figyelje a tűzfalprofil változását

Az új hálózati csatoló megjelenésekor besorolást kap, és a besorolás dönti el, melyik tűzfalprofil szerint ítélik meg a forgalmát. Egy Public kategóriába eső alagút-adapter csendben leállíthatja a bejövő RDP-t, még akkor is, ha az útválasztási táblázat tökéletesnek látszik. Ez a második hibaállapot, és más tünetet ad: az útvonal helyes, a csomagok megérkeznek, a gazdagép mégis megtagadja a kapcsolatot.

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

Hasonlítsa össze az alagút csatolójához tartozó profilt azokkal a profilokkal, amelyekre a Remote Desktop szabályai irányulnak. A csak Domain és Private számára engedélyezett szabály semmit nem tesz egy Public-ként besorolt csatolóért, és ezen egyetlen útvonal-javítás sem változtat. Néhány VPN-kliens tervezésénél fogva korlátozza a helyi alhálózat elérését is, ami ugyanazt a hibamintát hozza létre egy másik mechanizmusból.

Tesztelje az átmenetet egy olyan helyről, ahonnan vissza tud jönni

Végezze el a teljes sorozatot egy sávon kívüli konzolról vagy egy második felügyeleti útról, ebben a sorrendben: erősítse meg a meglévő munkamenetet, csatlakoztassa a VPN-t, nyisson új munkamenetet, majd bontsa a VPN-t, és nyisson még egyet. Minden lépés más átmenetet tesztel, és az első, amelyik elbukik, megmondja, melyik mechanizmus a felelős.

Tervezze meg a visszaállítást még a kezdés előtt, például egy ütemezett feladatot, amely rasdial "Work VPN" /disconnect futtat egy meghatározott időköz után. Ez az elveszett munkamenetet ötperces megszakítássá alakítja a helyszíni látogatás helyett, és ez a legolcsóbb biztosítás az egész eljárásban.

Jöjjön vissza, amikor a munkamenet már eltűnt

Ha a gazdagép már elérhetetlen, hagyja abba az új RDP-kapcsolatok próbálkozását ugyanabból a kliensből, és használja azt a helyreállítási csatornát, amely a környezetben már megvan: egy RD Gateway, egy hypervisor-konzol vagy egy sávon kívüli felügyeleti csatoló. Kérje meg a konzolhozzáféréssel rendelkező személyt, hogy futtassa ugyanazokat a parancsokat Find-NetRoute és Get-NetConnectionProfile, hogy a bizonyítékok túléljék a helyreállítást.

Ezután a tartós elrendezésről döntsön, ne a leggyorsabbról. Vagy a VPN-profil kifejezetten megőrzi a felügyeleti utat, vagy a felügyelet olyan csatornára kerül, amely nem függ a gazdagép alapértelmezett útvonalától. Mindkettő fenntartható; egy gazdagép-útvonal kitalált átjáróval nem. Írja le, melyiket választotta, és rögzítse a partner címét, amelynek túl kellett élnie.