Ein VPN-Konto über zwei Server: drei Zustandsregister

Ein Konto, das sich an einem von zwei VPN-Knoten anmelden kann, wirft eine Entwurfsfrage lange bevor es eine Softwarefrage aufwirft. Die Kontosicht, das Netzwerk, das jeder Knoten besitzt, und die Sitzung, die ein verbundener Client hält, sind drei verschiedene Arten von Zustand, und sie versagen auf unterschiedliche Weise, wenn man sie herumkopiert. Alle drei in ein System zu kopieren ist ein verbreiteter Weg, eines davon zu verlieren.

Arbeiten Sie die drei Register unten der Reihe nach durch. Jedes fragt, was maßgeblich ist, was lokal ist und was passiert, wenn der andere Knoten fehlt, und die Antworten folgen nicht auseinander.

Wer sich verbinden darf: eine Instanz, viele Knoten

Beginnen Sie mit dem Zulassungsregister: welche Identitätsquelle maßgeblich ist, welchen Zertifikatsausstellern vertraut wird, welche Konten zulässig sind, welcher zweite Faktor gilt und was jedes Konto erreichen darf. Schreiben Sie dann auf, wie jeder Knoten von Änderungen erfährt und wie schnell.

Eine gemeinsam genutzte Datenbank ist eine mögliche Komponente dieser Antwort. Sie ist kein Beweis dafür, dass jede relevante Richtlinie dort lebt oder dass jeder Knoten eine Änderung im selben Moment anwendet. Ein Konto, das an Knoten A deaktiviert, aber an Knoten B noch akzeptiert wird, bedeutet, dass der Offboarding-Prozess nicht abgeschlossen ist.

Entscheiden Sie, was ein Knoten tut, wenn die Instanz nicht erreichbar ist. Zwischengespeicherte Anmeldedaten während einer Störung zu akzeptieren ist eine Richtlinienentscheidung mit Sicherheitskosten, und sie abzulehnen ist eine Richtlinienentscheidung mit Verfügbarkeitskosten. Beides ist vertretbar; es undokumentiert zu lassen nicht.

Halten Sie die Ausstellerinstanz auch von den Kontodaten getrennt. Mehrere Gateways können derselben CA vertrauen, ohne deren Signaturschlüssel zu halten, und jeder Knoten braucht weiterhin sein eigenes Serverzertifikat und seine eigene Vertrauensbeziehung auf Clientseite.

Was ein Knoten besitzt: Adressen und Routen

Das zweite Register ist lokal für jeden Knoten: Listen-Adresse, Serveridentität, Adresspool, Routen zu privaten Ressourcen, Resolver-Richtlinie und wie der Verkehr ins Internet abgeht. Dasselbe Konto kann von jedem der beiden Knoten bedient werden, während diese Objekte getrennt bleiben.

Der Rückweg ist der Teil, der vergessen wird. Wenn beide Knoten Adressen aus demselben Pool ausgeben, kann das private Netzwerk nicht erkennen, welchem Knoten ein bestimmter Client gehört, und die Antwort kann an die falsche Stelle gehen. Unterschiedliche Pools brauchen ebenfalls Routen und Berechtigungen, ein getrennter Nummernbereich ist also kein vollständiger Entwurf.

Leiten Sie Clients bewusst zu einem Knoten. DNS-Auswahl, Client-Endpunktlisten und ein Front-End-Dienst sind verschiedene Mechanismen mit unterschiedlichem Health- und Failover-Verhalten. Einen davon zu wählen ist in Ordnung; „Lastverteilung“ als den Entwurf zu behandeln lässt Rückweg und Fehlerverhalten undefiniert.

Ein dokumentiertes Produktbeispiel hilft hier. Die Replikationsdokumentation von Pritunl behandelt das VPN-Netzwerk als Objekt pro Replik, und Clients auf verschiedenen Repliken brauchen zusätzliche Routen und Konnektivität, um einander zu erreichen. Das ist eine produktspezifische Anordnung, kein Rezept für Community OpenVPN, aber sie zeigt, warum das Hinzufügen einer Replik das Netzwerk verändert und nicht nur den Kontospeicher.

Was eine Sitzung ist: laufender Zustand, keine Zeile

Das dritte Register ist die laufende Sitzung. Ein verbundener Client hat Protokollzustand und eine Netzzuweisung auf dem Knoten, der ihn angenommen hat. Dass das Konto am anderen Knoten bekannt ist, gibt diesem Knoten nicht die Sitzung, die Schlüssel oder die Fähigkeit, die Pakete fortzusetzen.

Seien Sie ausdrücklich darüber, was passiert, wenn ein Knoten ausfällt. Das unterstützte Ergebnis kann eine erneute Verbindung zum anderen Knoten mit frischer Authentifizierung und einer neuen Adresse sein, wonach sich die Anwendung auf ihre eigene Weise erholt. Wenn eine unterbrechungsfreie Übergabe gefordert ist, braucht diese Anforderung ausdrückliche Umsetzungsunterstützung, keine Folgerung aus der Datenbankreplikation. Schreiben Sie die Antwort dort auf, wo der Bereitschaftsingenieur sie findet.

Kapazitätsregeln brauchen dieselbe Behandlung. Ein Limit von zwei gleichzeitigen Sitzungen pro Konto lässt sich nur knotenübergreifend durchsetzen, wenn eine Instanz eine abgestimmte Sicht auf belegte Plätze hat. Knotenlokale Listen und ein historischer Kontoeintrag summieren sich nicht zu dieser Sicht.

Die drei Register prüfen

Üben Sie jedes einzeln. Melden Sie sich über Knoten A an, dann über Knoten B, und bestätigen Sie, dass beides mit den erwarteten Adressbereichen gelingt. Ziehen Sie eine Identität zurück und prüfen Sie beide Knoten, nicht nur den, den Sie zufällig getestet haben. Stoppen Sie dann einen Knoten und beobachten Sie, was der Client und die private Anwendung tatsächlich tun.

Nehmen Sie den Rückweg in die Abnahme auf. Ein Client, der sich mit B verbindet, aber keine Antworten von einer Ressource hinter A empfangen kann, hat die Zulassungsprüfung bestanden und die Netzwerkprüfung nicht, und dieser Unterschied sollte im Bericht erscheinen.

Erst wenn alle drei Register einen ausdrücklichen Eigentümer, einen Änderungspfad und ein Fehlerverhalten haben, ist der Entwurf für ein Konto über mehrere Knoten vollständig. Eine Konfigurationsdatei zwischen Knoten zu kopieren beantwortet keine dieser Fragen.