Kvifor RDP frys når den eksterne datamaskinen koplar til ein VPN

Du er inne i RDP-vindauget, skrivebordet er på skjermen, og du trykkjer Connect i VPN-klienten som køyrer på den eksterne maskinen. Sekund seinare frys vindauget og lukkar seg. Tunnelen kom opp, som er nøyaktig det VPN-loggen vil rapportere, og det er det minst nyttige faktumet i heile hendinga. Økta døydde fordi maskinen du snakka med endra måten han svarar deg på, så gå gjennom returvegen før du rører tunnelen.

Noter endepunktet økta di faktisk brukar

Adressa som er skriven inn i RDP-klienten er ikkje nødvendigvis adressa den eksterne datamaskinen svarar på. NAT, ein RD Gateway eller ein lastbalansar framfor verten kan skrive henne om, og returvegen blir definert av kjeldeadressa den eksterne maskinen ser på den etablerte sambindinga. Tek du feil her, leitar du etter ei rute som aldri var involvert.

På den eksterne datamaskinen, før VPN-en er tilkopla, list opp dei etablerte øktene og les peer-adressa ut av tabellen. Skriv henne deretter ned ein stad utanfor den maskinen, for du kan ikkje lese henne etter at økta fell.

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

Behandle den adressa som det som må halde fram med å vere tilgjengeleg. Er det ei privat adresse på eit administrasjons-VLAN, må tunnelen la den vegen vere. Er det ei offentleg adresse, må svaret gå ut gjennom same grensesnittet som brakte førespurnaden inn.

Les ruta som svarar på det endepunktet

Windows vel eit grensesnitt per destinasjon, og Find-NetRoute viser avgjerda han ville ta akkurat no. Køyr henne mot peer-adressa før du koplar til, deretter igjen med tunnelen oppe, og samanlikn grensesnittindeksen og neste hopp i dei to svara. Ei endring av grensesnitt er heile feilen på éi 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

Ein fulltunnelprofil installerer ei standardrute gjennom tunnelen, slik Windows-veiledninga for VPN-ruting skildrar, så kvart svar går no ut gjennom VPN-en og er avhengig av at den andre sida ruter tilbake til klienten din. Ein splittunnelprofil er tryggare som standard, men ikkje immun, fordi ei spesifikk rute som dekkjer peer-adressa framleis kan slå den fysiske standardruta. Uansett er spørsmålet det same: når tunnelen kjem opp, blir peer-adressa framleis løyst til grensesnittet som brakte økta inn?

Viss ikkje, høyrer rettinga heime i profilen eller i ei eksplisitt unntaksrute godkjend av eigaren av VPN-policyen. Å redigere rutetabellen for hand på ein produksjonsvert under ei hending er måten ei mellombels løysing blir udokumentert konfigurasjon.

Følg med på endringa i brannmurprofilen

Eit nytt grensesnitt blir klassifisert når det dukkar opp, og klassifiseringa avgjer kva brannmurprofil trafikken blir vurdert mot. Ein tunneladapter som hamnar i kategorien Public kan stille stoppe innkommande RDP sjølv om rutetabellen ser perfekt ut. Det er den andre feilmodusen, og han gir eit anna symptom: ruta er riktig, pakkane kjem fram, og verten avviser sambindinga.

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

Samanlikn profilen som er knytt til tunnegrensesnittet, med profilane Remote Desktop-reglane er avgrensa til. Ein regel som berre er aktivert for Domain og Private gjer ingenting for eit grensesnitt klassifisert som Public, og inga rutekorreksjon endrar det. Nokre VPN-klientar begrensar òg tilgangen til det lokale subnettet av design, noko som gir same feilform frå ein annan kontroll.

Test overgangen frå ein stad du kan kome tilbake frå

Gjer heile sekvensen frå ein out-of-band-konsoll eller ein andre administrasjonsveg, i denne rekkjefølgja: stadfest den eksisterande økta, kople til VPN-en, opne ei ny økt, kople deretter frå VPN-en og opne endå ei. Kvart steg testar ein annan overgang, og den første som feilar fortel deg kva kontroll som er ansvarleg.

Planlegg tilbakerullinga før du startar, til dømes ein planlagd oppgåve som køyrer rasdial "Work VPN" /disconnect etter eit fast intervall. Det gjer ei tapt økt til ein fem minutts avbryting i staden for eit besøk på staden, og det er den billigaste forsikringa i heile prosedyren.

Kom inn att når økta allereie er borte

Viss verten allereie er utilgjengeleg, slutt å prøve nye RDP-tilkoplingar frå same klient og bruk gjenopprettingskanalen miljøet allereie har: ein RD Gateway, ein hypervisor-konsoll eller eit out-of-band-administrasjonsgrensesnitt. Be personen med konsolltilgang køyre dei same kommandoane Find-NetRoute og Get-NetConnectionProfile, slik at prova overlever gjenopprettinga.

Avgjer deretter den permanente ordninga i staden for den raskaste. Anten blir administrasjonsvegen uttrykkeleg teken vare på av VPN-profilen, eller så blir administrasjonen flytta til ein kanal som ikkje er avhengig av standardruta til verten. Begge er forsvarlege; ei vertsrute med ein gjett gateway er det ikkje. Skriv ned kva du valde, og registrer peer-adressa som måtte overleve.