Cloud-Firewall gegen Host-Firewall für einen VPN-Server

Erlauben Sie den VPN-Port in der Cloud-Richtlinie, und der Handshake kann trotzdem auf der Instanz sterben: Der Gast betreibt einen eigenen Filter und eine eigene Listener-Bindung, und beide können verwerfen, was die Cloud genehmigt hat. Auch das Gegenteil kommt vor, wenn eine Host-Regel den Port erlaubt und eine übergeordnete Richtlinie ihn zuerst verwirft. Zwei Verantwortliche, zwei Regelsätze, ein Paketpfad. Gehen Sie ihn der Reihe nach durch, statt auf der verdächtigsten Schicht zu raten.

Am Rand beginnen und nach innen wandern

Die Reihenfolge ist fest: öffentlicher Endpunkt, Ressourcen-Schnittstelle, angehängte Cloud-Richtlinie, Gastadresse, Prozess-Listener, lokale Eingangsregeln. Jede Stufe lässt das Paket durch oder beendet die Untersuchung, und deshalb kostet der Einstieg beim Gast die meiste Zeit.

Weitergeleiteter Client-Verkehr ist eine eigene Stufe, die erst nach dem Entkapseln des Tunnels geprüft wird. Die Cloud-Schicht sieht nur den äußeren Tunnel, kann also eine Verbindung genehmigen und dennoch nichts mit einer inneren Dienstanfrage zu tun haben. Ein Tunnel, der verbindet, aber keinen internen Host erreicht, deutet meist auf die Weiterleitung hin, nicht auf einen geschlossenen Port.

Lesen Sie die Cloud-Richtlinie, bevor Sie den Gast anfassen

Bestätigen Sie die Eingangsregel für den VPN-Port, ihr Protokoll und den Quellbereich, der zu Ihrem Testclient passt. Prüfen Sie auch die Zugriffsliste des Subnetzes: ein zweiter Filter mit eigenen Regeln und Vorgaben. Beide müssen den Fluss zulassen, bevor ein Paket die Instanz erreicht. Eine Erlaubnis im einen und eine Ablehnung im anderen ist die übliche Form dieses Fehlers.

Verengen Sie den Bereich, bis er etwas bedeutet. Den VPN-Port für das ganze Internet zu öffnen ist leicht zu beweisen und schwer zu verteidigen, während eine auf eine Adresse festgelegte Regel bricht, sobald Ihr Testclient das Netz wechselt. Notieren Sie Regelkennung und Richtlinien-Verantwortlichen, damit die nächste Änderung auf eine Person zurückführbar ist.

Bestätigen Sie den Listener, dann die Eingangskette

Prüfen Sie auf der Instanz, ob der VPN-Prozess an die erwartete Adresse und den erwarteten Port gebunden ist, etwa mit ss -lntp 'sport = :1194'. Ein Daemon, der nur an 127.0.0.1 gebunden ist, nimmt lokale Clients an und nichts durch den Tunnel, was von außen genau wie ein gefilterter Port aussieht.

Lesen Sie dann die lokalen Regeln in der Syntax, mit der Sie sie ändern würden, etwa iptables -S INPUT oder nft list chain inet filter input. Eine Regel, die in eine Datei geschrieben, aber nie geladen wurde, oder ein Standard-Drop ohne passende Erlaubnis verwirft Pakete still. Bei einem weiterleitenden Gateway prüfen Sie auch die Einstellungen für Weiterleitung und Rückweg. Sie entscheiden, was mit Paketen geschieht, die durch die Instanz geroutet und nicht an sie adressiert sind.

Zustandsbehaftet in einer Schicht, zustandslos in der nächsten

Sicherheitsgruppen merken sich die Flüsse, die sie erlaubt haben, und lassen die Antworten wieder herein. Zugriffslisten von Subnetzen und viele Host-Firewalls führen keinen solchen Zustand, daher lässt eine Regel, die nur die ausgehende Richtung abdeckt, die Anfrage durch und verwirft die Antwort. Übernehmen Sie nie eine Annahme über Rückverkehr zwischen Schichten, ohne die Regel der zweiten Schicht gelesen zu haben (second layer's rule).

Zähler klären das schneller als das Lesen jeder Regel im Konto. Ein steigender Zähler bedeutet, dass das Paket ankam und dort verworfen wurde, während einer, der bei null steht, bedeutet, dass es nie so weit kam; iptables -vnL INPUT und nft list ruleset zeigen diese Zahlen, wenn die Regeln mit Zählern geladen wurden.

Testen Sie mit einer frischen Sitzung, nicht mit einer laufenden

Lassen Sie das Quellnetz und das Testprofil unverändert, während Sie Ansichten vergleichen, und öffnen Sie nach jeder Änderung eine neue Verbindung. Die Weboberfläche auf 443 zu erreichen sagt nichts darüber, ob der VPN-Daemon an 1194 gebunden ist, also testen Sie den Port, den Sie brauchen. Eine bestehende Sitzung ist hier der schlechteste Zeuge. Sie läuft weiter, während jede neue Anmeldung abgelehnt wird.

Bevor Sie eine entfernte Richtlinie bearbeiten, sichern Sie sich einen Rückweg, der nicht von dem Pfad abhängt, den Sie ändern. Öffnen Sie dann eine zweite Verwaltungssitzung neben dem VPN-Test: eine früher aufgebaute kann die Regel überleben, die neue blockiert. Halten Sie beide Richtlinien-Verantwortlichen fest, damit kein Neuaufbau den halben Pfad wiederherstellt; wenn beide Schichten übereinstimmen und der Tunnel trotzdem scheitert, erfassen Sie an der Gast-Schnittstelle und prüfen Sie Adresse und Port, die der Client wirklich nutzt.