Firewall-Profile vs. VPN-Egress: Warum öffentlich kein Pfad ist

Die Regel klingt präzise: lokalen Datenverkehr im privaten Profil erlauben und im öffentlichen nur VPN-Datenverkehr. Das ist sie nicht, denn ein Netzwerkprofil legt fest, welcher Firewall-Regelsatz gilt, und sagt nichts darüber, über welchen Adapter ein Paket übertragen wurde. Den Profilnamen als Pfadanforderung zu behandeln, ist der Fehler, durch den ein Design mit eingeschränktem Egress fertig aussieht, obwohl es das nicht ist.

Halten Sie zuerst die Datenflüsse schriftlich fest und entscheiden Sie dann, welcher Mechanismus jeden einzelnen tatsächlich durchsetzen kann. Diese Liste der Datenflüsse ist das einzige Artefakt, das die nächste Regeländerung übersteht.

Die Kategorie wählt Regeln, nicht Routen

Wenn Windows ein Netzwerk als öffentlich oder privat einstuft, wendet die Firewall den für dieses Profil konfigurierten Regelsatz an. Die Einstufung folgt dem Netzwerk, dem sich der Adapter angeschlossen hat, und der Regelsatz entscheidet, was dort zulässig ist. Keine dieser Tatsachen hängt davon ab, ob der Datenverkehr einer Anwendung den Tunnel genutzt hat. Genau diese Unabhängigkeit ist die Schwierigkeit.

Die Pfadwahl trifft das Routing, über die Schnittstellenmetrik und das Präfix, das der Tunnel installiert. Ein Profil kann daher als öffentlich gekennzeichnet sein, während die Verbindung einer Anwendung den physischen Pfad nimmt, und die Firewall meldet trotzdem, dass der öffentliche Regelsatz angewendet wurde.

Deshalb kann eine auf das Profil beschränkte Regel nicht nur den Tunnel meinen. Die beiden Eigenschaften werden von verschiedenen Komponenten entschieden, und die eine kann die andere nicht ersetzen.

Ein expliziter Block schlägt eine engere Freigabe

Die Firewall-Regelrichtlinie von Microsoft unterscheidet eine Freigabe als Ausnahme von einer standardmäßigen Blockaktion von einem expliziten Block, der mit einer Freigabe kollidiert. Explizite Blöcke gewinnen diesen Konflikt, und ausgehende Regeln folgen derselben Rangfolge.

Das beliebte Rezept, eine Alles-blockieren-Regel hinzuzufügen und sich auf eine darüber platzierte engere Freigabe zu verlassen, bewirkt also nicht, was sein Autor erwartet. Die Windows-Firewall löst den Konflikt nicht über die vom Administrator vergebene Regelreihenfolge. Der Block greift einfach, und die verbindende Anwendung meldet eine Zeitüberschreitung. Die Regel, die wie die Ausnahme aussah, war nie im Spiel.

Die unterstützte Form ist eine Standard-Deny-Richtlinie mit genehmigten Freigaberegeln, bei der jede Freigabe ein Programm, einen Dienst oder ein Ziel präzise genug benennt, um geprüft werden zu können. Dieses Design übersteht ein Audit, weil jede Ausnahme sichtbar ist und keine von ihnen von der Reihenfolge ihrer Erstellung abhängt.

Zwei Regeln, die einander widersprechen, sind schlimmer als eine Regel, weil das resultierende Verhalten zugleich korrekt und unerklärlich ist.

Geben Sie der ausgehenden Richtlinie einen einzigen Verantwortlichen

Ein unterstützter VPN-Client pflegt bereits sein eigenes Blockierverhalten und seine eigenen Endpunkt-Ausnahmen. Unkoordinierte manuelle Regeln können diesen Client außerhalb des Tunnels zurücklassen, den er für die Einrichtung braucht, oder einen zweiten Pfad offen lassen, den niemand bemerkt hat.

Entscheiden Sie vor dem Schreiben von Regeln, wem die ausgehende Richtlinie gehört: der eigenen Konfiguration des Clients, einer verwalteten Firewall-Richtlinie oder einer dokumentierten lokalen Ausnahmeliste mit einem Verantwortlichen. Danach bringen Sie die Schichten in Einklang, statt Experimente zu stapeln, bis irgendetwas eine Verbindung herstellt. Ein benannter Verantwortlicher ist auch derjenige, den man fragt, wenn zwei Schichten nicht übereinstimmen.

Bewahren Sie einen Wiederherstellungskanal, bevor Sie etwas ändern. Ein entfernter Rechner, der von seinem eigenen Verwaltungspfad ausgesperrt ist, ist ein schlimmeres Ergebnis als die Richtlinienlücke, die Sie schließen wollten. Die Wiederherstellungsregel lässt sich leichter rechtfertigen, wenn sie vorab niedergeschrieben ist, und leichter finden, wenn eine Änderung zu einer Stunde schiefgeht, die niemand mag.

Testen Sie vier Ergebnisse statt das Etikett zu lesen

Eine Richtlinie ist nur so gut wie die Fälle, die sie unterscheidet; betrachten Sie das Profil-Etikett daher als Ausgangspunkt und nicht als Ergebnis. Vier Ergebnisse zeigen Ihnen, ob sie funktioniert: Die beabsichtigte LAN-Anfrage gelingt, eine abgedeckte Internet-Anfrage gelingt, eine verbotene direkte Anfrage scheitert, und der Tunnelausfall verhält sich wie geplant, statt still zurückzufallen. Schreiben Sie die vier Ergebnisse neben die Regeländerung. Ein Testplan mit vier benannten Fällen ist kurz genug, um jedes Mal zu laufen, und konkret genug, um laut zu scheitern.

Get-NetConnectionProfile | Select-Object Name,NetworkCategory,InterfaceAlias
Get-NetFirewallProfile | Select-Object Name,DefaultOutboundAction
Get-NetFirewallRule -Direction Outbound -Enabled True | Where-Object Action -eq Block |
  Select-Object DisplayName,Profile

Der erste Befehl zeigt, wie jedes verbundene Netzwerk eingestuft ist, was oft nicht dem entspricht, was die Person, die die Regel geschrieben hat, angenommen hat. Der zweite zeigt die Standardaktion pro Profil, und der dritte listet aktivierte ausgehende Blöcke auf, einschließlich solcher, die eine engere Freigabe still außer Kraft setzen.

Führen Sie die vier Fälle nach einer Netzwerkänderung erneut aus, denn ein Profil kann neu eingestuft werden, wenn der Rechner einem anderen Netzwerk beitritt. Ein passendes Profil-Etikett ist kein Beweis dafür, dass der Pfad der beabsichtigte war.