RDP se oprește după instalarea unui client VPN? Vina este a firewall-ului

La câteva minute după ce un client VPN de consum termină instalarea, portalul încă spune că VM-ul rulează, IP-ul public nu s-a schimbat, iar RDP nu răspunde. Oamenii presupun de obicei că VM-ul a crăpat sau că s-a schimbat grupul de securitate al rețelei, iar ambele sunt de obicei greșite. Ce s-a schimbat este profilul firewall-ului Windows în care se află mașina, iar regula RDP care se potrivea înainte nu mai corespunde. Reparația începe prin obținerea unui shell pe o cale care nu depinde de RDP.

VM-ul rulează; regula nu mai corespunde

Regulile firewall-ului din Windows poartă un set de profiluri, iar o regulă limitată la Privat sau Domeniu nu are efect cât timp mașina este pe profilul Public. Instalatoarele VPN adaugă adaptoare și rute, iar multe dintre ele întăresc profilul Public ca efect secundar. Ascultătorul rămâne legat de 3389 și pachetele încă sosesc, dar nepotrivirea de profil le aruncă.

Starea alimentării și accesibilitatea sunt fapte separate, iar un VM care rulează cu un port închis arată din exterior exact ca unul crăpat.

Testați portul înainte de a schimba ceva. O încercare de conectare la 3389 care expiră în timp ce o comandă a agentului invitat încă returnează ieșire indică firewall-ul gazdei. Un port care răspunde în timp ce RDP încă eșuează înseamnă că defecțiunea este deasupra stratului de rețea, iar această reparație nu o va atinge. Notați care dintre cele două cazuri l-ați văzut, pentru că restul planului depinde de asta.

Două porți se închid independent

Politica platformei rulează prima: grupul de securitate al rețelei vede pachetul înaintea invitatului. Această ordine face o intrare NSG perfectă inutilă când gazda aruncă pachetul, și o regulă de gazdă deschisă inutilă când platforma o refuză. Tratați-le ca porți separate și testați fiecare în parte.

Citiți regulile efective ale NSG în portal sau în CLI, apoi comparați-le cu regulile invitatului însuși. Nu presupuneți că ultima modificare pe care o țineți minte este cea care a intrat în vigoare.

Un client de consum poate instala și un driver de filtrare sau un kill switch care blochează traficul sub firewall-ul Windows. Dacă regulile firewall-ului par corecte și portul încă eșuează, acel strat este următorul suspect.

Folosiți agentul invitat ca cale de întoarcere

Două funcții de execuție la distanță, Run Command și Custom Script Extension, rulează în interiorul invitatului prin agentul platformei. Niciuna nu are nevoie de RDP, așa că eroarea de firewall nu le afectează. Ambele returnează ieșirea scriptului, ceea ce le face canal de diagnostic și totodată canal de reparație.

Citiți profilul activ și regula RDP înainte de a schimba oricare dintre ele:

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

Reactivarea regulilor de intrare pe acel profil este o măsură temporară, nu o destinație. Folosiți-o pentru a obține o sesiune, apoi închideți corect golul:

Set-NetFirewallProfile -Name Public -AllowInboundRules True

Acest comutator deschide fiecare regulă de intrare din profil, nu doar RDP. După ce aveți o sesiune, înlocuiți-l cu o regulă restrânsă și restabiliți setările pe care le doriți cu adevărat. Dacă nici agentul nu este disponibil, o consolă serială sau un disc reconstruit este soluția de rezervă, și acesta este motivul practic de a menține agentul sănătos.

Strângeți golul înainte de a închide sesiunea

Schimbarea temporară de profil este o ușă ținută deschisă pentru fiecare regulă de intrare a acelui profil. Înlocuiți-o cu o regulă limitată la adresa dumneavoastră sursă și la portul RDP, apoi confirmați că profilul a revenit la starea dorită. Faceți acest lucru cât timp aveți încă sesiunea, pentru că următoarea greșeală s-ar putea să nu fie reversibilă de la distanță. Țineți pregătită o a doua cale administrativă, precum Bastion sau o consolă serială, în timpul schimbării.

Confirmați rezultatul de la stația de lucru cu un test de port, iar din interiorul invitatului cu lista de reguli:

Test-NetConnection -ComputerName 203.0.113.25 -Port 3389
Get-NetFirewallRule -DisplayName "RDP from admin" | Get-NetFirewallPortFilter

Activați înregistrarea firewall-ului pe durata testului. O singură linie despre un pachet aruncat care menționează 3389 și profilul activ răspunde la întrebare mai repede decât o altă repornire.

Împiedicați următorul instalator să o facă din nou

Dacă acea gazdă nu are vreun motiv să ruleze clientul, dezinstalați-l. Un client instalat este o invitație permanentă ca următoarea actualizare să rescrie din nou profilul, iar următoarea persoană va depana aceeași întrerupere din portal.

Faceți o instantanee a discului înainte de a lăsa ceva să rescrie setările de rețea, și țineți o a doua cale administrativă gata înainte de a avea nevoie de ea.

Notați ce a modificat instalatorul: adaptoare, rute, profiluri de firewall, drivere de filtrare și servicii. Acea evidență transformă următorul incident într-un tipar cunoscut în loc de o anchetă nouă. Când VM-ul are nevoie de un tunel către exact un serviciu, puneți clientul pe stația de lucru sau construiți o legătură între locații în loc să instalați pe server un produs pentru laptopuri. Clienții de consum se adresează laptopurilor, iar un server pe care îl administrați de la distanță nu este așa.