De eerste sessie wint: OpenVPN-logins begrenzen vóór de verdrijving

Een beleid dat één sessie per account toestaat lijkt geregeld tot de tweede login binnenkomt. Twee uitkomsten zijn mogelijk: de nieuwkomer vervangt de lopende sessie, of de lopende sessie houdt de slot en de nieuwkomer wordt geweigerd. Alleen het tweede is een beleid waarbij de eerste sessie wint. De clientoptie waar de meeste mensen naar grijpen, schakelt gelijktijdigheid in en levert dat dus niet op.

Twee contracten schuilen achter één instelling

Met gelijktijdigheid uitgeschakeld kan een tweede verbinding met dezelfde certificaatnaam de al lopende sessie verdringen. Gelijktijdigheid aanzetten staat meerdere sessies tegelijk toe, wat het tegenovergestelde van een limiet is. Geen van beide toestanden is een weigeringsbeleid, dus de beslissing moet ergens anders worden genomen.

Schrijf het contract op voordat je iets implementeert: wie wordt geweigerd, welk bewijs de lopende sessie identificeert en wat er gebeurt als een sessie sterft zonder schone verbreking. Een beleid dat niemand zo heeft geformuleerd, kan later niet worden getest.

De verdrijving gebeurt vóór je connect-hook

In het servercodepad van 2.6 verwijdert de vroege voorbereiding van een nieuwe client bestaande instanties met dezelfde naam wanneer gelijktijdigheid is uitgeschakeld. Die verwijdering gebeurt voordat de keten van connect-handlers draait. Een script dat het duplicaat opmerkt en een fout teruggeeft, weigert de nieuwkomer dus nadat de lopende sessie al is weggesmeten - precies de uitkomst die het beleid moest voorkomen. De volgorde van de callbacks in de upstream-implementatie is het enige betrouwbare antwoord voor jouw build.

Het statusbestand pollen is ook geen poort. Twee pogingen die samen aankomen, kunnen beide een lege slot zien voordat een van beide die bevestigt, en beide gaan door.

Verplaats de beslissing naar de authenticatie

De beheerinterface kan de authenticatiebeslissing overnemen na certificaatverificatie. In die opzet is de controller geen monitor: hij ontvangt elke verbindende clientinstantie en antwoordt of die instantie mag doorgaan. Omdat het antwoord vóór de totstandkoming komt, laat een weigering de lopende sessie ongemoeid. Hetzelfde kanaal meldt verbrekingen, en zo leert de controller dat een slot rechtmatig is vrijgegeven.

Elke nieuwe instantie moet die poort passeren, inclusief herverbindingen en elk pad dat zonder prompt opnieuw authenticeert. Een poort die sommige instanties nooit bereiken, beschermt niets, en de omissie blijft onzichtbaar tot iemand de omweg probeert.

Tokens kunnen langs de poort lopen

Zodra een token is uitgegeven, kan de server het intern valideren en externe authenticatie voor die verbinding overslaan. De beheeraanroep gebeurt nooit, dus een slotcontrole die alleen daar is geïmplementeerd, ziet de nieuwe instantie nooit. Dat gedrag is een gemak voor gebruikers en een gat in een gelijktijdigheidsbeleid. Laat token-geauthenticeerde verbindingen een gelijkwaardige gezaghebbende controle passeren, of schakel het tokenpad uit wanneer het beleid een beslissing over elke verbinding eist.

Compenseer dat niet door elk token onvoorwaardelijk te accepteren. Een verlopen of ongeldig token moet nog steeds falen, en het moet falen via hetzelfde beslispunt als al het andere.

Bind de reservering aan een instantie, niet aan een adres

Een adres is een zwakke identiteit: een herverbinding vanaf dezelfde laptop kan van een ander adres komen, en een gekopieerde referentie kan van hetzelfde adres komen. Bind de reservering aan de clientinstantie die de server toewijst, zodat een herauthenticatie van de al toegelaten instantie als eigenaar wordt herkend. Een nieuwe instantie-identificatie moet zijn eigen slot verwerven via de eerste-wint-beslissing, zelfs wanneer die hetzelfde token presenteert.

Geef alleen de reservering vrij die bij de mislukte poging hoort. Een vertraagde verbrekingsgebeurtenis van een oudere poging mag de slot van een nieuwere eigenaar niet wissen, en daarom noemt de vrijgave de instantie en niet het account. Na een herstart van de controller moeten de levende sessies worden afgestemd voordat iemand wordt toegelaten, en dezelfde regel geldt op elke gateway die het account bedient.

Beslis apart hoe een werkelijk verouderde slot wordt hersteld. Een beheerder heeft een gedocumenteerde manier nodig om die op te ruimen, en dat pad zou niet bereikbaar moeten zijn voor een gebruiker die alleen op opnieuw verbinden klikt.

Test de paren die ertoe doen: twee bijna gelijktijdige logins, een herverbinding na een schone afsluiting, een herauthenticatie van de lopende sessie, een geweigerde nieuwkomer en een herstart van de controller. In elk geval moet de lopende sessie bruikbaar blijven en moet de nieuwkomer worden geweigerd zonder collateral damage voor andere accounts.