Zweiter VPN-Endpunkt: Was er abdeckt und was nicht

Zwei Endpunkte wirken auf dem Papier wie Redundanz. In der Praxis hilft eine zweite Adresse nur, wenn Clients sie erreichen können und wenn sie den Ausfall vermeidet, auf den Sie vorbereitet sind. Zwei Server hinter derselben Zugangsverbindung, demselben Konto oder demselben Zielnetz fallen gemeinsam aus. Die nützliche Frage ist, welchen einzelnen Ausfall der zweite Endpunkt beseitigt.

Vergleichen Sie, was beide Endpunkte teilen

Listen Sie auf, was die beiden Endpunkte gemeinsam haben, bevor Sie zählen, was sie doppeln. Hosting-Standort, Anbieterkonto, Upstream-Transit, DNS-Hosting, die Identitätsquelle und die private Ressource hinter dem Tunnel sind jeweils eine geteilte oder eine unabhängige Abhängigkeit. Zwei virtuelle Maschinen in einer Region teilen einen Anbieterausfall. Zwei Regionen unter einem Konto teilen weiterhin die Abrechnungsbeziehung und die Steuerungsebene, die sie bereitstellt.

Das Zielnetz verdient dieselbe Behandlung. Ein gesundes Reserve-Gateway kann ein NAS, das offline ist, nicht wiederherstellen, und es erreicht kein Büronetz, dessen Uplink ausgefallen ist. Wenn beide Endpunkte in dasselbe private Subnetz münden, fügt der zweite nur einen Pfad zu einem Ziel hinzu, das bereits der einzige Ausfallpunkt ist.

Identität ist die Abhängigkeit, die man vergisst. Das Klonen des Zertifikats und der Konfiguration auf einen zweiten Host schafft zwei Stellen, an denen dieselbe Anmeldeinformation kopiert werden kann, und sagt nichts darüber aus, wie Sperrungen beide erreichen.

Legen Sie fest, wie ein Client wechselt

Ein zweiter Endpunkt ist nur nützlich, wenn der Client ihn kennt und ohne Anruf beim Support auswählen kann. OpenVPN-Verbindungsprofile können mehrere remote-Zeilen mit einer Auswahlrichtlinie enthalten, und die meisten Clients bieten ein Alternativprofil in einem Menü. Schreiben Sie unabhängig vom Mechanismus auf, welches Ihre Nutzer haben, denn ein Profil, das sie nicht finden, ist kein Failover.

Lesen Sie die Client-Dokumentation zu Adressänderungen während einer Sitzung. Manche Implementierungen behalten den ursprünglichen Peer für die Lebensdauer des Tunnels und konsultieren Alternativen erst beim erneuten Verbinden. Dieser Unterschied entscheidet, ob ein toter Endpunkt eine kurze Unterbrechung oder eine Sitzung erzeugt, die nie zurückkommt. Testen Sie den Wiederverbindungspfad, statt anzunehmen, dass er stattfindet.

Eine geänderte Ausgangsadresse bricht auch den Anwendungszustand. Failover ist Wiederherstellung, und es als ununterbrochene Kontinuität zu beschreiben, weckt eine Erwartung, die der Transport nicht erfüllen kann.

Testen Sie einen echten Ausfall

Wählen Sie einen kontrollierten Ausfall und führen Sie ihn von Anfang bis Ende durch, statt dem Designdokument zu vertrauen. Stoppen Sie den primären Endpunkt und bestätigen Sie dann, dass ein autorisierter Client die vorgesehene Anwendung über die Alternative erreicht, während nicht autorisierte Clients es weiterhin nicht können. Notieren Sie, wie lange der Wechsel dauerte und was die Anwendung sah.

dig +short vpn2.example.net
ip route get 10.20.30.41
journalctl -u openvpn@backup --since '-10 min'

Der erste Befehl bestätigt, dass der Reservename zu etwas Routingfähigem auflöst, bevor Sie ihn brauchen, und das ist hier der billigste Test. Der zweite zeigt, welche Schnittstelle der Kernel für ein privates Ziel verwenden würde, sobald die Alternative aktiv ist. Der dritte liefert das Client-Log mit dem Namen des Peers, mit dem tatsächlich verbunden wurde, und das ist der einzige Beweis, dass der Wechsel stattfand. Achten Sie auch auf das Blockierverhalten während der Lücke, denn eine Richtlinie, die beim Wechseln Verkehr durchlässt, ist schlimmer als eine kurze Unterbrechung.

Bringen Sie dann das Original zurück und bestätigen Sie, ob der Client zurückkehrt. Ein Failback, das zufällig geschieht, ist ein Verhalten, das niemand geplant hat.

Schreiben Sie auf, was die zweite Adresse bringt

Fassen Sie die Abdeckung in einem Absatz zusammen: welchen Ausfall der zweite Endpunkt beseitigt, welche Ausfälle er mit dem ersten teilt und auf welchen Annahmen der Wechsel beruht. Nennen Sie den Mechanismus auf Client-Seite sowie die privaten Routen und das DNS-Verhalten, die an beiden Standorten vorhanden sein müssen. Ein öffentlicher Internet-Ausgang ersetzt kein privates Gateway, und einem Dokument, das beide als austauschbar behandelt, wird geglaubt. Fügen Sie den durchgeführten Wiederherstellungstest mit Datum und Ergebnis hinzu.

Unabhängigkeit von einem Server ist keine Unabhängigkeit vom geteilten Konto oder vom Zielnetz. Der Absatz, der das laut sagt, verhindert, dass eine zweite Adresse intern als Hochverfügbarkeit verkauft wird. Er sagt dem nächsten Betreiber auch, was zuerst zu prüfen ist, wenn das Paar gemeinsam ausfällt.