Die erste Sitzung gewinnt: OpenVPN-Logins vor der Verdrängung begrenzen
Ein späteres Login abzulehnen ist nicht dasselbe wie das alte zu ersetzen. Die Entscheidung muss vor der Verdrängung des gleichnamigen Eintrags fallen, und die Slot-Prüfung muss atomar sein.
Eine Richtlinie, die eine Sitzung pro Konto erlaubt, wirkt geklärt, bis das zweite Login eintrifft. Zwei Ausgänge sind möglich: Der Neuling verdrängt die bestehende Sitzung, oder die bestehende Sitzung behält den Slot und der Neuling wird abgelehnt. Nur der zweite ist eine Richtlinie, bei der die erste Sitzung gewinnt. Die Client-Option, zu der die meisten greifen, aktiviert Parallelität und erzeugt das daher nicht.
Zwei Verträge verbergen sich hinter einer Einstellung
Bei deaktivierter Parallelität kann eine zweite Verbindung mit demselben Zertifikatsnamen die bereits laufende Sitzung verdrängen. Parallelität einzuschalten erlaubt mehrere Sitzungen gleichzeitig, also das Gegenteil einer Begrenzung. Keiner der Zustände ist eine Ablehnungsrichtlinie, die Entscheidung muss also ganz woanders fallen.
Schreiben Sie den Vertrag auf, bevor Sie irgendetwas implementieren: wer abgelehnt wird, welcher Nachweis die bestehende Sitzung identifiziert und was passiert, wenn eine Sitzung ohne saubere Trennung stirbt. Eine Richtlinie, die niemand so formuliert hat, lässt sich später nicht prüfen.
Die Verdrängung erfolgt vor Ihrem Connect-Hook
Im Server-Codepfad von 2.6 entfernt die frühe Einrichtung eines neuen Clients vorhandene Instanzen mit demselben Namen, wenn Parallelität deaktiviert ist. Dieses Entfernen geschieht, bevor die Kette der Connect-Handler läuft. Ein Skript, das das Duplikat bemerkt und einen Fehler zurückgibt, lehnt den Neuling daher ab, nachdem die bestehende Sitzung bereits verworfen wurde - genau das Ergebnis, das die Richtlinie verhindern sollte. Die Callback-Reihenfolge in der Upstream-Implementierung ist die einzige verlässliche Antwort für Ihren Build.
| Stage | Who can still refuse | Effect on the incumbent |
|---|---|---|
| Certificate check | Server trust configuration | None |
| Authentication decision | The authentication controller | None, because establishment has not run |
| Connect handler | A profile script | Already evicted in the same-name case |
| Post-establishment | Status tooling, monitoring | Both sessions already exist or one is gone |
Die Statusdatei abzufragen ist ebenfalls kein Tor. Zwei gleichzeitig eintreffende Versuche können beide einen leeren Slot sehen, bevor einer ihn belegt, und beide fahren fort.
Verlagern Sie die Entscheidung in die Authentifizierung
Die Management-Schnittstelle kann die Authentifizierungsentscheidung nach der Zertifikatsprüfung übernehmen. In dieser Anordnung ist der Controller kein Beobachter: Er empfängt jede sich verbindende Client-Instanz und antwortet, ob diese Instanz fortfahren darf. Da die Antwort vor dem Aufbau kommt, bleibt die bestehende Sitzung bei einer Ablehnung unberührt. Derselbe Kanal meldet Trennungen, und so erfährt der Controller, dass ein Slot rechtmäßig freigegeben wurde.
Jede neue Instanz muss dieses Tor passieren, einschließlich Wiederverbindungen und jedes Pfads, der ohne Nachfrage erneut authentifiziert. Ein Tor, das manche Instanzen nie erreichen, schützt nichts, und die Auslassung bleibt unsichtbar, bis jemand die Umgehung ausprobiert.
Tokens können am Tor vorbeigehen
Sobald ein Token ausgestellt wurde, kann der Server es intern prüfen und die externe Authentifizierung für diese Verbindung überspringen. Der Management-Aufruf findet nie statt, daher sieht eine nur dort implementierte Slot-Prüfung die neue Instanz nie. Dieses Verhalten ist ein Komfort für Nutzer und ein Loch in einer Parallelitätsrichtlinie. Lassen Sie token-authentifizierte Verbindungen eine gleichwertige verbindliche Prüfung passieren oder deaktivieren Sie den Token-Pfad, wenn die Richtlinie eine Entscheidung bei jeder Verbindung verlangt.
Kompensieren Sie das nicht, indem Sie jedes Token bedingungslos akzeptieren. Ein abgelaufenes oder ungültiges Token muss weiterhin scheitern, und zwar über denselben Entscheidungspunkt wie alles andere.
Binden Sie die Reservierung an eine Instanz, nicht an eine Adresse
Eine Adresse ist eine schwache Identität: Eine Wiederverbindung vom selben Laptop kann von einer anderen Adresse kommen, und ein kopierter Zugangsdatensatz kann von derselben kommen. Binden Sie die Reservierung an die Client-Instanz, die der Server vergibt, damit eine erneute Authentifizierung der bereits zugelassenen Instanz als Eigentümer erkannt wird. Eine neue Instanzkennung muss ihren eigenen Slot über die Erstgewinner-Entscheidung erwerben, selbst wenn sie dasselbe Token vorlegt.
Geben Sie nur die Reservierung des fehlgeschlagenen Versuchs frei. Ein verzögertes Trennungsereignis eines älteren Versuchs darf den Slot eines neueren Eigentümers nicht löschen, deshalb benennt die Freigabe die Instanz statt des Kontos. Nach einem Neustart des Controllers gleichen Sie die lebenden Sitzungen ab, bevor Sie jemanden zulassen, und wenden Sie dieselbe Regel auf jedes Gateway an, das das Konto bedient.
Entscheiden Sie separat, wie ein wirklich veralteter Slot zurückgewonnen wird. Ein Administrator braucht einen dokumentierten Weg, ihn zu bereinigen, und dieser Weg sollte für einen Nutzer, der einfach auf Wiederverbinden klickt, nicht erreichbar sein.
Testen Sie die Paare, die zählen: zwei nahezu gleichzeitige Logins, eine Wiederverbindung nach sauberem Abbau, eine erneute Authentifizierung der bestehenden Sitzung, einen abgelehnten Neuling und einen Controller-Neustart. In jedem Fall muss die bestehende Sitzung nutzbar bleiben und der Neuling ohne Kollateralschaden für andere Konten abgelehnt werden.