VPN-zu-VLAN-Zugriff: erst die Matrix, dann die Regeln
Rollen auf der einen Seite, Dienste auf der anderen. Fünf Prüfungen machen aus einem vagen VPN-zu-VLAN-Entwurf eine Tabelle, die ein Firewall-Verantwortlicher umsetzen kann.
Beginnen Sie mit der Matrix, nicht mit der Firewall-Syntax. Eine Tabelle mit Rollen auf der einen und Diensten auf der anderen Seite kann ein Anwendungsverantwortlicher prüfen, ein Sicherheitsverantwortlicher diskutieren und derjenige umsetzen, der das Gateway hält. Diese Prüfung ist billiger als das Debuggen von Regeln, auf die sich niemand geeinigt hat.
Eine Stunde Schreiben spart später eine Woche Regel-Archäologie. Das Design handelt davon, wer welchen Dienst erreicht, und genau das ist der Teil, der eine Neunummerierung überlebt.
Schritt 1: Benennen Sie die Rollen vor den Netzen
Fangen Sie bei den Menschen an, nicht beim Switch. Notieren Sie jede Gruppe, die sich remote verbindet, und den einen Satz, der beschreibt, was diese Gruppe tut, etwa Lagerpersonal, das Bestände liest, oder ein Auftragnehmer, der eine Integration pflegt. Würden zwei Gruppen identischen Zugriff erhalten, sind sie für diesen Zweck eine Rolle.
Halten Sie hier an, wenn eine Rolle nur wegen eines Organigramms existiert. Eine Rolle ohne eigenständigen Dienstbedarf wird zu einer Zeile identischer Zellen, und identische Zeilen verleiten dazu, später bequem ein ganzes Subnetz freizugeben. Teilen Sie nach dem, was Menschen tun, nicht danach, wer ihre Ausgaben unterschreibt. Sechs Rollen sind für ein kleines Büro meist zu viele, und drei sind oft richtig.
Schritt 2: Machen Sie aus jeder Zelle eine Dienstaussage
Eine Zelle mit dem Inhalt „Anwendungen“ ist nicht prüfbar. Eine Zelle mit dem Inhalt „HTTPS zum ERP-Host auf 443, aus dem Mitarbeiter-Pool“ ist es. Ersetzen Sie jeden Netznamen durch ein Ziel, ein Protokoll und einen Port und ergänzen Sie dann die Abhängigkeit, ohne die der Dienst nicht funktioniert, etwa den internen Resolver oder den Identitätsanbieter.
| Check | Passes when | Stop if |
|---|---|---|
| Destination named | Host and port appear in the cell | Cell names a VLAN or a subnet |
| Direction stated | Initiator and responder are both clear | Cell implies two-way access |
| Dependency listed | DNS or identity path is explicit | Whole infrastructure range is granted |
| Negative case written | At least one denied pair is recorded | Only allow rules exist |
Die Richtungsspalte fängt die teuersten Fehler. Die Erlaubnis für Mitarbeiter, eine Anwendung zu öffnen, bedeutet nicht die Erlaubnis für Anwendungsserver, Verbindungen zurück zu Mitarbeiter-Laptops zu öffnen, und eine zustandsbehaftete Regel, die die erste Richtung erlaubt, wird oft als Erlaubnis für die zweite gelesen.
Schritt 3: Entscheiden Sie, wo Identität zu Richtlinie wird
Jemand muss eine authentifizierte Sitzung in eine Rolle umwandeln, die das Gateway durchsetzen kann. Unterstützte Optionen sind Gruppenrichtlinien vom Authentifizierungs-Backend, vertrauenswürdige Sitzungsattribute oder getrennte Adresspools pro Rolle. Alle drei funktionieren; ein vom Client gesendetes Label nicht. Wählen Sie den Mechanismus, den Ihr Gateway dokumentiert, nicht den, den ein Forenbeitrag beschreibt.
Eine Adresse zuzuweisen, die nur so aussieht, als gehöre sie zu einem VLAN, ist dieselbe Nicht-Antwort in anderem Kostüm. Der Netgate-Leitfaden zu OpenVPN-Firewallregeln macht die Trennung deutlich: den Tunnel hochkommen zu lassen ist eine andere Entscheidung, als Verkehr hindurchzulassen.
Notieren Sie, welchen Mechanismus Sie gewählt haben und wo er konfiguriert ist. Wenn sich eine Rolle ändert, ist diese Notiz der Unterschied zwischen einer Änderung und einer Suche durch drei Oberflächen. Sie sagt auch einer Prüferin, wo sie zuerst nachsehen soll.
Schritt 4: Achten Sie auf die Quelladresse, die das Ziel sieht
Die Weiterleitungsrichtlinie muss am Rand zur tatsächlichen Quelle passen. Wenn das Gateway VPN-Clients auf seine eigene Adresse übersetzt, sieht jede nachgelagerte Firewall eine Quelle und verliert die Fähigkeit, Entscheidungen pro Rolle zu treffen. Wenn es die Clientadresse bewahrt, muss der Rückweg für diesen Pool existieren.
Testen Sie beide Richtungen, bevor Sie die endgültigen Regeln schreiben, und notieren Sie dann die beobachtete Quelle neben jeder Zelle. Führen Sie dieselbe Prüfung aus zwei verschiedenen Rollen aus und vergleichen Sie das Ergebnis. Zeigen beide die Gateway-Adresse, ist die Rollenunterscheidung bereits verloren. Eine Matrix, die bewahrte Adressen annimmt, während das Gateway Quellübersetzung betreibt, scheitert an der ersten nachgelagerten ACL.
Schritt 5: Testen Sie jede Zelle, bevor Sie sie ausliefern
Machen Sie aus jeder erlaubten Zelle eine repräsentative Operation und aus jeder verweigerten Zelle einen Negativfall. Führen Sie beides von einem Client in der tatsächlichen Rolle aus, nicht von der Gateway-Konsole, denn die Konsole umgeht den Pfad, den Sie testen.
# allowed: staff role reaches the ERP endpoint
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://erp.internal.example/health
# denied: the same role must not reach a management host
nc -vz -w 3 10.30.5.11 22
# observed source address at the destination
sudo tcpdump -ni any 'tcp port 443 and host 10.30.20.15'Ein Negativfall, der sich verbindet, ist ein Befund, kein Zufall, und er gehört als fehlgeschlagene Zelle in die Matrix, bis die Regel korrigiert ist. Halten Sie die Testbefehle neben der Tabelle, damit die nächste Prüferin sie erneut ausführt, statt die Argumentation neu aufzubauen.
Die fertige Tabelle überlebt das Gateway, für das sie geschrieben wurde. Regeln ändern sich mit Firmware und Hersteller, doch die Zeile, die besagt, dass ein Auftragnehmer einen Projektdienst erreicht, bleibt wahr, bis sich diese Arbeit ändert.