Kial RDP frostas kiam la fora komputilo konektiĝas al VPN

Vi estas ene de la RDP-fenestro, la labortablo estas sur la ekrano, kaj vi premas Connect en la VPN-kliento kiu funkcias sur tiu fora maŝino. Post sekundoj la fenestro frostas kaj poste fermiĝas. La tunelo ekfunkciis, kio estas ĝuste tio, kion raportos la VPN-protokolo, kaj tio estas la malplej utila fakto en la tuta incidento. La seanco mortis ĉar la maŝino kun kiu vi parolis ŝanĝis la manieron respondi al vi, do esploru la revenan vojon antaŭ ol tuŝi la tunelon.

Notu la finan punkton kiun via seanco efektive uzas

La adreso entajpita en vian RDP-klienton ne nepre estas la adreso al kiu la fora komputilo respondas. NAT, RD Gateway aŭ ŝarĝegalancilo antaŭ la gastiganto povas reverki ĝin, kaj la revenan vojon difinas tiu fontadreso, kiun la fora maŝino vidas sur la establita konekto. Erari ĉi tie sendas vin serĉi itineron kiu neniam partoprenis.

Sur la fora komputilo, antaŭ ol la VPN estas konektita, listigu la establitajn seancajn ligojn kaj legu la samtavolan adreson el la tabelo. Poste skribu ĝin ie ekster tiu maŝino, ĉar vi ne povos legi ĝin post kiam la seanco falos.

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

Traktu tiun adreson kiel tion, kio devas resti atingebla. Se ĝi estas privata adreso sur administra VLAN, la tunelo devas lasi tiun vojon trankvila. Se ĝi estas publika adreso, la respondo devas eliri tra la sama interfaco kiu enportis la peton.

Legu la itineron kiu respondas al tiu fina punkto

Windows elektas interfacon por ĉiu celo, kaj Find-NetRoute montras la decidon kiun ĝi farus nun. Rulu ĝin kontraŭ la samtavola adreso antaŭ konekti, poste denove kun la tunelo supre, kaj komparu la interfacan indekson kaj la sekvan salteton en la du respondoj. Ŝanĝo de interfaco estas la tuta cimo en unu linio de eligo.

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

Plentunela profilo instalas defaŭltan itineron tra la tunelo, kiel la gvidilo de Windows pri VPN-itinerado priskribas, do ĉiu respondo nun eliras tra la VPN kaj dependas de tio, ĉu la alia flanko itineredas reen al via kliento. Disigita tunela profilo estas pli sekura defaŭlte sed ne imuna, ĉar specifa itinero kovranta la samtavolan adreson ankoraŭ povas venki la fizikan defaŭltan itineron. Ĉiuokaze la demando estas identa: post kiam la tunelo ekfunkcias, ĉu la samtavola adreso ankoraŭ solviĝas al la interfaco kiu enportis la seancon?

Se ne, la korekto apartenas al la profilo aŭ al eksplicita escepta itinero aprobita de la posedanto de la VPN-politiko. Redakti la itineran tabelon permane sur produkta gastiganto dum incidento estas kiel provizora solvo fariĝas nedokumentita agordo.

Observu la ŝanĝon de la fajroŝirma profilo

Nova interfaco estas klasifikata kiam ĝi aperas, kaj la klasifiko decidas laŭ kiu fajroŝirma profilo oni juĝas ĝian trafikon. Tunela adaptilo kiu eniras la kategorion Public povas silente haltigi envenantan RDP kvankam la itinera tabelo aspektas perfekta. Tio estas la dua fiaska reĝimo, kaj ĝi produktas alian simptomon: la itinero estas ĝusta, la pakaĵoj alvenas, kaj la gastiganto rifuzas la konekton.

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

Komparu la profilon ligitan al la tunela interfaco kun la celaj profiloj de la reguloj Remote Desktop. Regulo ŝaltita nur por Domain kaj Private faras nenion por interfaco klasifikita kiel Public, kaj neniu itinera korekto tion ŝanĝas. Iuj VPN-klientoj ankaŭ laŭprojekte limigas aliron al la loka subreto, kio produktas la saman formon de fiasko el alia regilo.

Testu la transiron el loko de kie vi povas restarigi

Faru la tutan sinsekvon el ekstrabenda konzolo aŭ dua administra vojo, en ĉi tiu ordo: konfirmu la ekzistantan seancon, konektu la VPN, malfermu novan seancon, poste malkonektu la VPN kaj malfermu ankoraŭ unu. Ĉiu paŝo testas alian transiron, kaj la unua kiu malsukcesas diras al vi kiu regilo respondecas.

Planu la returniron antaŭ ol vi komencas, ekzemple planitan taskon kiu rulas rasdial "Work VPN" /disconnect post difinita intervalo. Tio ŝanĝas perditan seancon en kvinminutan interrompon anstataŭ viziton al la loko, kaj ĝi estas la plej malmultekosta asekuro en la tuta proceduro.

Reeniru kiam la seanco jam mankas

Se la gastiganto jam estas neatinebla, ĉesu provi novajn RDP-konektojn el la sama kliento kaj uzu la restarigan kanalon kiun la medio jam havas: RD Gateway, hipervizilan konzolon aŭ ekstrabendan administran interfacon. Petu la personon kun konzola aliro ruli la samajn komandojn Find-NetRoute kaj Get-NetConnectionProfile, por ke la pruvoj postvivu la restarigon.

Poste decidu la permanentan aranĝon anstataŭ la plej rapidan. Aŭ la administra vojo estas eksplicite konservita de la VPN-profilo, aŭ administrado moviĝas al kanalo kiu ne dependas de la defaŭlta itinero de la gastiganto. Ambaŭ estas subteneblaj; gastiganta itinero kun divenita enirejo ne estas. Skribu kiun vi elektis, kaj registru la samtavolan adreson kiu devis postvivi.