VPN über mehrere Pfade: vier Garantien, die der Carrier liefern muss

Fügen Sie einen zweiten WAN-Link hinzu, und die Tunnel kommen hoch – doch eine Dateikopie stockt weiterhin, wenn ein Pfad wackelt. Die Links sind gesund, die VPN-Prozesse laufen; was fehlt, ist ein Vertrag zwischen dem Carrier und dem Tunnel. Mehrere Sockets verhalten sich nicht automatisch wie eine Verbindung, und die Anwendung darüber erkennt den Unterschied erst, wenn die Zustellung bricht. Jeder Teil des Vertrags entspricht einem Fehler, den Sie testen können – das macht ihn nützlich.

Schreiben Sie diesen Vertrag, bevor Sie ein Produkt wählen. Er hat vier Teile: den Strom, den das VPN empfängt, die Art, wie der Carrier verlorene Daten wiederherstellt, welche Endpunktidentität einen Pfadwechsel übersteht und wie sich das Ganze verhält, wenn ein Pfad ausfällt.

Das Symptom: Die Links stehen, die Sitzung bricht trotzdem

Ein Überwachungsdiagramm, das beide Links als aktiv zeigt, beweist nur, dass jeder Pfad Verkehr tragen kann. Es beweist nicht, dass das VPN einen geordneten Strom sieht, dass ein auf einem Pfad verlorenes Paket auf einem anderen wiederhergestellt wird oder dass der Peer noch weiß, mit welcher Sitzung er spricht. Der Rest des Vertrags deckt ab, was das Diagramm nicht zeigen kann.

Wenn eine Übertragung stockt, prüfen Sie, ob der Carrier auf dem überlebenden Pfad weiter geliefert hat. Stirbt die Sitzung, während der zweite Link untätig ist, hat der Carrier ihn nie genutzt. Überlebt die Sitzung, kommen die Daten aber außer der Reihenfolge oder doppelt an, bewegt der Carrier Pakete ohne Vertrag auf Verbindungsebene. Zeitstempel auf beiden Seiten machen das meist klar.

Diese Unterscheidung entscheidet über die Lösung. Ein Routing- oder Richtlinienproblem erfordert eine andere Pfadwahl; eine fehlende Schicht für Reihenfolge und Wiederherstellung erfordert einen anderen Transport, nicht einen größeren Puffer.

Garantie eins: ein Bytestrom auf Verbindungsebene

Braucht das VPN einen zuverlässigen, geordneten Strom, muss der Carrier Bytebereiche oberhalb des einzelnen Pfads identifizieren. Jede zugrunde liegende TCP-Verbindung nummeriert nur ihre eigenen Segmente, sodass ein Empfänger allein mit diesen Nummern nicht über Pfade hinweg umsortieren kann.

Multipath TCP ist das standardisierte Beispiel. Es bietet einen zuverlässigen Bytestrom und koordiniert mehrere TCP-Subflows mit Sequenzabbildung und Bestätigung auf Datenebene. Die Anwendung liest einen Strom, nicht den Subflow, der zufällig zuerst ein Stück geliefert hat.

Unter Linux ist MPTCP pro Socket über IPPROTO_MPTCP opt-in. Kann die Aushandlung kein Multipath-Verhalten nutzen, ist der dokumentierte Rückfall gewöhnliches TCP – die Anwendung arbeitet dann möglicherweise über einen Pfad weiter, ohne den zweiten je zu nutzen. Prüfen Sie, welches Verhalten der eingesetzte Socket tatsächlich ausgehandelt hat, statt anzunehmen, die Kernel-Einstellung greife.

Garantie zwei: Reihenfolge, Duplizierung und Wiederherstellung

Pfade mit unterschiedlichen Verzögerungen und Verlustraten zwingen den Carrier zu puffern, umzusortieren und erneut zu senden. Der Vertrag muss festhalten, wie viel Puffer erlaubt ist, welchen Gegendruck die Anwendung sieht und welcher Pfad eine Neusendung trägt.

Ein Pfad, der verbunden bleibt, aber nichts mehr liefert, ist schwieriger als ein sauberes Schließen. Der Carrier muss ihn erkennen, ausstehende Daten verschieben und vermeiden, ewig auf ein Segment zu warten, das nie ankommt. Eine einfache Prüfung „beide Links sind aktiv“ deckt diesen Zustand nicht ab.

