Wêrom RDP befriest as de ôfstâns kompjûter ferbynt mei in VPN

Jo binne yn it RDP-finster, it buroblêd stiet op it skerm, en jo drukke Connect yn de VPN-klant dy’t op dy ôfstâns masine rint. Sekonden letter befriest it finster en slút dan. De tunnel kaam omheech, dat is krekt wat de VPN-loch melde sil, en dat is it minst nuttige feit yn it hiele foarfal. De sesje stoar omdat de masine dêr’t jo mei praten de manier feroare hoe’t dy jo antwurdet, dus kontrolearje it weromwei foar’t jo de tunnel oanreitsje.

Skriuw it einpunt op dat jo sesje eins brûkt

It adres dat yn jo RDP-klant typt is net needsaaklik itselde adres dêr’t de ôfstâns kompjûter op antwurdet. NAT, in RD Gateway of in lêstbalansearder foar de host kinne it oerskriuwe, en it weromwei wurdt bepaald troch it boarneadres dat de ôfstâns masine op de oprjochte ferbining sjocht. Mist jo hjir, dan sykje jo in rûte dy’t nea belutsen wie.

Op de ôfstâns kompjûter, foar’t de VPN ferbûn is, listje jo de oprjochte sesjes en lêze jo it peeradres út de tabel. Skriuw it dan earne bûten dy masine op, want jo kinne it net lêze nei’t de sesje falt.

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

Behannelje dat adres as it ding dat berikber bliuwe moat. As it in privee-adres op in behear-VLAN is, moat de tunnel dat paad mei rêst litte. As it in iepenbier adres is, moat it antwurd troch deselde ynterface nei bûten gean dy’t it fersyk nei binnen brocht hat.

Lês de rûte dy’t dat einpunt antwurdet

Windows kiest in ynterface foar elke bestimming, en Find-NetRoute lit it beslút sjen dat it no nimme soe. Rin it tsjin it peeradres foar’t jo ferbine, dan wer mei de tunnel omheech, en fergelykje de ynterface-yndeks en de folgjende hop yn de beide antwurden. In feroaring fan ynterface is de hiele flater yn ien rigel útfier.

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

In foltunnelprofyl ynstallearret in standertrûte troch de tunnel, sa’t de Windows-gids foar VPN-routing it beskriuwt, dus elk antwurd giet no troch de VPN nei bûten en hinget derfan ôf oft de oare kant werom nei jo klant rûtet. In splitstunnelprofyl is standert feiliger mar net ymmún, want in spesifike rûte dy’t it peeradres dekt kin de fysike standertrûte noch altyd ferslaan. Hoe dan ek, de fraach is itselde: nei’t de tunnel omheech giet, löst it peeradres dan noch altyd op nei de ynterface dy’t de sesje nei binnen brocht hat?

Sa nee, dan heart de korreksje yn it profyl of yn in eksplisite útsûnderingsrûte dy’t troch de eigner fan it VPN-belied goedkard is. It hânmjittich bewurkjen fan de routingtabel op in produksje-host yn in foarfal is hoe’t in tydlike omwei ûndokumintearre konfiguraasje wurdt.

Hâld de feroaring fan it firewallprofyl yn it each

In nije ynterface wurdt klassifisearre as dy ferskynt, en de klassifikaasje beslút tsjin hokker firewallprofyl it ferkear beoardiele wurdt. In tunneladapter dy’t yn de kategory Public belânet kin ynkommen RDP stil stopje, sels as de routingtabel perfekt liket. Dat is de twadde flatermodus, en dy jout in oar symptoom: de rûte is goed, de pakketten komme oan, en de host wegere de ferbining.

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

Fergelykje it profyl dat oan de tunnelinterface keppele is mei de profylen dêr’t de Remote Desktop-regels op rjochte binne. In regel dy’t allinnich foar Domain en Private oan stiet docht neat foar in ynterface dy’t as Public klassifisearre is, en gjin rûtekorreksje feroaret dat. Guon VPN-klanten beheine ek de tagong ta it lokale subnet by ûntwerp, wat deselde foarm fan flater út in oar kontrôle jout.

Test de oergong fan in plak dêr’t jo weromkomme kinne

Doch de hiele sekwinsje fan in bûtenbânskonsole of in twadde behearpaad, yn dizze folchoarder: befêstigje de besteande sesje, ferbynje de VPN, iepenje in nije sesje, ferbrek dan de VPN en iepenje noch ien. Eltse stap testet in oare oergong, en de earste dy’t mislearret fertelt jo hokker kontrôle ferantwurdlik is.

Plen it weromdraaien foar’t jo begjinne, bygelyks in plande taak dy’t rasdial "Work VPN" /disconnect nei in fêst ynterval útfiert. Dat makket fan in ferlern sesje in ûnderbrekking fan fiif minuten yn plak fan in besite oan it plak, en it is de bêste koop yn de hiele proseduere.

Kom wer binnen as de sesje al fuort is

As de host al net berikber is, stopje dan mei it besykjen fan nije RDP-ferbiningen fan deselde klant en brûk it herstelmakanaal dat de omjouwing al hat: in RD Gateway, in hypervisor-konsole of in bûtenbânsk behearynterface. Freegje de persoan mei konsoletagong deselde opdrachten Find-NetRoute en Get-NetConnectionProfile út te fieren, sadat it bewiis it herstel oerlibbet.

Beslút dan de permaninte regeling yn plak fan de fluchste. Of it behearpaad wurdt eksplisyt troch it VPN-profyl bewarre, of it behear ferhûzet nei in kanaal dat net fan de standertrûte fan de host ôfhinget. Beide binne te ferdigenjen; in hostrûte mei in rieden gateway net. Skriuw op hokker jo keazen hawwe, en registrearje it peeradres dat oerlibje moast.