Hvorfor RDP fryser når den eksterne datamaskinen kobler til en VPN

Du er inne i RDP-vinduet, skrivebordet er på skjermen, og du trykker Connect i VPN-klienten som kjører på den eksterne maskinen. Sekunder senere fryser vinduet og lukker seg. Tunnelen kom opp, som er nøyaktig det VPN-loggen vil rapportere, og det er det minst nyttige faktum i hele hendelsen. Økten døde fordi maskinen du snakket med endret måten den svarer deg på, så gå gjennom returveien før du rører tunnelen.

Noter endepunktet økten din faktisk bruker

Adressen som er skrevet inn i RDP-klienten er ikke nødvendigvis adressen den eksterne datamaskinen svarer på. NAT, en RD Gateway eller en lastbalanserer foran verten kan skrive den om, og returveien defineres av kildeadressen den eksterne maskinen ser på den etablerte forbindelsen. Tar du feil her, leter du etter en rute som aldri var involvert.

På den eksterne datamaskinen, før VPN-en er tilkoblet, list opp de etablerte øktene og les peer-adressen ut av tabellen. Skriv den deretter ned et sted utenfor den maskinen, for du kan ikke lese den etter at økten faller.

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

Behandle den adressen som det som må forbli tilgjengelig. Hvis det er en privat adresse på et administrasjons-VLAN, må tunnelen la den veien være. Hvis det er en offentlig adresse, må svaret gå ut gjennom samme grensesnitt som brakte forespørselen inn.

Les ruten som svarer på det endepunktet

Windows velger et grensesnitt per destinasjon, og Find-NetRoute viser beslutningen den ville ta akkurat nå. Kjør den mot peer-adressen før du kobler til, deretter igjen med tunnelen oppe, og sammenlign grensesnittindeksen og neste hopp i de to svarene. En endring av grensesnitt er hele feilen på én linje utdata.

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 fulltunnelprofil installerer en standardrute gjennom tunnelen, slik Windows-veiledningen for VPN-ruting beskriver, så hvert svar går nå ut gjennom VPN-en og avhenger av at den andre siden ruter tilbake til klienten din. En splittunnelprofil er sikrere som standard, men ikke immun, fordi en spesifikk rute som dekker peer-adressen fortsatt kan slå den fysiske standardruten. Uansett er spørsmålet det samme: når tunnelen kommer opp, løses peer-adressen fortsatt til grensesnittet som brakte økten inn?

Hvis ikke, hører rettelsen hjemme i profilen eller i en eksplisitt unntaksrute godkjent av eieren av VPN-policyen. Å redigere rutetabellen for hånd på en produksjonsvert under en hendelse er måten en midlertidig løsning blir udokumentert konfigurasjon.

Følg med på endringen i brannmurprofilen

Et nytt grensesnitt klassifiseres når det dukker opp, og klassifiseringen avgjør hvilken brannmurprofil trafikken vurderes mot. En tunneladapter som havner i kategorien Public kan stille stoppe innkommende RDP selv om rutetabellen ser perfekt ut. Det er den andre feilmodusen, og den gir et annet symptom: ruten er riktig, pakkene kommer frem, og verten avviser forbindelsen.

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

Sammenlign profilen som er knyttet til tunnegrensesnittet, med profilene Remote Desktop-reglene er avgrenset til. En regel som bare er aktivert for Domain og Private gjør ingenting for et grensesnitt klassifisert som Public, og ingen rutekorreksjon endrer det. Noen VPN-klienter begrenser også tilgangen til det lokale subnettet av design, noe som gir samme feilform fra en annen kontroll.

Test overgangen fra et sted du kan komme tilbake fra

Gjør hele sekvensen fra en out-of-band-konsoll eller en andre administrasjonsvei, i denne rekkefølgen: bekreft den eksisterende økten, koble til VPN-en, åpne en ny økt, koble deretter fra VPN-en og åpne enda en. Hvert steg tester en annen overgang, og den første som feiler forteller deg hvilken kontroll som er ansvarlig.

Planlegg tilbakerullingen før du starter, for eksempel en planlagt oppgave som kjører rasdial "Work VPN" /disconnect etter et fast intervall. Det gjør en tapt økt til en fem minutters avbrytelse i stedet for et besøk på stedet, og det er den billigste forsikringen i hele prosedyren.

Kom inn igjen når økten allerede er borte

Hvis verten allerede er utilgjengelig, slutt å prøve nye RDP-tilkoblinger fra samme klient og bruk gjenopprettingskanalen miljøet allerede har: en RD Gateway, en hypervisor-konsoll eller et out-of-band-administrasjonsgrensesnitt. Be personen med konsolltilgang kjøre de samme kommandoene Find-NetRoute og Get-NetConnectionProfile, slik at bevisene overlever gjenopprettingen.

Bestem deretter den permanente ordningen i stedet for den raskeste. Enten bevares administrasjonsveien uttrykkelig av VPN-profilen, eller så flyttes administrasjonen til en kanal som ikke avhenger av vertens standardrute. Begge er forsvarlige; en vertsrute med en gjettet gateway er det ikke. Skriv ned hvilken du valgte, og registrer peer-adressen som måtte overleve.