RDP bricht nach der Installation eines VPN-Clients ab? Die Firewall ist schuld

Wenige Minuten, nachdem ein Verbraucher-VPN-Client die Installation abgeschlossen hat, meldet das Portal weiterhin, die VM laufe, die öffentliche IP habe sich nicht geändert, und RDP antwortet nicht. Meist wird vermutet, die VM sei abgestürzt oder die Netzwerksicherheitsgruppe habe sich geändert, und beides ist üblicherweise falsch. Geändert hat sich das Windows-Firewallprofil, in dem die Maschine steht, und die RDP-Regel, die früher passte, passt nicht mehr. Die Reparatur beginnt damit, eine Shell über einen Weg zu bekommen, der nicht von RDP abhängt.

Die VM läuft; die Regel passt nicht mehr

Firewallregeln unter Windows tragen eine Profilmenge, und eine auf Privat oder Domäne beschränkte Regel hat keine Wirkung, solange die Maschine im öffentlichen Profil steht. VPN-Installer fügen Adapter und Routen hinzu, und mehrere davon härten das öffentliche Profil als Nebenwirkung. Der Listener bleibt an 3389 gebunden, und die Pakete kommen weiterhin an, aber die Profilabweichung verwirft sie.

Energiezustand und Erreichbarkeit sind getrennte Fakten, und eine laufende VM mit geschlossenem Port sieht von außen genau wie eine abgestürzte aus.

Prüfen Sie den Port, bevor Sie irgendetwas ändern. Ein Verbindungsversuch auf 3389, der in einen Timeout läuft, während ein Befehl des Gast-Agents weiterhin Ausgabe liefert, deutet auf die Firewall des Hosts. Ein Port, der antwortet, während RDP weiterhin scheitert, bedeutet, dass der Fehler oberhalb der Netzwerkschicht sitzt, und diese Reparatur wird ihn nicht berühren. Notieren Sie, welchen der beiden Fälle Sie gesehen haben, denn der Rest des Plans hängt davon ab.

Zwei Tore schließen unabhängig voneinander

Zuerst läuft die Fabric-Richtlinie: die Netzwerksicherheitsgruppe sieht das Paket vor dem Gast. Diese Reihenfolge macht einen perfekten NSG-Eintrag nutzlos, wenn der Host das Paket verwirft, und eine offene Hostregel nutzlos, wenn die Fabric sie verweigert. Behandeln Sie beides als getrennte Tore und testen Sie jedes für sich.

Lesen Sie die wirksamen Regeln der NSG im Portal oder in der CLI und vergleichen Sie sie dann mit den eigenen Regeln des Gasts. Gehen Sie nicht davon aus, dass die letzte Änderung, an die Sie sich erinnern, die wirksame ist.

Ein Verbraucher-Client kann auch einen Filtertreiber oder einen Kill-Switch installieren, der Datenverkehr unterhalb der Windows-Firewall blockiert. Wenn die Firewallregeln korrekt aussehen und der Port weiterhin scheitert, ist diese Schicht der nächste Verdächtige.

Nutzen Sie den Gast-Agent als Weg zurück

Zwei Funktionen zur Fernausführung, Run Command und die Custom Script Extension, laufen über den Fabric-Agent im Gast. Keine von beiden braucht RDP, der Firewallfehler betrifft sie also nicht. Beide geben die Ausgabe des Skripts zurück, was sie zu einem Diagnose- und zugleich Reparaturkanal macht.

Lesen Sie das aktive Profil und die RDP-Regel, bevor Sie eines von beiden ändern:

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

Eingehende Regeln in diesem Profil wieder zu aktivieren ist eine vorübergehende Maßnahme, kein Ziel. Nutzen Sie sie, um eine Sitzung zu bekommen, und schließen Sie die Lücke dann richtig:

Set-NetFirewallProfile -Name Public -AllowInboundRules True

Dieser Schalter öffnet jede eingehende Regel des Profils, nicht nur RDP. Sobald Sie eine Sitzung haben, ersetzen Sie ihn durch eine eingegrenzte Regel und stellen Sie die Einstellungen wieder her, die Sie tatsächlich wollen. Ist auch der Agent nicht verfügbar, sind eine serielle Konsole oder eine neu aufgebaute Platte der Rückfallweg, und das ist der praktische Grund, den Agent gesund zu halten.

Verengen Sie das Loch, bevor Sie die Sitzung schließen

Die vorübergehende Profiländerung ist eine Tür, die für jede eingehende Regel dieses Profils offen steht. Ersetzen Sie sie durch eine Regel, die auf Ihre Quelladresse und den RDP-Port begrenzt ist, und bestätigen Sie dann, dass das Profil wieder im vorgesehenen Zustand ist. Tun Sie das, solange Sie die Sitzung noch haben, denn der nächste Fehler ist möglicherweise nicht aus der Ferne umkehrbar. Halten Sie während der Änderung einen zweiten Verwaltungsweg wie Bastion oder eine serielle Konsole bereit.

Bestätigen Sie das Ergebnis von Ihrer Workstation mit einem Porttest und von innen im Gast mit der Regelliste:

Test-NetConnection -ComputerName 203.0.113.25 -Port 3389
Get-NetFirewallRule -DisplayName "RDP from admin" | Get-NetFirewallPortFilter

Schalten Sie die Firewallprotokollierung für die Dauer des Tests ein. Eine einzelne Zeile zu einem verworfenen Paket, die 3389 und das aktive Profil nennt, beantwortet die Frage schneller als ein weiterer Neustart.

Hindern Sie den nächsten Installer daran, es wieder zu tun

Wenn dieser Host keinen Grund hat, den Client zu betreiben, deinstallieren Sie ihn. Ein installierter Client ist eine stehende Einladung für das nächste Update, das Profil erneut umzuschreiben, und die nächste Person wird denselben Ausfall vom Portal aus debuggen.

Machen Sie einen Snapshot der Platte, bevor Sie irgendetwas Netzwerkeinstellungen umschreiben lassen, und halten Sie einen zweiten Verwaltungsweg bereit, bevor Sie ihn brauchen.

Notieren Sie, was der Installer geändert hat: Adapter, Routen, Firewallprofile, Filtertreiber und Dienste. Diese Aufzeichnung macht den nächsten Vorfall zu einem bekannten Muster statt zu einer neuen Untersuchung. Wenn die VM einen Tunnel zu genau einem Dienst braucht, setzen Sie den Client auf Ihre Workstation oder bauen Sie eine Standort-zu-Standort-Verbindung, statt ein Laptop-Produkt auf dem Server zu installieren. Verbraucher-Clients zielen auf Laptops, und ein Server, den Sie aus der Ferne verwalten, ist keiner.