Waarom RDP vries wanneer die afgeleë rekenaar aan ’n VPN koppel

Jy is binne die RDP-venster, die tafelblad is op die skerm, en jy druk Connect in die VPN-kliënt wat op daardie afgeleë masjien loop. Sekondes later vries die venster en sluit dan. Die tonnel het opgekom, wat presies is wat die VPN-log sal rapporteer, en dit is die mins nuttige feit in die hele voorval. Die sessie het gesterf omdat die masjien met wie jy gepraat het die manier verander het waarop dit jou antwoord, so volg die terugpad voordat jy aan die tonnel raak.

Let op die eindpunt wat jou sessie werklik gebruik

Die adres wat in jou RDP-kliënt ingetik word, is nie noodwendig die adres waarop die afgeleë rekenaar antwoord nie. NAT, ’n RD Gateway of ’n lasbalanseerder voor die gasheer kan dit herskryf, en die terugpad word bepaal deur watter bronadres die afgeleë masjien op die gevestigde verbinding sien. Kry jy dit verkeerd, dan soek jy na ’n roete wat nooit betrokke was nie.

Op die afgeleë rekenaar, voordat die VPN gekoppel is, lys jy die gevestigde sessies en lees die eweknie-adres uit die tabel. Skryf dit dan iewers buite daardie masjien neer, want jy sal dit nie kan lees nadat die sessie val nie.

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

Behandel daardie adres as die ding wat bereikbaar moet bly. As dit ’n privaat adres op ’n bestuurs-VLAN is, moet die tonnel daardie pad met rus laat. As dit ’n openbare adres is, moet die antwoord deur dieselfde koppelvlak uitgaan wat die versoek ingebring het.

Lees die roete wat daardie eindpunt antwoord

Windows kies ’n koppelvlak per bestemming, en Find-NetRoute wys die besluit wat dit nou sou maak. Voer dit teen die eweknie-adres uit voordat jy koppel, dan weer met die tonnel op, en vergelyk die koppelvlakindeks en volgende sprong in die twee antwoorde. ’n Verandering van koppelvlak is die hele fout in een reël uitset.

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

’n Voltonnel-profiel installeer ’n verstekroete deur die tonnel, soos die Windows-gids vir VPN-roetering beskryf, so elke antwoord verlaat nou deur die VPN en hang daarvan af dat die ander kant terug na jou kliënt roeteer. ’n Split-tonnel-profiel is by verstek veiliger maar nie immuun nie, want ’n spesifieke roete wat die eweknie-adres dek, kan steeds die fisiese verstekroete wen. Hoe dit ook al sy, die vraag is identies: nadat die tonnel opkom, los die eweknie-adres steeds op na die koppelvlak wat die sessie ingebring het?

Indien nie, hoort die regstelling in die profiel of in ’n eksplisiete uitsonderingroete wat deur die eienaar van die VPN-beleid goedgekeur is. Om die roetetabel met die hand op ’n produksie-gasheer tydens ’n voorval te redigeer, is hoe ’n tydelike noodoplossing ongedokumenteerde konfigurasie word.

Let op die verandering in die brandmuurprofiel

’n Nuwe koppelvlak word geklassifiseer wanneer dit verskyn, en die klassifikasie bepaal teen watter brandmuurprofiel sy verkeer beoordeel word. ’n Tonnel-adapter wat in die Public-kategorie beland, kan inkomende RDP stilweg stop selfs al lyk die roetetabel perfek. Dit is die tweede foutmodus, en dit lewer ’n ander simptoom: die roete is reg, die pakkette kom aan, en die gasheer weier die verbinding.

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

Vergelyk die profiel wat aan die tonnelkoppelvlak gekoppel is met die profiele waarvoor die Remote Desktop-reëls bestem is. ’n Reël wat slegs vir Domain en Private geaktiveer is, doen niks vir ’n koppelvlak wat as Public geklassifiseer is nie, en geen mate van roeteregstelling verander dit nie. Sommige VPN-kliënte beperk ook plaaslike subnettoegang per ontwerp, wat dieselfde soort faling uit ’n ander beheer voortbring.

Toets die oorgang van ’n plek waar jy kan herstel

Doen die hele reeks vanaf ’n buiteband-konsole of ’n tweede bestuurspad, in hierdie volgorde: bevestig die bestaande sessie, koppel die VPN, maak ’n nuwe sessie oop, ontkoppel dan die VPN en maak nog een oop. Elke stap toets ’n ander oorgang, en die eerste een wat misluk, sê vir jou watter beheer verantwoordelik is.

Beplan die terugrol voordat jy begin, byvoorbeeld ’n geskeduleerde taak wat rasdial "Work VPN" /disconnect ná ’n vasgestelde tydperk uitvoer. Dit verander ’n verlore sessie in ’n onderbreking van vyf minute in plaas van ’n besoek ter plaatse, en dit is die goedkoopste versekering in die hele prosedure.

Kom terug in wanneer die sessie reeds weg is

As die gasheer reeds onbereikbaar is, hou op om nuwe RDP-verbindings vanaf dieselfde kliënt te probeer en gebruik die herstelkanaal wat die omgewing reeds het: ’n RD Gateway, ’n hipervisor-konsole of ’n buiteband-bestuurskoppelvlak. Vra die persoon met konsoltoegang om dieselfde Find-NetRoute en Get-NetConnectionProfile opdragte uit te voer sodat die bewyse die herstel oorleef.

Besluit dan op die permanente reëling eerder as die vinnigste een. Óf die bestuurspad word uitdruklik deur die VPN-profiel bewaar, óf bestuur skuif na ’n kanaal wat nie van die gasheer se verstekroete afhang nie. Albei is verdedigbaar; ’n gasheerroete met ’n geraamde gateway is nie. Skryf neer watter een jy gekies het, en teken die eweknie-adres aan wat moes oorleef.