Duplizierung braucht eine eigene Regel. Dieselbe Nutzlast auf beiden Pfaden zu senden kann die Latenz verbessern, aber der Empfänger muss die Kopie unterdrücken, bevor sie das VPN erreicht. IPsec-Anti-Replay ist pro Sicherheitsassoziation optional und prüft Sequenznummern; eine Duplizierungsschicht, die Pakete umsortiert oder wiederholt, kann sie auslösen oder das Problem verbergen, bis der Tunnel abbricht.

Garantie drei: Endpunktidentität und Pfadbeitritt

Der Peer braucht eine stabile Möglichkeit, die Sitzung zu erkennen, wenn ein neuer Pfad erscheint. Wird jeder Pfad als eigener Tunnel authentifiziert, sieht das VPN womöglich zwei Sitzungen statt einer. Führt der Carrier Pfade unter einer Sitzung zusammen, muss er festlegen, wie der neue Pfad authentifiziert wird und was mit dem alten geschieht.

Halten Sie fest, welche Adressen und Kennungen stabil bleiben: der Tunnelendpunkt, die Sitzungskennung des Carriers und ein eventueller Proxy dazwischen. Ein Proxy fügt eine weitere Verfügbarkeits- und Vertrauensgrenze hinzu, selbst wenn er die geschützte Nutzlast nie sieht.

Hier liegt auch die Richtlinie. Ein Pfad, der aus einem unerwarteten Netz beitritt, kann technisch gültig sein und trotzdem das vorgesehene Vertrauensmodell verletzen. Entscheiden Sie, ob neue Pfade automatisch akzeptiert werden, eine Authentifizierung verlangen oder abgelehnt werden.

Garantie vier: begrenztes Verhalten bei Ausfall

Testen Sie einen vollständigen Pfadausfall, nicht nur einen langsamen Pfad. Der überlebende Pfad sollte die Sitzung ohne unbegrenztes Speicherwachstum tragen, und die Wiederherstellung sollte nicht von einem Timer abhängen, der länger ist, als die Anwendung toleriert. Kehrt der ausgefallene Pfad zurück, muss der Carrier entscheiden, ob er neu verteilt oder den Fluss lässt, wo er ist.

Setzen Sie Grenzen für Pufferung, Neusendung und Pfadanzahl und prüfen Sie sie unter Verlust, Umsortierung, Duplizierung und Verzögerungsungleichgewicht. Die Gesamtbandbreite ist hier die uninteressanteste Zahl; Zustellkontinuität und Speichergrenzen sind der Vertrag.

Halten Sie den Wiederherstellungszustand des Carriers vom kryptografischen Zustand des VPN getrennt. Eine eigene Zuverlässigkeitsschicht, die etablierte Authentifizierung oder Verschlüsselung ersetzt, ist keine Abkürzung, und die Wiederverwendung von Sequenznummern über Schichten hinweg macht Replay-Schutz und Diagnose unzuverlässig.

Den Carrier mit einem Testplan abnehmen

Schreiben Sie die vier Garantien als Bestanden-oder-nicht-bestanden-Prüfungen: ein geordneter Strom, definierte Wiederherstellung, stabile Sitzungsidentität, begrenztes Ausfallverhalten. Führen Sie jede Prüfung mit einem beeinträchtigten und dann mit einem entfernten Pfad aus.

Eine einzige erfolgreiche Dateiübertragung über einen Pfadwechsel beweist keinen Dauerbetrieb. Wiederholen Sie die Übertragung, während Sie den bevorzugten Pfad umschalten, und prüfen Sie sowohl die Sicht des Carriers als auch die eigenen Zähler des VPN. Stimmen beide darin nicht überein, welcher Pfad die Daten trug, ist der Vertrag noch nicht beobachtbar.

Bewahren Sie die abgenommene Matrix beim Deployment auf. Sie sagt dem nächsten Ingenieur, welches Verhalten versprochen wurde, welche Pfadkombinationen getestet wurden und welcher Fehlermodus nicht unterstützt bleibt – ohne eine weitere Runde Rätselraten anhand von Link-Statusleuchten.