Zwei aktive IPsec-Tunnel brauchen trotzdem einen Rückwegplan

Öffnen Sie ein Terminal auf einer Workstation am einen Standort und verbinden Sie sich mit einem Server am anderen. Diese eine TCP-Unterhaltung muss jetzt vier Gateways statt zwei überqueren, und das Interessante ist nicht, ob es an einem guten Tag funktioniert. Das Interessante ist, welches Gateway-Paar die Hinrichtung gewählt hat, welches Paar die Antwort wählt und wer währenddessen den Zustand für den Fluss hält. Nichts in der Routing-Tabelle entscheidet das für Sie.

Zeichnen Sie vier Gateways, bevor Sie eine Route zeichnen

Ein dual-aktives Design mit zwei unabhängigen VPN-Firewalls pro Standort, ein Paar pro Provider, gibt Ihnen zwei nutzbare Pfade und drei Arten, sie zu brechen. Schreiben Sie die Adressen auf, bevor Sie irgendetwas konfigurieren: den Client, wie er vor und nach jedem Gateway erscheint, den Server ebenso, den nächsten Hop hin und den nächsten Hop zurück.

Diese Tabelle ist das Design. Alles danach ist die Frage, ob die Geräte mit der Tabelle übereinstimmen.

Wie der Hinweg gewählt wird

Eine Multipath-Routing-Schicht mit gleichen Kosten verteilt Flüsse per Hashing von Header-Feldern auf nächste Hops, was RFC 2992 ausführlich beschreibt. Diese Auswahl kann völlig zustandslos sein: Sie braucht keinen Eintrag zur Verbindungsverfolgung, nur einen stabilen Hash über unveränderte Felder. Halten Sie die Pfadmenge und die Hash-Eingaben konstant, und jedes Paket des Flusses wählt denselben nächsten Hop.

Die Auswahl pro Fluss vermeidet die Umordnung, die Paket-für-Paket-Balancierung über Links mit unterschiedlichen Verzögerungen verursachen würde. Sie verspricht nicht, dass gleiche Routing-Kosten gleiche gemessene Latenz bedeuten, denn das tun sie nicht. Und wenn sich die Pfadzusammensetzung ändert, werden Flüsse neu abgebildet, sodass das Überleben von Verbindungen während eines Ausfalls eine eigene Anforderung gegenüber der Pfadwahl ist.

Was der Rückweg wirklich braucht

Hier hört der Rundgang auf, symmetrisch zu sein. Ein stabiler Hash hinwärts sagt Ihnen nichts darüber, was der ferne Standort mit der Antwort tun wird. Wenn eine unabhängige Firewall beide Richtungen der Verbindung sehen muss, um nützlichen Zustand zu halten, lässt eine Rückroute, die sie umgeht, Verkehr zurück, der auf nichts passt. Zwei Boxen mit ähnlichen Regelsätzen sind kein gemeinsamer Zustand.

Bestätigen Sie das implementierte bidirektionale Verhalten, oder schreiben Sie eine ausdrückliche Policy, die die erforderlichen Grenzen kohärent hält. Eine Vermutung hier wird während eines Ausfalls entdeckt, von Leuten, die das nicht genießen.

Wo Übersetzung für Sie entscheidet

NAT ist der andere Hebel, und er ist optional statt erforderlich. Pfadspezifische übersetzte Identitäten können Antworten zurück zum zustandshaltenden Gateway lenken, was ein legitimes Design ist. Sie fügen aber Mappings, Rückrouten und einen Besitzer dieses Zustands hinzu, also akzeptieren Sie die Last nur für eine Anforderung, die Sie laut benennen können.

Wenn die Anforderung einfach ist, dass beide Pfade Verkehr tragen und einer den Verlust eines Providers übersteht, ist schlichter Multipath pro Fluss mit kohärentem Rückrouting meist das kleinere Design.

Gehen Sie die Abnahme der Reihe nach durch

Testen Sie in dieser Reihenfolge und notieren Sie die Adressen bei jedem Schritt: eine neue Verbindung auf Pfad A und ihr Antwortpfad, dasselbe auf Pfad B, dann Verlust eines Providers, dann Wiederherstellung. Notieren Sie für jedes Ergebnis, welche bestehenden Flüsse sich bewegt haben, welche neu verbinden mussten und wohin neue Flüsse danach gingen. Schreiben Sie den erwarteten Wert zuerst auf und vergleichen Sie ihn dann mit dem Mitschnitt. Zwei bestehende Tunnel beweisen nichts davon.

Das Design ist fertig, wenn die von Ihnen geschriebene Tabelle mit dem übereinstimmt, was der Mitschnitt zeigt, nicht wenn beide Tunnel stehen.