IPsec über ein privates WAN: SRX-Richtliniengrenzen, die zu prüfen sind

Ein privates WAN kann die äußeren Pakete eines IPsec-Tunnels transportieren, daher müssen die Peer-Adressen keine öffentlichen Internetadressen sein. Geändert hat sich der Pfad, den diese äußeren Pakete nehmen, und die Berechtigungen auf der Schnittstelle, die sie empfängt. Auf einer SRX sind der äußere Steuerungspfad, die Bindung der Tunnelschnittstelle und die Richtlinie für weitergeleiteten Datenverkehr drei getrennte Objekte. Die Fehlersuche an einem, während die anderen beiden falsch sind, ist der übliche Grund, warum ein Tunnel unten bleibt.

Halten Sie zuerst den äußeren IKE-Pfad fest

Notieren Sie vier Werte, bevor Sie die Richtlinie anfassen: die Peer-Adresse, die lokale Schnittstelle, die IKE empfängt, den Routing-Kontext, der den Peer erreicht, und die Route, die diese Schnittstelle auswählt. IKE-Pakete sind an die SRX selbst adressiert, daher benötigen sie eine host-inbound-Berechtigung in der empfangenden Zone, keine Richtlinie für weitergeleiteten Datenverkehr. Eine private WAN-Adresse hebt diese Anforderung nicht auf, denn das Paket endet weiterhin auf dem Gerät.

Prüfen Sie den installierten Zustand mit show security ike sa und die Konfiguration mit show configuration security ike. Ersterer zeigt, ob Phase 1 existiert; letztere zeigt, was das Gerät zu tun glaubt.

Binden Sie die Tunnelschnittstelle an die richtige Richtlinie

Ein routenbasiertes VPN bindet eine Tunnelschnittstelle an ein VPN-Objekt, und geschützte Präfixe werden in diese Schnittstelle geroutet. Notieren Sie, welche Schnittstelle, welche Route und welche Richtlinie die Anwendungen zwischen den betroffenen Zonen zulässt. Eine Zone namens trust ist ein Richtliniencontainer, und der Name beweist nicht, dass die erforderlichen Steuer- oder Datenpakete erlaubt sind.

Lesen Sie die tatsächlichen Bindungen statt eines alten Diagramms: show configuration security ipsec vpn für die Bind-to-Interface-Einstellung und show configuration security policies für die Regeln, die auf die Tunnelzone verweisen.

Wenn die geschützte Route woanders hinzeigt, kann der Tunnel oben sein, während der Datenverkehr nie hineingelangt. Das ist ein Routingproblem im IPsec-Kostüm.

Halten Sie die Peer-Route im Underlay

Die Route zum externen Peer muss über das Underlay aufgelöst werden, nicht rekursiv über den Tunnel, den sie aufbaut. Wenn die Peer-Route auf die Tunnelschnittstelle zeigt, jagen die IKE-Pakete ihrem eigenen Tunnel hinterher, und Phase 1 wird nie abgeschlossen. Der Rückweg für geschützten Datenverkehr braucht seine eigene korrekte Route und Richtlinie, und er ist meist die fehlende Hälfte, wenn eine Richtung funktioniert. Lesen Sie den Routentabelleneintrag für die Peer-Adresse und bestätigen Sie, dass die ausgehende Schnittstelle die WAN-Schnittstelle ist.

Prüfen Sie es mit show route 198.51.100.10, setzen Sie die echte Peer-Adresse ein und bestätigen Sie, dass der nächste Hop keine Tunnelschnittstelle ist.

Prüfen Sie Steuerung und Dienst der Reihe nach

Arbeiten Sie sich nach oben: Phase-1-Zustand, Phase-2-Zustand, dann ein echter Anwendungsfluss. show security ipsec sa listet die Sicherheitsassoziationen auf, und show security flow session destination-prefix 10.60.0.0/16 zeigt, ob weitergeleitete Sitzungen für das geschützte Netzwerk aufgebaut werden.

Eine gesunde Steuerungsbeziehung und ein funktionierender Datenpfad sind zwei verschiedene Ergebnisse, und eine bestandene Phase 2 sagt nichts darüber aus, ob die Richtlinie die Anwendung zulässt. Testen Sie einen erlaubten Fluss und einen, den die Richtlinie ablehnen sollte, damit der Unterschied sichtbar wird.

Notieren Sie die Peer-Route, die host-inbound-Berechtigung, die Tunnelbindung, die innere Route und die Anwendungsrichtlinie zusammen. Diese fünf Aufzeichnungen zeigen, welche Schicht einen künftigen Fehler besitzt, ohne sich auf ein Portetikett zu verlassen.