Junos Dual-WAN IPsec VPN: Quellpfad dem richtigen Gateway zuordnen

Zwei WAN-Links pro Standort sehen nach Redundanz aus, bis man beweisen will, welches Adresspaar ein bestimmter Datenfluss wirklich benutzt hat. Auf einer SRX trägt ein IKE-Gateway eine externe Schnittstelle und eine lokale Adresse; eine Liste entfernter Kandidaten erzeugt keine zweite lokale Quelle. Deshalb beginnt dieser Durchgang mit der Paarmatrix statt mit der Konfiguration, weil Junos ohne Zögern ein Design committet, das nur die Hälfte der vorgesehenen Kombinationen abdeckt. Ich bin darauf bei zwei SRX345s gestoßen: Der Backup-Tunnel kam sauber hoch und zog die Sitzung beim Zurückschalten trotzdem herunter.

Arbeiten Sie die Schritte der Reihe nach ab: Zählen Sie die Paare auf, die Sie unterstützen müssen, bauen Sie ein Gateway pro lokaler Quelle, bestätigen Sie, welche Assoziation den Verkehr getragen hat, und entscheiden Sie erst dann, was jede Fehlerart ändern darf.

Die Paare abbilden, bevor Sie die CLI anfassen

Kann Standort A aus A1 oder A2 quellen und Standort B auf B1 oder B2 empfangen, entstehen vier äußere Adresspaare. Die meisten Designs brauchen zwei davon durchgehend und behandeln die beiden anderen als optional. Schreiben Sie die Matrix auf, und markieren Sie jede Zeile, denn jede zugesagte Zeile kostet später ein Gateway, eine Tunnel-Schnittstelle und eine Routing-Entscheidung.

Jedes erforderliche Paar braucht drei Dinge gleichzeitig: ein erreichbares Underlay zwischen genau diesen Adressen, gegenseitige Akzeptanz von Peer-Identität und Quelladresse an beiden Enden und einen geschützten Rückweg. Ein Paar, das nur in eine Richtung funktioniert, zeigt trotzdem einen Tunnel, und der Fehler zeigt sich später als einseitig fließender Anwendungsverkehr.

Ein Gateway pro lokaler Quelle, nicht pro Gegenstelle

Die Liste der entfernten Adressen gehört zu einem Gateway, und die lokale Quelle ebenso. Die IKE-Gateway-Referenz behandelt entfernte Adressen, externe Schnittstelle, lokale Adresse und Dead-Peer-Erkennung als getrennte Einstellungen, und genau darum geht es: zwei lokale Quellen bedeuten zwei Gateways über zwei st0-Einheiten. Die IKE-Policy zwischen ihnen zu teilen ist in Ordnung; ein Gateway zu behalten und zu hoffen, dass es sich selbst neu bezieht, nicht.

set security ike policy IKE-P1 mode main
set security ike gateway GW-A1 ike-policy IKE-P1
set security ike gateway GW-A1 address 198.51.100.20
set security ike gateway GW-A1 address 198.51.100.21
set security ike gateway GW-A1 external-interface ge-0/0/0
set security ike gateway GW-A1 local-address 203.0.113.10
set security ike gateway GW-A1 version v2-only
set security ike gateway GW-A2 ike-policy IKE-P1
set security ike gateway GW-A2 address 198.51.100.20
set security ike gateway GW-A2 external-interface ge-0/0/3
set security ike gateway GW-A2 local-address 192.0.2.10
set security ike gateway GW-A2 version v2-only

Dann hängen Sie die Tunnel an und geben dem fernen Präfix zwei Next Hops, einen pro Tunnel:

set interfaces st0 unit 1 family inet
set interfaces st0 unit 2 family inet
set security ipsec policy IPSEC-P1 perfect-forward-secrecy keys group14
set security ipsec vpn VPN-A1 bind-interface st0.1
set security ipsec vpn VPN-A1 ike gateway GW-A1 ipsec-policy IPSEC-P1
set security ipsec vpn VPN-A2 bind-interface st0.2
set security ipsec vpn VPN-A2 ike gateway GW-A2 ipsec-policy IPSEC-P1
set routing-options static route 10.20.0.0/16 qualified-next-hop st0.1 preference 10
set routing-options static route 10.20.0.0/16 qualified-next-hop st0.2 preference 20

Ob ein Gateway zwei Anweisungen vom Typ address halten darf, hängt von der Version und davon ab, welchen IKE-Prozess die Box ausführt. Ältere kmd-basierte Junos-Versionen nehmen eine einzige entfernte Adresse pro Gateway; neuere Builds verarbeiten mehrere Kandidaten, bringen aber eigene Einschränkungen mit, und Hochverfügbarkeits-Cluster sind ein häufiger Ort, an dem diese Unterstützung enger wird. Prüfen Sie die Release Notes für Ihren genauen Build, bevor Sie dies von einem älteren Chassis kopieren.

