Cloud-Sicherheitsgruppe für ein VPN: nur den Listener öffnen, nicht alles

Der VPN-Server läuft, der Client läuft in eine Zeitüberschreitung, und der erste Reflex ist, eine Regel, die alles erlaubt, zur Sicherheitsgruppe hinzuzufügen. Manchmal funktioniert es dann, und das ist das schlechteste Ergebnis, denn jetzt weiß niemand, welche Grenze tatsächlich geschlossen wurde. Vier getrennte Filter liegen zwischen Client und Daemon, und nur einer davon ist die Sicherheitsgruppe.

Erst das Protokoll benennen, dann die Regel

Eine Regel besteht aus Protokoll, Portbereich und Quelle. WireGuard lauscht auf UDP, üblicherweise 51820. OpenVPN ist je nach Konfiguration meist UDP oder TCP 1194. IPsec braucht seinen IKE-Austausch auf UDP 500 und 4500 sowie das ESP-Protokoll selbst, das eine Protokollnummer und kein Port ist. TCP zu raten, weil die anderen Regeln TCP sind, führt genau zu einer Regel, die richtig aussieht und auf nichts passt.

Lesen Sie den Listener aus dem laufenden Dienst, nicht aus einem Tutorial. Ein an eine Adresse gebundener Daemon akzeptiert keinen Verkehr, der an einer anderen ankommt.

Beschränken Sie die Quelle auf den vom Design erlaubten Client-Bereich statt auf das ganze Internet.

Sicherheitsgruppen sind zustandsbehaftet; Subnetz-ACLs sind es nicht

Sicherheitsgruppen sind zustandsbehaftet und erlauben nur: Ein erlaubter eingehender Fluss erhält seine Antworten automatisch, und es gibt keine Ablehnungsregel, über die nachzudenken wäre. Subnetz-ACLs sind zustandslos und werden in beide Richtungen ausgewertet, daher scheitert eine eingehende Erlaubnis ohne den passenden ausgehenden ephemeren Bereich weiterhin. Dieser Unterschied erklärt viele Regeln, die in der Konsole korrekt aussehen.

Prüfen Sie außerdem, welche Richtlinie am laufenden Endpunkt hängt, denn eine Instanz kann mehr als eine Gruppe haben, und eine Regel in einer nicht angehängten Gruppe ändert nichts.

Die wirksame Richtlinie ist die Vereinigung des Angehängten, nicht die Datei, die Sie bearbeitet haben.

Die Host-Firewall ist eine eigene Grenze

Die Cloud-Richtlinie lässt Verkehr zur Netzwerkschnittstelle zu, und dann entscheidet das Betriebssystem, ob der Daemon ihn sieht. Eine Host-Firewall mit Standard-Ablehnungsrichtlinie verwirft ein Paket, das die Sicherheitsgruppe erlaubt hat, und die Cloud-Konsole zeigt keine Ablehnung, weil sie nie eine Meinung hatte. Prüfen Sie beides, in der Reihenfolge, in der das Paket ihnen begegnet.

Nutzt der Host ein Firewall-Frontend der Distribution, prüfen Sie die zugrunde liegenden Regeln statt den Profilnamen, denn ein Profil kann aktiv sein, während der Port geschlossen ist.

Ein Mitschnitt auf der Schnittstelle sagt Ihnen, welche Grenze das Paket verworfen hat.

Den Listener zuzulassen heißt nicht, die Clients zu routen

Ein VPN-Gateway, das Client-Verkehr weiterleitet, braucht mehr als einen offenen Port. Es braucht IP-Weiterleitung, eine Richtlinie, die den Fluss von der Tunnel-Schnittstelle zum Zielnetz erlaubt, und oft eine deaktivierte Quell-Ziel-Prüfung auf der Schnittstelle, damit die Plattform keinen Verkehr verwirft, der nicht an sie adressiert ist. Nichts davon entsteht durch die Listener-Regel.

Hier trennen sich ein funktionierender Handshake und ein defekter Datenpfad, und deshalb kann ein Tunnelstatus gesund aussehen, während nichts lädt.

Beheben Sie das Routing als separate Änderung mit eigener Prüfung, und beachten Sie, dass ein weiterleitendes Gateway auch eine Ausgangsrichtlinie braucht, die das Ziel erlaubt.

Halten Sie einen Rückweg offen und verengen Sie dann die Regel

Bevor Sie die entfernte Firewall-Richtlinie ändern, prüfen Sie, ob ein unabhängiger Verwaltungsweg existiert, etwa ein Session-Manager, eine serielle Konsole oder ein Out-of-Band-Netz. Läuft der einzige Verwaltungsweg über die Regel, die Sie bearbeiten, haben Sie keine Wiederherstellung. Wenden Sie dann die enge Regel an, testen Sie von einem echten Client und gleichen Sie den Versuch mit serverseitigen Belegen ab. Eine Antwort eines anderen Dienstes auf derselben Maschine ist kein Beweis, dass der Listener erreicht wurde.

Entfernen Sie jede experimentelle breite Freigabe, sobald die enge funktioniert, und notieren Sie, warum die Regel existiert. AWS dokumentiert das zustandsbehaftete Verhalten von Sicherheitsgruppen, und dieses Dokument ist zu zitieren, wenn jemand einen breiten Bereich als Abkürzung vorschlägt.

Dokumentieren Sie auch die Zuordnung, sonst verliert eine Ersatzschnittstelle die Richtlinie stillschweigend.