Site-to-Site-VPN: Welche Richtung braucht wirklich eine Regel?

Beide Seiten melden einen aufgebauten Tunnel, die entfernte Filiale antwortet vom Gateway, und die Anwendung läuft für Benutzer auf einer Seite weiterhin in einen Timeout. Der übliche Rat lautet, in beide Richtungen eine Firewallregel hinzuzufügen. Manchmal ist das richtig, manchmal dupliziert es eine bereits vorhandene Regel, und manchmal ist es die zweite Regel, die den Zustand zerstört. Welcher Fall zutrifft, hängt davon ab, wo die Firewall das Paket sieht.

Zustandsbehafteter Rückverkehr ändert die Anzahl

Eine zustandsbehaftete Firewall zeichnet die Anfrage auf und lässt die Antwort ohne zweite Regel zu, ein Design mit nur einer Regel ist also normal. Eine zustandslose Zugriffsliste hat kein solches Gedächtnis, und die Antwort muss ausdrücklich erlaubt werden. Beides ist auf der eigenen Plattform korrekt, deshalb widersprechen sich die Ratschläge.

Lesen Sie die Weiterleitungsdokumentation der Plattform vor sich und prüfen Sie, ob die Richtlinie, die Sie bearbeiten, dort zustandsbehaftet ist, wo sie das Paket sieht. Ein ausdrückliches Verbot für etablierten Verkehr oder eine Regelreihenfolge, die die Antwort vor der Zustandstabelle auswertet, macht aus einem funktionierenden Design ein rätselhaftes. Die Anzahl der Regeln ist ein Implementierungsdetail, die Anforderung ist, dass beide Richtungen eines erlaubten Gesprächs abgeschlossen werden können.

Wo die Firewall entschlüsselte Pakete sieht

In einem richtlinienbasierten Tunnel kann die Firewall das verschlüsselte Paket vor der Entschlüsselung und das entschlüsselte Paket danach auf unterschiedlichen Schnittstellen auswerten. Eine Regel für die falsche Schnittstelle ist vorhanden, korrekt und wird nie getroffen. So kann ein aus einer funktionierenden Umgebung kopierter Regelsatz auf identischer Hardware scheitern.

Routenbasiertes IPsec und die meisten modernen Implementierungen stellen eine Tunnelschnittstelle bereit, sodass das entschlüsselte Paket dort ankommt und normale Schnittstellenregeln gelten. Bestätigen Sie, welches Modell die Umgebung verwendet, bevor Sie einen Regelsatz aus einer Anleitung für das andere kopieren. Die Tunnelschnittstelle ist auch die Stelle, an der man nachsieht, wenn man wissen will, ob ein Paket überhaupt entschlüsselt wurde.

Asymmetrisches Routing bricht die Annahme

Eine zustandsbehaftete Firewall geht davon aus, beide Hälften des Gesprächs zu sehen. Kehrt die Antwort über ein anderes Gateway zurück, hält dieses Gerät keinen Zustand für die Anfrage und verwirft sie nach seiner eigenen Richtlinie. Das Symptom ist ein einseitiger Fehler, den keine Regel auf der Senderseite reparieren kann. Verfolgen Sie den Antwortpfad bevor Sie irgendetwas ändern.

Prüfen Sie die Antwortroute, bevor Sie auf beiden Seiten eine breite Erlaubnisregel hinzufügen. Alles auf jeder Schnittstelle zu tolerieren verbirgt den Routingfehler und erweitert gleichzeitig den Zugriff, was die schlechteste verfügbare Kombination ist.

Prüfen Sie beide Richtungen mit echten Quelladressen

Testen Sie mit der Adresse, die die Gegenseite tatsächlich sieht, denn Übersetzung kann dazu führen, dass eine Quellregel auf nichts passt. Führen Sie die Aufzeichnung auf beiden Gateways gleichzeitig aus.

tcpdump -ni any 'host 10.30.8.15 and tcp port 443'
nft list ruleset | grep -A 8 'chain forward'
ip route get 10.30.8.15
conntrack -L | grep 10.30.8.15

Eine Anfrage, die am entfernten Gateway mit einer unerwarteten Quelladresse auftaucht, erklärt eine Regel, die nie passt, und eine Antwort, die auf der falschen Schnittstelle ankommt, erklärt eine Zustandsabweichung. Testen Sie dann ein Ziel innerhalb des genehmigten Bereichs und eines außerhalb, damit die Grenze gezeigt statt angenommen wird.

Notieren Sie die Quelladresse nach der Übersetzung, die Schnittstelle, die das entschlüsselte Paket verwendet hat, und die passende Regel. Diese drei Fakten beantworten das nächste Ticket, ohne die gesamte Untersuchung zu wiederholen.