Første økt vinner: begrensning av OpenVPN-innlogginger før utkastelse
Å avvise en senere innlogging er ikke det samme som å erstatte den gamle. Beslutningen må tas før utkastelsen av samme navn, og slottkontrollen må være atomisk.
En policy som tillater én økt per konto virker avgjort helt til den andre innloggingen kommer. To utfall er mulige: den nye erstatter økten som kjører, eller økten som kjører beholder slottet og den nye avvises. Bare det andre er en policy der første økt vinner. Klientvalget de fleste griper til, aktiverer samtidighet og gir derfor ikke dette.
To kontrakter skjuler seg bak én innstilling
Med samtidighet slått av kan en andre tilkobling med samme sertifikatnavn fortrenge økten som allerede kjører. Å slå på samtidighet tillater flere økter samtidig, som er det motsatte av en grense. Ingen av tilstandene er en avvisningspolicy, så beslutningen må tas et helt annet sted.
Skriv ned kontrakten før du implementerer noe: hvem som avvises, hvilket bevis som identifiserer økten som kjører, og hva som skjer når en økt dør uten en ren frakobling. En policy som ingen har formulert slik, kan ikke testes senere.
Utkastelsen skjer før connect-kroken din
I serverkoden for 2.6 fjerner den tidlige klargjøringen av en ny klient eksisterende instanser med samme navn når samtidighet er slått av. Den fjerningen skjer før kjeden av connect-handlere kjører. Et skript som oppdager duplikatet og returnerer feil, avviser derfor den nye etter at økten som kjører allerede er kastet ut - nøyaktig utfallet policyen skulle forhindre. Rekkefølgen på tilbakeringingene i upstream-implementasjonen er det eneste pålitelige svaret for ditt bygg.
| 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 statusfilen er heller ikke en port. To forsøk som kommer samtidig, kan begge se et tomt slott før noen av dem bekrefter det, og begge fortsetter.
Flytt beslutningen inn i autentiseringen
Administrasjonsgrensesnittet kan overta autentiseringsbeslutningen etter sertifikatverifiseringen. I den ordningen er kontrolleren ikke en overvåker: den mottar hver tilkoblende klientinstans og svarer på om den instansen kan fortsette. Fordi svaret kommer før etableringen, lar en avvisning økten som kjører være urørt. Den samme kanalen rapporterer frakoblinger, og slik lærer kontrolleren at et slott er lovlig frigitt.
Hver ny instans må passere den porten, inkludert gjenoppkoblinger og enhver vei som autentiserer på nytt uten forespørsel. En port som noen instanser aldri når, beskytter ingenting, og utelatelsen forblir usynlig til noen prøver omveien.
Tokener kan gå forbi porten
Når et token er utstedt, kan serveren validere det internt og hoppe over ekstern autentisering for den tilkoblingen. Administrasjonskallet skjer aldri, så en slottkontroll som bare er implementert der, ser aldri den nye instansen. Den oppførselen er en bekvemmelighet for brukere og et hull i en samtidighetspolicy. La token-autentiserte tilkoblinger passere en tilsvarende autoritativ kontroll, eller slå av tokenveien når policyen krever en beslutning på hver tilkobling.
Ikke kompenser med å akseptere hvert token ubetinget. Et utløpt eller ugyldig token må fortsatt feile, og det må feile gjennom samme beslutningspunkt som alt annet.
Bind reservasjonen til en instans, ikke til en adresse
En adresse er en svak identitet: en gjenoppkobling fra samme bærbare kan komme fra en annen adresse, og en kopiert legitimasjon kan komme fra den samme. Bind reservasjonen til klientinstansen serveren tildeler, slik at en reautentisering av den allerede tillatte instansen gjenkjennes som eieren. En ny instansidentifikator må skaffe seg sitt eget slott gjennom førstemann-vinner-beslutningen, selv når den presenterer samme token.
Frigi bare reservasjonen som tilhører det mislykkede forsøket. En forsinket frakoblingshendelse fra et eldre forsøk må ikke slette slottet til en nyere eier, og derfor navngir frigivelsen instansen og ikke kontoen. Etter omstart av kontrolleren må de levende øktene avstemmes før noen tas inn, og den samme regelen gjelder på hver gateway som betjener kontoen.
Avgjør separat hvordan et virkelig utdatert slott gjenopprettes. En administrator trenger en dokumentert måte å rydde det på, og den veien bør ikke være tilgjengelig for en bruker som bare klikker på koble til på nytt.
Test parene som betyr noe: to nesten samtidige innlogginger, en gjenoppkobling etter en ren avslutning, en reautentisering av økten som kjører, en avvist nykommer og en omstart av kontrolleren. I alle tilfeller må økten som kjører forbli brukbar, og den nye må avvises uten skade på andre kontoer.