Första sessionen vinner: begränsning av OpenVPN-inloggningar före utträngning
Att avvisa en senare inloggning är inte samma sak som att ersätta den gamla. Beslutet måste fattas före utträngningen av samma namn, och slottkontrollen måste vara atomär.
En policy som tillåter en session per konto verkar avgjord tills den andra inloggningen kommer. Två utfall är möjliga: den nya ersätter sessionen som körs, eller sessionen som körs behåller slotten och den nya avvisas. Bara det andra är en policy där första sessionen vinner. Klientalternativet som de flesta griper efter aktiverar samtidighet och ger därför inte detta.
Två kontrakt gömmer sig bakom en inställning
Med samtidighet avstängd kan en andra anslutning med samma certifikatnamn tränga undan sessionen som redan körs. Att slå på samtidighet tillåter flera sessioner samtidigt, vilket är motsatsen till en gräns. Inget av tillstånden är en avvisningspolicy, så beslutet måste fattas någon helt annanstans.
Skriv ned kontraktet innan du implementerar något: vem som avvisas, vilket bevis som identifierar sessionen som körs och vad som händer när en session dör utan en ren frånkoppling. En policy som ingen har formulerat så kan inte testas senare.
Utträngningen sker före din connect-hook
I serverkoden för 2.6 tar den tidiga förberedelsen av en ny klient bort befintliga instanser med samma namn när samtidighet är avstängd. Den borttagningen sker innan kedjan av connect-hanterare körs. Ett skript som upptäcker dubbletten och returnerar fel avvisar därför den nya efter att sessionen som körs redan har kastats ut - exakt det utfall som policyn skulle förhindra. Ordningen på återanropen i upstream-implementeringen är det enda pålitliga svaret för din 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 |
Att polla statusfilen är inte heller en port. Två försök som kommer samtidigt kan båda se en tom slott innan någon av dem bekräftar den, och båda fortsätter.
Flytta beslutet till autentiseringen
Administrationsgränssnittet kan ta över autentiseringsbeslutet efter certifikatverifieringen. I den ordningen är kontrollern ingen övervakare: den tar emot varje anslutande klientinstans och svarar på om den instansen får fortsätta. Eftersom svaret kommer före etableringen lämnar en avvisning sessionen som körs orörd. Samma kanal rapporterar frånkopplingar, och så lär sig kontrollern att en slott har frigjorts lagligt.
Varje ny instans måste passera den porten, inklusive återanslutningar och varje väg som autentiserar om utan uppmaning. En port som vissa instanser aldrig når skyddar ingenting, och utelämnandet förblir osynligt tills någon provar omvägen.
Tokens kan gå förbi porten
När en token har utfärdats, kan servern validera den internt och hoppa över extern autentisering för den anslutningen. Administrationsanropet sker aldrig, så en slottkontroll som bara är implementerad där ser aldrig den nya instansen. Det beteendet är en bekvämlighet för användare och ett hål i en samtidighetspolicy. Låt token-autentiserade anslutningar passera en likvärdig auktoritativ kontroll, eller stäng av tokenvägen när policyn kräver ett beslut för varje anslutning.
Kompensera inte genom att acceptera varje token villkorslöst. En utgången eller ogiltig token måste fortfarande misslyckas, och den måste misslyckas genom samma beslutspunkt som allt annat.
Bind reservationen till en instans, inte till en adress
En adress är en svag identitet: en återanslutning från samma bärbara dator kan komma från en annan adress, och en kopierad inloggningsuppgift kan komma från samma. Bind reservationen till den klientinstans som servern tilldelar, så att en reautentisering av den redan tillåtna instansen känns igen som ägaren. En ny instansidentifierare måste skaffa sin egen slott genom först-till-kvarn-beslutet, även när den presenterar samma token.
Frigör bara den reservation som hör till det misslyckade försöket. En fördröjd frånkopplingshändelse från ett äldre försök får inte rensa slotten för en nyare ägare, och därför namnger frigöringen instansen och inte kontot. Efter omstart av kontrollern måste de levande sessionerna stämmas av innan någon släpps in, och samma regel gäller på varje gateway som betjänar kontot.
Avgör separat hur en verkligen inaktuell slott återvinns. En administratör behöver ett dokumenterat sätt att rensa den, och den vägen bör inte vara nåbar för en användare som bara klickar på återanslut.
Testa paren som spelar roll: två nästan samtidiga inloggningar, en återanslutning efter en ren avslutning, en reautentisering av sessionen som körs, en avvisad nykomling och en omstart av kontrollern. I varje fall måste sessionen som körs förbli användbar och den nya måste avvisas utan skada på andra konton.