Eine RDP-Zulassungsregel hinzuzufügen verengt den VPN-Zugriff nicht

Der Plan klingt vernünftig: Lassen Sie die bestehende Freigabe für Remotedesktop unangetastet und fügen Sie eine kleine für den einen VPN-Client hinzu, der Zugriff haben soll. Windows Firewall funktioniert nicht so. Regeln sind keine geordnete Liste, in der der spezifischste Eintrag gewinnt, und eine enge Freigabe neben einer breiten ändert nichts, weil die breite weiterhin jeden durchlässt, den sie schon durchgelassen hat. Den Dienst einzugrenzen bedeutet, die Freigabe zu bearbeiten, die bereits die Arbeit leistet.

Die Regel, die Sie hinzufügen, ist nicht die Regel, auf die es ankommt

Windows Firewall wertet alle anwendbaren eingehenden Regeln über die Richtlinienspeicher aus, die für den Computer gelten, und entscheidet dann, ob eine Freigabe passt und ob eine Blockierung sie übersteuert. Eine Regel hinzuzufügen fügt eine Freigabe hinzu; sie entfernt oder präzisiert nicht die Freigaben, die bereits vorhanden sind.

Die Frage ist also nie, was Sie hinzugefügt haben. Sie ist, was die effektive Richtlinie enthält nachdem lokale Richtlinie, Domänenrichtlinie und die Profilstandards zusammengeführt wurden. Eine Workstation mit einer lokalen Regel lässt sich leicht durchdenken; ein in eine Domäne eingebundener Server nicht.

Deshalb kann ein Administrator eine korrekt aussehende Änderung vornehmen, sie vom falschen Rechner aus testen und zu dem Schluss kommen, dass sie funktioniert hat. Die ausgeschlossene Quelle wurde nie getestet. Ein Test, der nur Erfolg beweist, beweist weniger als die Hälfte dessen, wofür die Änderung gedacht war.

Finden Sie heraus, welche Adresse der Server sieht

Beobachten Sie, bevor Sie irgendetwas eingrenzen, eine erlaubte Sitzung am Windows-Host und notieren Sie die Quelladresse, die der Server meldet. Das ist nicht immer die Adresse, von der der Client glaubt, sie zu haben.

Wenn das VPN-Gateway Clientadressen bewahrt, sieht der Server die Tunneladresse des Clients, und eine adressbezogene Regel ist sinnvoll. Wenn das Gateway übersetzt, kommt jeder Client als Adresse des Gateways an, und die Eingrenzung auf diese Adresse gewährt jedem Client dahinter Zugriff. Dann ist die Regel präzise in der falschen Sache.

Diese beiden Entwürfe brauchen unterschiedliche Antworten. Der erste lässt sich in einer Firewallregel ausdrücken; der zweite muss dort durchgesetzt werden, wo Identität noch existiert, also im VPN selbst oder in einem authentifizierten Gateway vor dem Dienst.

Ein Firewallfilter kann eine Identität nicht zurückgewinnen, die die Netzwerkübersetzung verworfen hat, so sorgfältig die Adresse auch eingetippt wird.

Ändern Sie den Eigentümer der effektiven Regel

Prüfen Sie die effektive eingehende Richtlinie und finden Sie jede Regel, die RDP-Verkehr derzeit zulässt, einschließlich Regeln, deren Anzeigename nie Port 3389 erwähnt. Dienstbezogene und anwendungsbezogene Regeln zählen ebenfalls, und auch der UDP-Transport, den einige RDP-Bereitstellungen aktivieren.

Bearbeiten Sie dann die bestehenden Regeln über den Speicher, dem sie gehören. Eine lokale Änderung an einer Regel, die auch die Domänenrichtlinie definiert, kann zusammengeführt, ignoriert oder überschrieben werden, und es lohnt sich zu wissen, welcher Fall eintritt, bevor Sie sich darauf verlassen.

Diese Befehle finden die aktiven Regeln, zeigen den Adressfilter an, der an eine davon angehängt ist, und zeigen eine Bereichsänderung in der Vorschau:

Get-NetFirewallRule -PolicyStore ActiveStore -Direction Inbound | Where-Object DisplayName -match RDP
Get-NetFirewallAddressFilter -AssociatedNetFirewallRule (Get-NetFirewallRule -Name Reviewed-RDP-TCP)
Set-NetFirewallRule -Name Reviewed-RDP-TCP -RemoteAddress 10.63.4.17 -WhatIf

Die Regelnnamen hier sind Platzhalter für das, was die Prüfung gefunden hat, und das Vorschauflag existiert, damit ein Tippfehler in einer Adresse Sie nicht vom Server aussperrt, den Sie bearbeiten.

Erst blockieren, dann erlauben ist ein anderes Modell

Die Gewohnheit aus anderen Firewalls ist, eine breite Blockierung zu schreiben und darüber eine enge Freigabe. Unter Windows gewinnt eine ausdrückliche Blockierung im Allgemeinen gegen eine Freigabe, sodass diese Reihenfolge einen Dienst erzeugt, den niemand erreichen kann, statt einer Ausnahme für einen Client. Das Ergebnis ist ein Ausfall, der wie ein defekter RDP-Dienst aussieht. Es ist in Wahrheit ein Prioritätsfehler, und die Lösung ist, die Blockierung zu entfernen, statt eine weitere Freigabe hinzuzufügen.

Behalten Sie das standardmäßige Blockieren eingehender Verbindungen auf den aktiven Profilen bei und grenzen Sie stattdessen die konkreten Freigaben ein. Das hinterlässt den Rechner mit einer verständlichen Haltung statt mit zwei widersprüchlichen Regeln, deren Zusammenspiel von Prioritätsdetails abhängt.

Beweisen Sie es mit einer zweiten Quelle

Testen Sie vom erlaubten Client und von einer Quelle, die jetzt scheitern sollte. Eine einzige erfolgreiche Verbindung beweist nur, dass der erlaubte Weg funktioniert; sie sagt nichts über den Ausschluss aus, den Sie gerade vorgenommen haben.

Wiederholen Sie den Test über IPv6, wenn der Server es aktiviert hat, denn eine reine IPv4-Absicht kann neben einer breiten IPv6-Freigabe bestehen, die niemand angesehen hat.

Schließlich halten Sie Authentifizierung und Erreichbarkeit getrennt. Netzwerkauthentifizierung, Kontorechte und Anmeldebeschränkungen entscheiden weiterhin, wer die Sitzung nutzen darf, und die Firewall entscheidet nur, wer fragen darf. Das spätere Entfernen eines Geräts sollte sowohl seine VPN-Registrierung als auch diese Netzwerkberechtigung entfernen, sonst gehört die eingegrenzte Adresse irgendwann jemand anderem.