Warum RDP einfriert, wenn der Remote-Computer eine VPN-Verbindung aufbaut

Sie sind im RDP-Fenster, der Desktop ist auf dem Bildschirm, und Sie drücken Connect im VPN-Client, der auf dieser entfernten Maschine läuft. Sekunden später friert das Fenster ein und schließt sich dann. Der Tunnel kam hoch, genau das wird das VPN-Log melden, und das ist die am wenigsten nützliche Tatsache im gesamten Vorfall. Die Sitzung starb, weil die Maschine, mit der Sie sprachen, die Art ihrer Antwort geändert hat, also prüfen Sie den Rückweg, bevor Sie den Tunnel anfassen.

Notieren Sie den Endpunkt, den Ihre Sitzung tatsächlich nutzt

Die in Ihren RDP-Client eingetragene Adresse ist nicht zwangsläufig die Adresse, auf die der entfernte Rechner antwortet. NAT, ein RD Gateway oder ein Load Balancer vor dem Host können sie umschreiben, und der Rückweg wird durch die Quelladresse bestimmt, die die entfernte Maschine auf der bestehenden Verbindung sieht. Machen Sie hier einen Fehler, suchen Sie eine Route, die nie beteiligt war.

Listen Sie auf dem entfernten Rechner, bevor die VPN verbunden ist, die bestehenden Sitzungen auf und lesen Sie die Peer-Adresse aus der Tabelle. Schreiben Sie sie dann außerhalb dieser Maschine auf, denn nach dem Abbruch der Sitzung können Sie sie nicht mehr lesen.

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

Behandeln Sie diese Adresse als das, was erreichbar bleiben muss. Ist es eine private Adresse in einem Management-VLAN, muss der Tunnel diesen Pfad in Ruhe lassen. Ist es eine öffentliche Adresse, muss die Antwort über dieselbe Schnittstelle hinausgehen, die die Anfrage hereingebracht hat.

Lesen Sie die Route, die diesen Endpunkt beantwortet

Windows wählt pro Ziel eine Schnittstelle, und Find-NetRoute zeigt die Entscheidung, die es gerade jetzt treffen würde. Führen Sie es gegen die Peer-Adresse aus, bevor Sie verbinden, dann erneut mit aufgebautem Tunnel, und vergleichen Sie Schnittstellenindex und nächsten Hop in beiden Antworten. Ein Wechsel der Schnittstelle ist der ganze Fehler in einer Zeile Ausgabe.

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 Full-Tunnel-Profil installiert eine Standardroute durch den Tunnel, wie der Windows-Leitfaden zum VPN-Routing beschreibt, also verlässt jede Antwort nun die Maschine über die VPN und hängt davon ab, dass die Gegenseite zurück zu Ihrem Client routet. Ein Split-Tunnel-Profil ist standardmäßig sicherer, aber nicht immun, denn eine spezifische Route, die die Peer-Adresse abdeckt, kann die physische Standardroute weiterhin schlagen. Wie auch immer, die Frage ist identisch: Löst die Peer-Adresse nach dem Aufbau des Tunnels noch auf die Schnittstelle auf, die die Sitzung hereingebracht hat?

Wenn nicht, gehört die Korrektur ins Profil oder in eine ausdrückliche Ausnahme-Route, die der Eigentümer der VPN-Richtlinie genehmigt. Die Routingtabelle während eines Vorfalls von Hand auf einem Produktionshost zu bearbeiten, ist der Weg, auf dem aus einem vorübergehenden Workaround undokumentierte Konfiguration wird.

Beobachten Sie den Wechsel des Firewallprofils

Eine neue Schnittstelle wird bei ihrem Erscheinen klassifiziert, und die Klassifizierung entscheidet, gegen welches Firewallprofil ihr Verkehr bewertet wird. Ein Tunneladapter, der in der Kategorie Public landet, kann eingehendes RDP stillschweigend stoppen, obwohl die Routingtabelle perfekt aussieht. Das ist der zweite Fehlermodus, und er erzeugt ein anderes Symptom: Die Route stimmt, die Pakete kommen an, und der Host verweigert die Verbindung.

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

Vergleichen Sie das an die Tunnelschnittstelle gebundene Profil mit den Profilen, für die die Remote Desktop-Regeln gelten. Eine nur für Domain und Private aktivierte Regel bewirkt nichts für eine als Public klassifizierte Schnittstelle, und keine Routenkorrektur ändert das. Manche VPN-Clients beschränken außerdem den Zugriff auf das lokale Subnetz konstruktionsbedingt, was dieselbe Fehlerform aus einem anderen Mechanismus erzeugt.

Testen Sie den Übergang von einem Ort, von dem aus Sie zurückkommen können

Führen Sie die gesamte Sequenz von einer Out-of-Band-Konsole oder einem zweiten Management-Pfad in dieser Reihenfolge aus: bestehende Sitzung bestätigen, VPN verbinden, neue Sitzung öffnen, dann VPN trennen und noch eine öffnen. Jeder Schritt testet einen anderen Übergang, und der erste, der scheitert, sagt Ihnen, welcher Mechanismus verantwortlich ist.

Planen Sie das Zurückrollen, bevor Sie beginnen, zum Beispiel eine geplante Aufgabe, die rasdial "Work VPN" /disconnect nach einem festen Intervall ausführt. Das macht aus einer verlorenen Sitzung eine fünfminütige Unterbrechung statt eines Besuchs vor Ort, und es ist die billigste Versicherung im ganzen Verfahren.

Kommen Sie wieder hinein, wenn die Sitzung schon weg ist

Ist der Host bereits unerreichbar, hören Sie auf, neue RDP-Verbindungen vom selben Client zu versuchen, und nutzen Sie den Wiederherstellungskanal, den die Umgebung schon hat: ein RD Gateway, eine Hypervisor-Konsole oder eine Out-of-Band-Management-Schnittstelle. Bitten Sie die Person mit Konsolenzugriff, dieselben Befehle Find-NetRoute und Get-NetConnectionProfile auszuführen, damit die Beweise die Wiederherstellung überleben.

Entscheiden Sie danach die dauerhafte Regelung statt der schnellsten. Entweder bleibt der Management-Pfad ausdrücklich durch das VPN-Profil erhalten, oder die Verwaltung wechselt auf einen Kanal, der nicht von der Standardroute des Hosts abhängt. Beides ist vertretbar; eine Host-Route mit geratenem Gateway nicht. Schreiben Sie auf, für welche Sie sich entschieden haben, und halten Sie die Peer-Adresse fest, die überleben musste.