Hvorfor RDP fryser, når den eksterne computer opretter forbindelse til en VPN

Du er inde i RDP-vinduet, skrivebordet er på skærmen, og du trykker Connect i VPN-klienten, der kører på den eksterne maskine. Sekunder senere fryser vinduet og lukker derefter. Tunnelen kom op, hvilket er præcis det, VPN-loggen vil rapportere, og det er den mindst nyttige kendsgerning i hele hændelsen. Sessionen døde, fordi maskinen, du talte med, ændrede den måde, den svarer dig på, så gennemgå returvejen, før du rører tunnelen.

Notér det endepunkt, din session faktisk bruger

Adressen, der er skrevet i din RDP-klient, er ikke nødvendigvis den adresse, den eksterne computer svarer på. NAT, en RD Gateway eller en load balancer foran værten kan omskrive den, og returvejen defineres af den kildeadresse, den eksterne maskine ser på den etablerede forbindelse. Tager du fejl her, leder du efter en rute, der aldrig var involveret.

På den eksterne computer, før VPN’en er tilsluttet, skal du liste de etablerede sessioner og læse peer-adressen ud af tabellen. Skriv den derefter ned et sted uden for den maskine, for du kan ikke læse den, når sessionen falder.

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

Behandl den adresse som det, der skal forblive tilgængeligt. Hvis det er en privat adresse på et administrations-VLAN, skal tunnelen lade den vej være. Hvis det er en offentlig adresse, skal svaret gå ud gennem samme interface, som bragte anmodningen ind.

Læs den rute, der svarer på det endepunkt

Windows vælger et interface pr. destination, og Find-NetRoute viser den beslutning, den ville træffe lige nu. Kør den mod peer-adressen før tilslutning, derefter igen med tunnelen oppe, og sammenlign interfaceindeks og næste hop i de to svar. En ændring af interface er hele fejlen på én linje output.

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

En full-tunnel-profil installerer en standardrute gennem tunnelen, som Windows-vejledningen til VPN-routing beskriver, så hvert svar nu forlader gennem VPN’en og afhænger af, at den anden side router tilbage til din klient. En split-tunnel-profil er sikrere som standard, men ikke immun, fordi en specifik rute, der dækker peer-adressen, stadig kan vinde over den fysiske standardrute. Uanset hvad er spørgsmålet det samme: når tunnelen kommer op, oversættes peer-adressen så stadig til det interface, der bragte sessionen ind?

Hvis ikke, hører rettelsen hjemme i profilen eller i en eksplicit undtagelsesrute, der er godkendt af ejeren af VPN-politikken. At redigere rutetabellen i hånden på en produktionsvært under en hændelse er måden, hvorpå en midlertidig løsning bliver udokumenteret konfiguration.

Hold øje med ændringen af firewallprofilen

Et nyt interface klassificeres, når det dukker op, og klassificeringen afgør, hvilken firewallprofil dets trafik vurderes efter. En tunneladapter, der lander i kategorien Public, kan lydløst stoppe indgående RDP, selv om rutetabellen ser perfekt ud. Det er den anden fejltilstand, og den giver et andet symptom: ruten er rigtig, pakkerne ankommer, og værten afviser forbindelsen.

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

Sammenlign profilen, der er knyttet til tunnelinterfacet, med de profiler, som Remote Desktop-reglerne er afgrænset til. En regel, der kun er aktiveret for Domain og Private, gør intet for et interface klassificeret som Public, og ingen rutekorrektion ændrer det. Nogle VPN-klienter begrænser også adgang til det lokale subnet af design, hvilket giver samme form for fejl fra en anden kontrol.

Test overgangen fra et sted, hvor du kan komme tilbage

Udfør hele sekvensen fra en out-of-band-konsol eller en anden administrationsvej, i denne rækkefølge: bekræft den eksisterende session, tilslut VPN’en, åbn en ny session, afbryd derefter VPN’en og åbn endnu en. Hvert trin tester en anden overgang, og det første, der fejler, fortæller dig, hvilken kontrol der er ansvarlig.

Planlæg tilbagerulningen, før du starter, for eksempel en planlagt opgave, der kører rasdial "Work VPN" /disconnect efter et fast interval. Det gør en tabt session til en fem minutters afbrydelse i stedet for et besøg på stedet, og det er den billigste forsikring i hele proceduren.

Kom ind igen, når sessionen allerede er væk

Hvis værten allerede er uopnåelig, skal du stoppe med at prøve nye RDP-forbindelser fra samme klient og bruge den gendannelseskanal, miljøet allerede har: en RD Gateway, en hypervisor-konsol eller et out-of-band-administrationsinterface. Bed personen med konsoladgang om at køre de samme kommandoer Find-NetRoute og Get-NetConnectionProfile, så beviset overlever gendannelsen.

Beslut derefter den permanente ordning frem for den hurtigste. Enten bevares administrationsvejen udtrykkeligt af VPN-profilen, eller også flyttes administrationen til en kanal, der ikke afhænger af værtens standardrute. Begge er holdbare; en værtsrute med en gættet gateway er ikke. Skriv ned, hvilken du valgte, og registrér den peer-adresse, der skulle overleve.