VPN-Client-Traffic und Firewall-Zustand: äußerer und innerer Fluss

Der VPN-Handshake ist abgeschlossen, der Client erhält eine Adresse, und ein Dienst hinter dem Gateway lehnt die Verbindung weiterhin ab. Die Firewall tut oft genau das, was ihr gesagt wurde. Sie hat den äußeren Tunnel-Fluss erlaubt, der ein anderes Paket ist als die entkapselte Anwendungsverbindung. Daraus folgen zwei Entscheidungen: welchen Fluss Sie erlauben und ob die Grenze überhaupt Zustand verfolgt.

Solange Sie beides nicht trennen, ist jede Regeländerung eine Vermutung.

Die Firewall sieht zwei verschiedene Pakete

Vor der Entkapselung sieht die Firewall Datenverkehr, der an den VPN-Endpunkt adressiert ist: einen äußeren UDP-Fluss zum Listener. Nach der Entkapselung trägt ein weitergeleitetes Paket die innere Adresse des Clients und das Ziel des Dienstes.

Eine Erlaubnis für den äußeren Fluss berechtigt nicht die weitergeleitete TCP-Verbindung. Beide können in verschiedenen Ketten, an verschiedenen Schnittstellen und mit verschiedenen Adressen nach der Übersetzung bewertet werden.

Vergleichen Sie Mitschnitte von gleichwertigen Positionen auf beiden Seiten. Ein Mitschnitt am Tunnelrand und ein Mitschnitt am Server zeigen unterschiedliche Tupel für dieselbe Sitzung.

Erste Entscheidung: den Tunnel oder den Dienst erlauben

Wenn der Client nur den VPN-Endpunkt selbst braucht, kann die äußere Erlaubnis ausreichen. Wenn er einen Dienst jenseits des Gateways braucht, brauchen Sie eine Weiterleitungserlaubnis für dieses Ziel und diesen Port. Eine Tunnelregel, die auch den Dienst erlaubt, ist eine Designentscheidung, die Sie benennen sollten, kein Versehen.

Halten Sie den Client-Bereich und den Umfang des Dienstes eng. Eine Erlaubnis vom Tunnel-Subnetz ins gesamte LAN ist eine Entscheidung, jedem Host zu vertrauen, keine Abkürzung für eine Anwendung.

Schreiben Sie beide Regeln getrennt auf. Die Tunnelregel und die Dieneregel versagen auf unterschiedliche Weise und werden mit unterschiedlichen Beweisen debuggt. Wenn eine versagt, wissen Sie, welche Schicht zuerst zu prüfen ist.

Zweite Entscheidung: zustandsbehaftet oder zustandslos an jeder Grenze

Eine Regel für etablierte Flüsse kann Antworten für einen erlaubten Austausch zulassen, aber ihr Verhalten hängt vom Produkt ab. Eine Cloud-Sicherheitsgruppe ist normalerweise zustandsbehaftet; eine Subnetz-ACL ist oft zustandslos und braucht in beide Richtungen eine ausdrückliche Behandlung. Gehen Sie nicht davon aus, dass jede Grenze auf dem Weg den Zustand gleich behandelt. Listen Sie jede Grenze auf und markieren Sie sie als zustandsbehaftet oder zustandslos, bevor Sie die Regeln entwerfen.

Wenn sich eine Regel ändert, können bestehende verfolgte Flüsse weiter funktionieren, während neue scheitern, oder umgekehrt. Dieser Unterschied ist ein nützlicher Hinweis, kein Grund, den gesamten Verbindungszustand auf einem produktiven Gateway zu leeren.

Testen Sie mit einer frischen, kontrollierten Anfrage und prüfen Sie die relevanten Zähler. Ein sauberer Test ist besser als ein störender Reset. Notieren Sie den Zählernamen im Änderungsprotokoll, damit der nächste Test dieselben Beweise nutzt.

Prüfen Sie den Rückweg unter derselben Richtlinie

Senden Sie eine neue Anfrage vom Client an den Dienst und prüfen Sie dann die Hin- und Rückwegzähler an jeder Grenze. Bestätigen Sie, dass die Antwort den erwarteten Weg nimmt, besonders wenn eine Übersetzung beteiligt ist.

Halten Sie den vorgesehenen Client-Bereich und den Umfang des Dienstes eng und prüfen Sie den Rückweg unter demselben Regelsatz, der die Anfrage erlaubt hat. Eine Regel, die nur funktioniert, weil ein alter Fluss noch offen ist, ist keine funktionierende Regel.