Den første økta vinn: avgrensing av OpenVPN-innloggingar før utkasting
Å avvise ei seinare innlogging er ikkje det same som å erstatta den gamle. Avgjerda må takast før utkastinga av same namn, og slottkontrollen må vera atomisk.
Ein politikk som tillèt éi økt per konto verkar avgjord heilt til den andre innlogginga kjem. To utfall er mogelege: den nye erstattar økta som køyrer, eller økta som køyrer held på slottet og den nye vert avvist. Berre det andre er ein politikk der første økt vinn. Klientvalet dei fleste grip til, slår på samtidigheit og gjev derfor ikkje dette.
To kontraktar skjuler seg bak éi innstilling
Med samtidigheit avslegen kan ei andre tilkopling med same sertifikatnamn fortrengje økta som alt køyrer. Å slå på samtidigheit tillèt fleire økter samtidig, som er det motsette av ei grense. Ingen av tilstandane er ein avvisingspolitikk, så avgjerda må takast ein heilt annan stad.
Skriv ned kontrakten før du implementerer noko: kven som vert avvist, kva prov som identifiserer økta som køyrer, og kva som skjer når ei økt døyr utan ein rein fråkopling. Ein politikk som ingen har formulert slik, kan ikkje testast seinare.
Utkastinga skjer før connect-kroken din
I serverkoden for 2.6 fjernar den tidlege klargjeringa av ein ny klient eksisterande instansar med same namn når samtidigheit er avslegen. Den fjerninga skjer før kjeda av connect-handsamlarar køyrer. Eit skript som oppdagar duplikatet og returnerer feil, avviser derfor den nye etter at økta som køyrer alt er kasta ut - nøyaktig utfallet politikken skulle hindre. Rekkjefølgja på tilbakekallingane i upstream-implementasjonen er det einaste pålitelege svaret for bygget ditt.
| 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 |
Å polle statusfila er heller ikkje ei port. To forsøk som kjem samtidig, kan begge sjå eit tomt slott før nokon av dei stadfester det, og begge held fram.
Flytt avgjerda inn i autentiseringa
Administrasjonsgrensesnittet kan overta autentiseringsavgjerda etter sertifikatverifiseringa. I den ordninga er kontrolløren ikkje ein overvakar: den tek imot kvar klientinstans som koplar til og svarar på om den instansen kan halde fram. Fordi svaret kjem før etableringa, lèt ei avvising økta som køyrer vera urørt. Den same kanalen rapporterer fråkoplingar, og slik lærer kontrolløren at eit slott er lovleg frigjeve.
Kvar ny instans må passere den porten, inkludert attkoplingar og kvar veg som autentiserer på nytt utan førespurnad. Ei port som somme instansar aldri når, vernar ingenting, og utelatinga held seg usynleg til nokon prøver omvegen.
Token kan gå forbi porten
Når eit token er gjeve ut, kan serveren validere det internt og hoppe over ekstern autentisering for den tilkoplinga. Administrasjonskallet skjer aldri, så ein slottkontroll som berre er implementert der, ser aldri den nye instansen. Den åtferda er ei lettvintheit for brukarar og eit hol i ein samtidigheitspolitikk. La token-autentiserte tilkoplingar passere ein tilsvarande autoritativ kontroll, eller slå av tokenvegen når politikken krev ei avgjerd på kvar tilkopling.
Ikkje kompenser med å akseptere kvart token utan vilkår. Eit utløpt eller ugyldig token må framleis feile, og det må feile gjennom same avgjerds punkt som alt anna.
Bind reservasjonen til ein instans, ikkje til ein adresse
Ein adresse er ein svak identitet: ei attkopling frå same berbare kan kome frå ein annan adresse, og ein kopiert legitimasjon kan kome frå den same. Bind reservasjonen til klientinstansen serveren tildeler, slik at ein reautentisering av den alt tillatne instansen vert kjend som eigaren. Ein ny instansidentifikator må skaffe seg sitt eige slott gjennom førstemann-vinn-avgjerda, sjølv når den legg fram same token.
Frigjer berre reservasjonen som høyrer til det mislukka forsøket. Ei forseinka fråkoplingshending frå eit eldre forsøk må ikkje sletta slottet til ein nyare eigar, og derfor nemner frigjevinga instansen og ikkje kontoen. Etter omstart av kontrolløren må dei levande øktene avstemmast før nokon vert sleppt inn, og den same regelen gjeld på kvar gateway som tenar kontoen.
Avgjer separat korleis eit verkeleg utdatert slott vert gjenoppretta. Ein administrator treng ein dokumentert måte å rydde det på, og den vegen bør ikkje vera tilgjengeleg for ein brukar som berre klikkar på kople til på nytt.
Test para som betyr noko: to nesten samtidige innloggingar, ei attkopling etter ei rein avslutting, ein reautentisering av økta som køyrer, ein avvist nykomar og ein omstart av kontrolløren. I alle tilfelle må økta som køyrer halde seg brukbar, og den nye må avvisast utan skade på andre kontoar.