Waarom RDP vastloopt wanneer de externe computer verbinding maakt met een VPN

Je zit in het RDP-venster, het bureaublad staat op het scherm en je drukt op Connect in de VPN-client die op die externe machine draait. Seconden later loopt het venster vast en sluit het. De tunnel kwam omhoog, precies dat zal het VPN-log melden, en dat is het minst nuttige feit van het hele incident. De sessie stierf omdat de machine waarmee je sprak de manier veranderde waarop hij je antwoordt, dus bekijk de terugweg voordat je de tunnel aanraakt.

Noteer het eindpunt dat je sessie werkelijk gebruikt

Het adres dat je in de RDP-client typt is niet noodzakelijk het adres waarop de externe computer antwoordt. NAT, een RD Gateway of een load balancer voor de host kunnen het herschrijven, en de terugweg wordt bepaald door het bronadres dat de externe machine op de bestaande verbinding ziet. Vergis je hierin, dan zoek je een route die er nooit bij betrokken was.

Op de externe computer, voordat de VPN is verbonden, som je de bestaande sessies op en lees je het peeradres uit de tabel. Schrijf het daarna ergens buiten die machine op, want je kunt het niet meer lezen nadat de sessie wegvalt.

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

Behandel dat adres als het ding dat bereikbaar moet blijven. Is het een privéadres op een beheer-VLAN, dan moet de tunnel dat pad met rust laten. Is het een openbaar adres, dan moet het antwoord naar buiten gaan via dezelfde interface die het verzoek binnenbracht.

Lees de route die dat eindpunt beantwoordt

Windows kiest per bestemming een interface, en Find-NetRoute toont de beslissing die het nu zou nemen. Voer het uit tegen het peeradres voordat je verbindt, daarna opnieuw met de tunnel omhoog, en vergelijk de interface-index en de volgende hop in beide antwoorden. Een verandering van interface is de hele fout in één regel uitvoer.

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

Een full-tunnelprofiel installeert een standaardroute door de tunnel, zoals de Windows-handleiding voor VPN-routering beschrijft, dus elk antwoord verlaat nu de machine via de VPN en hangt ervan af of de andere kant terugrouteert naar je client. Een split-tunnelprofiel is standaard veiliger maar niet immuun, omdat een specifieke route die het peeradres dekt de fysieke standaardroute nog steeds kan verslaan. Hoe dan ook is de vraag identiek: lost het peeradres, nadat de tunnel omhoog is gekomen, nog steeds op naar de interface die de sessie binnenbracht?

Zo niet, dan hoort de correctie in het profiel of in een expliciete uitzonderingsroute die is goedgekeurd door de eigenaar van het VPN-beleid. De routetabel met de hand bewerken op een productiehost tijdens een incident is hoe een tijdelijke oplossing ongedocumenteerde configuratie wordt.

Let op de verandering van het firewallprofiel

Een nieuwe interface wordt geclassificeerd wanneer hij verschijnt, en de classificatie bepaalt tegen welk firewallprofiel het verkeer wordt beoordeeld. Een tunneladapter die in de categorie Public belandt, kan inkomend RDP stil stoppen terwijl de routetabel perfect lijkt. Dat is de tweede faalmodus, en die geeft een ander symptoom: de route is juist, de pakketten komen aan en de host weigert de verbinding.

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

Vergelijk het profiel dat aan de tunnelinterface hangt met de profielen waarop de Remote Desktop-regels zijn gericht. Een regel die alleen voor Domain en Private is ingeschakeld, doet niets voor een interface die als Public is geclassificeerd, en geen routecorrectie verandert dat. Sommige VPN-clients beperken ook het bereik naar het lokale subnet by design, wat dezelfde faalvorm uit een andere controle oplevert.

Test de overgang vanaf een plek waar je terug kunt komen

Doe de hele reeks vanaf een out-of-band-console of een tweede beheerpad, in deze volgorde: bevestig de bestaande sessie, verbind de VPN, open een nieuwe sessie, verbreek daarna de VPN en open er nog een. Elke stap test een andere overgang, en de eerste die faalt vertelt je welke controle verantwoordelijk is.

Plan de terugrol voordat je begint, bijvoorbeeld een geplande taak die rasdial "Work VPN" /disconnect na een vast interval uitvoert. Dat maakt van een verloren sessie een onderbreking van vijf minuten in plaats van een bezoek ter plaatse, en het is de goedkoopste verzekering in de hele procedure.

Kom weer binnen wanneer de sessie al weg is

Als de host al onbereikbaar is, stop dan met het proberen van nieuwe RDP-verbindingen vanaf dezelfde client en gebruik het herstelkanaal dat de omgeving al heeft: een RD Gateway, een hypervisor-console of een out-of-band-beheerinterface. Vraag de persoon met consoletoegang dezelfde opdrachten Find-NetRoute en Get-NetConnectionProfile uit te voeren, zodat het bewijs het herstel overleeft.

Bepaal daarna de blijvende regeling in plaats van de snelste. Ofwel blijft het beheerpad expliciet behouden door het VPN-profiel, ofwel verhuist beheer naar een kanaal dat niet afhankelijk is van de standaardroute van de host. Beide zijn verdedigbaar; een hostroute met een geraden gateway niet. Schrijf op welke je koos, en leg het peeradres vast dat moest overleven.