Warum ein Firewall-Gate auf VPN-Zustand keine Ping-Regel nur durch den Tunnel ist

Stellen Sie sich eine Firewall-Regel vor, die ICMP-Echo für die öffentliche Adresse des Servers einschaltet, sobald ein benanntes VPN-Profil verbunden ist. Das liest sich wie „Ping nur durch den Tunnel“, und diese Lesart ist auf eine Weise falsch, die zählt. Die Regel schränkt nicht ein, wer den Host erreichen darf; sie ändert, was die öffentliche Schnittstelle antwortet, während zufällig eine andere Verbindung steht. Das sind zwei verschiedene Politiken, und eine davon erweitert die Exposition still.

Die Regel, die Sie zu schreiben glauben

Die beabsichtigte Anforderung ist meist eng: Das Monitoring-System oder der eine Administrator im VPN soll bestätigen können, dass der Server lebt. Als Satz geschrieben klingt es nach Zugriffskontrolle auf den Tunnel. Als Firewall-Objekt geschrieben wird daraus eine Bedingung am öffentlichen Profil, denn dort kommt die Echo-Anfrage an.

Sobald die Bedingung ein Verbindungszustand statt einer Quelladresse ist, ist die Menge erlaubter Absender nicht mehr die VPN-Peer-Menge. Jeder, der die öffentliche Adresse erreicht, kann eine Echo-Anfrage senden, solange das Gate offen ist. Der Tunnel wurde nicht der Pfad; der Tunnel wurde der Schalter.

Die Leute, die diese Idee bewerben, lügen meist nicht über den gewünschten Effekt. Sie brauchten eine Prüfung, die nur antwortet, wenn die Strecke gesund ist, und die Gesundheit der Strecke war am einfachsten über das VPN zu beobachten. Der Fehler ist, ein Verfügbarkeitssignal als Zugriffsentscheidung zu behandeln und das dann zu automatisieren.

Was das Gate tatsächlich steuert

Dieses Design verschmilzt zwei unabhängige Dinge, und ihre Trennung ist der größte Teil der Korrektur. Das erste ist der Umfang: welche lokale Adresse, welche entfernten Adressen, welches Protokoll und welcher ICMP-Typ. Das zweite ist die Bedingung: ob das Regelobjekt in diesem Moment aktiviert ist. Umfang ist das, was eine Firewall pro Paket bewertet; Bedingung ist das, was ein Skript in den Richtlinienspeicher schreibt, und beides wird auf völlig verschiedenen Uhren abgeglichen.

Wenn die Anforderung wirklich nur VPN-Peers sind, beantwortet der Umfang sie ohne jede Verbindungszustandslogik: binden Sie die Regel an die Tunnelschnittstelle oder an den Tunneladressbereich, beschränken Sie die entfernten Adressen auf den Client-Pool und geben Sie den Echo-Typ statt „ICMP“ an. Diese Regel bleibt richtig, wenn kein VPN läuft, und kann von einem fremden Profil nicht geöffnet werden.

Wenn die Anforderung wirklich ein öffentliches Gate ist, dann sagen Sie das im Richtlinientext, weil sich die Abnahmekriterien ändern. Ein öffentliches Gate muss das genaue Profil nennen, definieren, was verbunden bedeutet, und festhalten, dass öffentliche Absender konstruktionsbedingt im Umfang liegen. Der meiste Wirrwarr verschwindet in dem Moment, in dem jemand gezwungen wird, diesen Satz aufzuschreiben.

Bauen Sie das Objekt einmal, dann schalten Sie es

Legen Sie vorab eine einzige Regel mit stabiler Identität an, deaktiviert, und lassen Sie den Controller nur ihren Aktivierungszustand ändern. Regeln bei jedem Lauf nach dem Anzeigenamen zu erstellen, ist der Weg, auf dem ein Richtlinienspeicher mit fünf nahezu identischen Objekten und ohne verlässliche Möglichkeit endet, sie zu entfernen.

New-NetFirewallRule -Name "VpnGateEchoV4" -DisplayName "Public echo gated on VPN state" -Direction Inbound -Action Allow -Protocol ICMPv4 -IcmpType 8 -LocalAddress 203.0.113.10 -RemoteAddress Any -Enabled False
Set-NetFirewallRule -Name "VpnGateEchoV4" -Enabled True

Der Name ist die dauerhafte Kennung; der Anzeigename ist Dokumentation, die ein Mensch bearbeiten darf. Gleichen Sie gegen -Name ab, und das Skript erzeugt keine Duplikate mehr. Dieselbe Befehlsform deckt den IPv6-Fall mit -Protocol ICMPv6 -IcmpType 128 ab, was eine eigene Regel ist, weil sich die Echo-Typnummern zwischen den beiden Familien unterscheiden.

Halten Sie Adressfamilie und ICMP-Typ aus einem zweiten Grund explizit: -Protocol ICMPv4 ohne Typ erlaubt jede ICMPv4-Nachricht, die das Profil zulässt, einschließlich derer, die Sie nie annehmen wollten. Typ 8 zu nennen, verengt die Regel auf Echo-Anfrage, und nur das sendet eine Erreichbarkeitsprüfung.

Wo die Automatisierung der Absicht widerspricht

Ein Client-Profil alle paar Minuten abzufragen, kann keine sofortige Grenze erzeugen. Zwischen dem Abfallen der Verbindung und der nächsten Abfrage antwortet die Regel weiter auf der öffentlichen Adresse; zwischen dem Hochkommen der Verbindung und der nächsten Abfrage nicht. Diese Verzögerung zuzugeben ist ehrlich, zu behaupten, das Design erzwinge eine strikte Invariante, nicht.

In der Zustandsprüfung selbst steckt eine Umfangsfalle. Get-VpnConnection meldet auf dem Rechner konfigurierte Client-Profile, standardmäßig für den aktuellen Benutzer und für alle Benutzer mit -AllUserConnection. Es meldet nicht die entfernten Benutzer, die gerade bei einem RRAS-Server eingewählt sind; das ist eine andere Beobachtung mit einem anderen Cmdlet. Ein Gate, das auf dem falschen gebaut ist, ist mit nichts verbunden.

Decken Sie dann die Zustände ab, die niemand skriptet: Start mit bereits aktivierter Regel aus einem früheren Lauf, Controller-Absturz bei offenem Gate und ein gelöschtes Profil, während seine Regel aktiv bleibt. Jeder braucht einen definierten Standard, und der sichere Standard für eine öffentliche Freigabe ist deaktiviert. Wenn die Anforderung das Abfragefenster wirklich nicht verträgt, ist eine zustandsgesteuerte Regel das falsche Werkzeug, und die Durchsetzung gehört an den Tunnel, nicht an die öffentliche Schnittstelle.

Testen Sie zuletzt die öffentliche Anfrage zweimal, einmal mit aufgebauter ausgewählter Verbindung und einmal mit abgebauter, von einem Host, der nicht im VPN ist. Ein erfolgreicher Ping aus dem Tunnel heraus beweist nichts über diese Politik, und genau diese Messung lassen die meisten Bereitstellungen aus.