Desktop la distanță printr-un VPN: în ce defecțiune te afli?

Tunelul tău este activ, wiki-ul intern se încarcă, iar Desktop la distanță refuză în continuare conexiunea. Combinația este normală, pentru că VPN-ul oferă o rută către gazdă, în timp ce serviciul de desktop trebuie să asculte, să fie permis de propriul firewall și să fie dispus să autentifice contul. Între un tunel funcțional și o sesiune utilizabilă stau patru etape de defecțiune, iar fiecare eșuează cu alt mesaj. Citește mai întâi mesajul, pentru că numește etapa.

Patru defecțiuni care par una singură

Etapele sunt ordonate: numele se rezolvă la adresa privată pe care o prevede proiectarea, portul răspunde la un handshake TCP, gazda acceptă conexiunea conform propriei politici, iar autentificarea în sesiune reușește. Fiecare etapă o face netestabilă pe următoarea, de aceea modificarea setărilor RDP înainte ca rețeaua să fie lămurită produce doar zgomot. Simptomul arată identic din partea utilizatorului în toate cele patru cazuri. Doar mesajul clientului le separă.

Un site intern funcțional nu demonstrează niciuna dintre cele patru. Demonstrează că o gazdă din aceeași rețea a răspuns pe alt port cu alt serviciu. Tratează asta ca dovadă despre rutare și nimic mai mult.

Testează în ordine și notează rezultatul. Să sari la ecranul de autentificare pentru că portul a răspuns este felul în care pierzi o după-amiază pe o problemă de firewall pe care primul pas a localizat-o deja.

Ascultă ceva pe 3389?

Începe cu numele, pentru că un nume care se rezolvă la adresa greșită invalidează fiecare test ulterior. Întreabă resolverul tunelului ce înseamnă numele, apoi compară răspunsul cu adresa privată pe care o prevede proiectarea, nu cu un răspuns reușit. Un nume care se rezolvă la o adresă publică este toată problema, iar nicio modificare RDP nu o va repara:

nslookup desktop.corp.example
Resolve-DnsName desktop.corp.example

Apoi testează portul, nu gazda. Un handshake TCP finalizat pe 3389 separă accesibilitatea de tot ce se află deasupra:

Test-NetConnection -ComputerName desktop.corp.example -Port 3389

Rulează acel test din LAN și din tunel, pentru că o diferență între cele două rezultate localizează defectul pe traseul VPN. Pe traseu stau două firewall-uri și e ușor să le confunzi: rețeaua trebuie să permită adresei tunelului clientului să ajungă la gazdă, iar firewall-ul propriu al gazdei trebuie să permită aceeași sursă pe portul care ascultă. O regulă limitată la subrețeaua LAN nu acoperă pool-ul de clienți VPN, și aceasta este cea mai frecventă cauză a unui timeout pe care îl raportează doar utilizatorii la distanță. Verifică aria de aplicare, nu existența regulii.

Traseul de retur merită aceeași verificare. Răspunsurile au nevoie de o rută înapoi spre pool-ul de clienți și nu spre LAN, iar o traducere în fața gazdei schimbă sursa pe care o va arăta jurnalul tău. Dacă portul răspunde într-o direcție și nu în cealaltă, jumătatea lipsă este de obicei traseul de retur.

Citește mesajul înainte de a citi configurația

A treia etapă este gazda care refuză conexiunea conform propriei politici, ceea ce arată adesea ca un port care se deschide și se închide imediat. Ceva a răspuns, iar asta este informație utilă în loc de tăcere. Dacă handshake-ul s-a încheiat și sesiunea a murit imediat, rețeaua este în regulă și gazda decide. Verifică permisiunile pentru Desktop la distanță înainte de a atinge din nou rețeaua.

Funcția poate fi activată pentru mașină în timp ce accesul este restricționat la grupuri anume, iar listenerul poate fi legat în moduri care exclud adresa de pe care ai venit. Autentificarea la nivel de rețea adaugă o poartă care eșuează înainte de încărcarea desktopului, iar textul erorii diferă de o parolă greșită. Compară mesajul clientului cu jurnalul de evenimente al gazdei, pentru că mesajul numește poarta, iar jurnalul contul.

Autentificarea în sesiune este propria frontieră

Autentificarea aparține serviciului de desktop, nu VPN-ului. Identitatea tunelului și contul de desktop sunt acreditări separate cu politici de blocare separate, așa că un tunel funcțional dovedește doar că tunelul te-a acceptat. Blocarea contului de desktop nu deranjează tunelul, iar inversul este și el adevărat.

Păstrează ambele intacte. Când lipsește ruta privată, repară ruta, pentru că publicarea listenerului pe internet schimbă un defect de accesibilitate pe un desktop expus. Nu slăbi nici verificările de identitate ale sesiunii pentru a trece de un avertisment de certificat apărut în același timp. Un certificat auto-semnat pe un listener RDP produce un avertisment prin proiectare, așa că acceptarea lui este o decizie, nu un pas.

Numără încercările înainte de a reîncerca. Pragurile de blocare ale desktopului numără autentificările eșuate separat de eșecurile VPN, iar un client care reîncearcă pe un timer poate depăși pragul în timp ce încă editezi o regulă. Este același mecanism de reîncercări paralele care blochează conturile după o schimbare de parolă.

Ce poate muta sesiunea și unde rămâne

Învață fluxul de deconectare aprobat înainte de a avea nevoie de el. Închiderea ferestrei poate doar deconecta vizualizarea în timp ce sesiunea continuă să ruleze conform politicii configurate, ceea ce contează pe o gazdă partajată sau auditată. Deconectează-te din interiorul sesiunii când politica așteaptă asta.

Apoi decide ce poate transporta sesiunea, pentru că clipboard-ul, unitățile redirecționate, redirecționarea imprimantei și transferul de fișiere mută date între sistemele local și la distanță acolo unde politica permite. O aplicație publicată care rulează pe cealaltă parte nu este automat o frontieră fără descărcare, iar o sesiune care pare doar-citire poate transporta totuși un clipboard. Testează sarcina reală, nu conexiunea: deschide fișierul, folosește aplicația și confirmă redirecționarea de care ai nevoie. Îndrumările Microsoft pentru a ajunge la un desktop la distanță din exterior descriu opțiunile de expunere acceptate și sunt o referință mai bună decât un listener public adăugat sub presiune.