Bestätigen, welche Assoziation das Paket getragen hat

Zwei SAs und zwei Tunnel sagen nicht, welcher davon die Sitzung weitergeleitet hat. Fragen Sie die Box direkt und vergleichen Sie die Felder mit dem Paar, das Sie vorgesehen hatten:

show security ike sa detail
show security ipsec sa detail
show security flow session destination-prefix 10.20.1.0/24
show interfaces st0.1 | match packets

Die Detailausgabe nennt für jede Assoziation das lokale und das entfernte Gateway, was der schnellste Weg ist, einen Tunnel zu erkennen, der sich von einer unerwarteten Quelle aus ausgehandelt hat. Beobachten Sie dann die Paketzähler pro Einheit auf st0.1 und st0.2, während Sie Verkehr durchschicken; ein Tunnel, der nichts trägt, behält seine SA und sieht in einer Übersicht gesund aus.

Jeder Fehlerart ihren eigenen Detektor geben

Peer-Liveness, Verlust des lokalen Uplinks, Rücknahme der geschützten Route und Ausfall der Anwendung sind vier verschiedene Ereignisse. DPD beantwortet nur das erste, konfigurieren Sie es also mit einem Intervall und einer Schwelle, die Sie vertreten können, statt die Vorgabe zu lassen und anzunehmen, sie decke den Rest ab:

set security ike gateway GW-A1 dead-peer-detection interval 10
set security ike gateway GW-A1 dead-peer-detection threshold 3
set security ipsec vpn VPN-A1 vpn-monitor source-interface st0.1
set security ipsec vpn VPN-A1 vpn-monitor destination-ip 10.20.0.1

Tunnel-Monitoring, das ein Ziel im fernen Subnetz anpingt, deckt den Fall ab, den DPD nicht sehen kann: IKE lebt, das Gateway antwortet, und das geschützte Präfix ist trotzdem nicht erreichbar. Legen Sie fest, welcher der beiden die Präferenz ziehen soll, denn wenn beide gleichzeitig auslösen, entsteht ein Änderungssturm statt eines sauberen Failovers.

Vergessen Sie die Gegenseite nicht. Eine bevorzugte Route, die am entfernten Standort installiert bleibt, zeigt weiter in einen Tunnel, den Sie längst verlassen haben, und kein lokaler Timer behebt das. Veröffentlichen Sie dieselbe Präferenzlogik auf beiden Peers, und halten Sie fest, ob ein wiederhergestellter Link den Verkehr automatisch zurückholen darf oder von Hand umgeschaltet werden muss.

Einen Link neu adressieren, ohne den anderen anzufassen

Wenn ein ISP Ihnen einen neuen Block vergibt, ändern Sie jeweils nur eine Beziehung. Aktualisieren Sie address oder local-address auf beiden Peers für dieses Paar, committen Sie, und löschen Sie nur die betroffenen Assoziationen nach Index, statt alle SAs auf der Box zu löschen. Ein globales Löschen nimmt auch den gesunden Tunnel mit und macht aus einem Wartungsfenster einen Ausfall.

Halten Sie einen fehlgeschlagenen Datenfluss samt Sitzungsdetail als Beleg fest, bevor Sie aufräumen, und wiederholen Sie dann die Prüfungen oben gegen das neue Adresspaar. Einen Link wiederherzustellen ist eine Routing-Entscheidung, behandeln Sie die Rückkehr also als eigenen getesteten Schritt, statt anzunehmen, die alte Präferenz komme von selbst zurück.

Die Änderung mit einer kurzen Checkliste abschließen

Ein Dual-WAN-Tunneldesign ist fertig, wenn Sie zu jeder Sitzung das Paar nennen können, nicht wenn beide SAs oben sind. Gehen Sie die Liste unten auf der Box durch, die Sie tatsächlich geändert haben:

• Jedes zugesagte Paar hat ein Gateway, eine st0-Einheit und einen Routeneintrag.
• Jeder Tunnel ist schon beim Tragen von Paketen beobachtet worden, nicht nur beim Halten einer SA.
• Beide Enden sind sich über die Erkennung und darüber einig, welche Seite die Präferenz wiederherstellt.
• Der Rückweg für jedes Paar ist neben seinem Hinweg notiert.

Wenn eine Zeile scheitert, reparieren Sie dieses Paar, bevor Sie das nächste hinzufügen; zwei halb funktionierende Tunnel übereinander machen die Zähler bedeutungslos und das Failover-Verhalten unvorhersagbar.