Første session vinder: begrænsning af OpenVPN-logins før udsmidning
At afvise et senere login er ikke det samme som at erstatte det gamle. Beslutningen skal ligge før udsmidningen af samme navn, og slotkontrollen skal være atomar.
En politik, der tillader én session pr. konto, ser afgjort ud, indtil det andet login ankommer. To udfald er mulige: den nye erstatter den siddende session, eller den siddende session beholder slottet, og den nye afvises. Kun det andet er en politik, hvor den første session vinder. Den klientindstilling, de fleste griber til, aktiverer samtidighed og giver derfor ikke dette.
To kontrakter gemmer sig bag én indstilling
Med samtidighed slået fra kan en anden forbindelse med samme certifikatnavn fortrænge den session, der allerede kører. At slå samtidighed til tillader flere sessioner på én gang, hvilket er det modsatte af en grænse. Ingen af tilstandene er en afvisningspolitik, så beslutningen skal træffes helt andre steder.
Skriv kontrakten ned, før du implementerer noget: hvem afvises, hvilket bevis identificerer den siddende session, og hvad der sker, når en session dør uden en ren afbrydelse. En politik, som ingen har formuleret sådan, kan ikke testes bagefter.
Udsmidningen sker før din connect-hook
I serverkoden for 2.6 fjerner den tidlige opsætning af en ny klient eksisterende instanser med samme navn, når samtidighed er slået fra. Den fjernelse sker, før kæden af connect-handlere kører. Et script, der opdager dubletten og returnerer fejl, afviser derfor den nye, efter at den siddende session allerede er smidt ud - præcis det udfald, politikken skulle forhindre. Rækkefølgen af callbacks i upstream-implementeringen er det eneste pålidelige svar for dit 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 |
At polle statusfilen er heller ikke en port. To forsøg, der ankommer samtidig, kan begge se et tomt slot, før nogen af dem committer, og begge fortsætter.
Flyt beslutningen ind i autentificeringen
Management-interfacet kan overtage autentificeringsbeslutningen efter certifikatverifikationen. I den ordning er controlleren ikke en overvåger: den modtager hver forbindende klientinstans og svarer på, om den instans må fortsætte. Fordi svaret kommer før etableringen, lader en afvisning den siddende session urørt. Den samme kanal rapporterer afbrydelser, og sådan lærer controlleren, at et slot er blevet lovligt frigivet.
Hver ny instans skal passere den port, inklusive genforbindelser og enhver vej, der genautentificerer uden en prompt. En port, som nogle instanser aldrig når, beskytter intet, og udeladelsen forbliver usynlig, indtil nogen bruger omvejen.
Tokens kan gå forbi porten
Når et token er udstedt, kan serveren validere det internt og springe ekstern autentificering over for den forbindelse. Management-kaldet sker aldrig, så en slotkontrol, der kun er implementeret der, ser aldrig den nye instans. Den adfærd er en bekvemmelighed for brugere og et hul i en samtidighedspolitik. Lad tokenautentificerede forbindelser passere en tilsvarende autoritativ kontrol, eller slå tokenvejen fra, når politikken kræver en beslutning for hver forbindelse.
Kompensér ikke ved at acceptere hvert token ubetinget. Et udløbet eller ugyldigt token skal stadig fejle, og det skal fejle gennem samme beslutningspunkt som alt andet.
Bind reservationen til en instans, ikke til en adresse
En adresse er en dårlig identitet: en genforbindelse fra den samme bærbare kan komme fra en anden adresse, og en kopieret credential kan komme fra den samme. Bind reservationen til den klientinstans, serveren tildeler, så en genautentificering af den allerede optagne instans genkendes som ejeren. Et nyt instans-id skal skaffe sit eget slot gennem først-vinder-beslutningen, selv når det fremviser det samme token.
Frigiv kun den reservation, der hører til det mislykkede forsøg. En forsinket afbrydelsesbegivenhed fra et ældre forsøg må ikke rydde slottet for en nyere ejer, og derfor navngiver frigivelsen instansen i stedet for kontoen. Efter en genstart af controlleren skal de levende sessioner afstemmes, før nogen optages, og den samme regel skal gælde på hver gateway, der betjener kontoen.
Beslut særskilt, hvordan et virkelig forældet slot genoprettes. En administrator har brug for en dokumenteret måde at rydde det på, og den vej bør ikke være tilgængelig for en bruger, der blot klikker genopret forbindelse.
Test de par, der betyder noget: to næsten samtidige logins, en genforbindelse efter en ren afbrydelse, en genautentificering af den siddende session, en afvist ny og en genstart af controlleren. I alle tilfælde skal den siddende session forblive brugbar, og den nye skal afvises uden skade på andre konti.