De ce se blochează RDP când computerul la distanță se conectează la un VPN

Ești în fereastra RDP, desktopul este pe ecran și apeși Connect în clientul VPN care rulează pe acea mașină la distanță. Câteva secunde mai târziu fereastra se blochează și apoi se închide. Tunelul a urcat, exact asta va raporta jurnalul VPN, și acesta este cel mai puțin util fapt din întregul incident. Sesiunea a murit pentru că mașina cu care vorbeai și-a schimbat modul în care îți răspunde, așa că verifică calea de întoarcere înainte de a atinge tunelul.

Notează punctul final pe care sesiunea ta îl folosește efectiv

Adresa tastată în clientul RDP nu este neapărat adresa la care răspunde computerul la distanță. NAT-ul, un RD Gateway sau un balansator de încărcare din fața gazdei o pot rescrie, iar calea de întoarcere este definită de adresa sursă pe care mașina la distanță o vede pe conexiunea stabilită. Dacă greșești aici, vei căuta o rută care nu a fost niciodată implicată.

Pe computerul la distanță, înainte ca VPN-ul să fie conectat, listează sesiunile stabilite și citește adresa perechii din tabel. Apoi noteaz-o undeva în afara acelei mașini, pentru că nu o vei mai putea citi după ce sesiunea cade.

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

Tratează acea adresă ca pe lucrul care trebuie să rămână accesibil. Dacă este o adresă privată într-un VLAN de administrare, tunelul trebuie să lase acea cale în pace. Dacă este o adresă publică, răspunsul trebuie să iasă prin aceeași interfață care a adus cererea înăuntru.

Citește ruta care răspunde acelui punct final

Windows alege o interfață pentru fiecare destinație, iar Find-NetRoute arată decizia pe care ar lua-o acum. Ruleaz-o pe adresa perechii înainte de conectare, apoi din nou cu tunelul ridicat, și compară indexul interfeței și următorul salt în cele două răspunsuri. O schimbare de interfață este întreaga defecțiune într-o linie de ieșire.

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

Un profil de tunel complet instalează o rută implicită prin tunel, așa cum descrie ghidul Windows pentru rutarea VPN, așa că fiecare răspuns iese acum prin VPN și depinde de faptul că partea cealaltă rutează înapoi către clientul tău. Un profil de tunel divizat este mai sigur implicit, dar nu imun, pentru că o rută specifică ce acoperă adresa perechii poate încă învinge ruta implicită fizică. În orice caz întrebarea este identică: după ce tunelul urcă, adresa perechii se mai rezolvă către interfața care a adus sesiunea înăuntru?

Dacă nu, corecția aparține profilului sau unei rute de excepție explicite aprobate de proprietarul politicii VPN. Editarea manuală a tabelului de rutare pe o gazdă de producție în timpul unui incident este felul în care o soluție temporară devine configurație nedocumentată.

Urmărește schimbarea profilului firewall-ului

O interfață nouă este clasificată când apare, iar clasificarea decide față de ce profil de firewall este evaluat traficul ei. Un adaptor de tunel care ajunge în categoria Public poate opri silențios RDP-ul de intrare chiar dacă tabelul de rutare pare perfect. Acesta este al doilea mod de defectare și produce un simptom diferit: ruta este corectă, pachetele ajung, iar gazda refuză conexiunea.

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

Compară profilul atașat interfeței tunelului cu profilurile cărora le sunt destinate regulile Remote Desktop. O regulă activată doar pentru Domain și Private nu face nimic pentru o interfață clasificată drept Public, iar nicio corecție de rută nu schimbă asta. Unii clienți VPN limitează prin proiectare și accesul la subrețeaua locală, ceea ce produce aceeași formă de defectare dintr-un alt mecanism.

Testează tranziția dintr-un loc de unde poți reveni

Fă întreaga secvență dintr-o consolă out-of-band sau o a doua cale de administrare, în această ordine: confirmă sesiunea existentă, conectează VPN-ul, deschide o sesiune nouă, apoi deconectează VPN-ul și deschide încă una. Fiecare pas testează o tranziție diferită, iar primul care eșuează îți spune ce mecanism este responsabil.

Planifică revenirea înainte de a începe, de exemplu o sarcină planificată care rulează rasdial "Work VPN" /disconnect după un interval stabilit. Asta transformă o sesiune pierdută într-o întrerupere de cinci minute în loc de o vizită la fața locului, și este cea mai ieftină asigurare din întreaga procedură.

Revino înăuntru când sesiunea a dispărut deja

Dacă gazda este deja inaccesibilă, oprește încercarea de conexiuni RDP noi din același client și folosește canalul de recuperare pe care mediul îl are deja: un RD Gateway, o consolă de hypervisor sau o interfață de administrare out-of-band. Roagă persoana cu acces la consolă să ruleze aceleași comenzi Find-NetRoute și Get-NetConnectionProfile, ca dovezile să supraviețuiască recuperării.

Apoi decide aranjamentul permanent, nu pe cel mai rapid. Fie calea de administrare este păstrată explicit de profilul VPN, fie administrarea trece pe un canal care nu depinde de ruta implicită a gazdei. Ambele sunt sustenabile; o rută de gazdă cu o poartă ghicită nu este. Notează pe care ai ales-o și înregistrează adresa perechii care trebuia să supraviețuiască.