Eerste sessie wen: OpenVPN-aanmeldings voor uitwissing beperk
Om 'n latere aanmelding te verwerp is nie dieselfde as om die ou een te vervang nie. Die besluit moet voor die uitwissing van dieselfde naam val, en die slotkontrole moet atomies wees.
'n Beleid wat een sessie per rekening toelaat, lyk vanselfsprekend totdat die tweede aanmelding opdaag. Twee uitkomste is moontlik: die nuweling vervang die sittende sessie, of die sittende sessie behou die slot en die nuweling word geweier. Net die tweede is 'n beleid waar die eerste sessie wen. Die kliëntopsie waarna die meeste mense gryp, stel gelyktydigheid in werking en lewer dit dus nie.
Twee kontrakte skuil agter een instelling
Met gelyktydigheid afgeskakel kan 'n tweede verbinding met dieselfde sertifikaatnaam die lopende sessie verdring. Gelyktydigheid aan skakel verskeie sessies gelyktydig toe, wat die teenoorgestelde van 'n beperking is. Nie een van die twee is 'n weieringsbeleid nie, so die besluit moet heeltemal elders geneem word.
Skryf die kontrak neer voordat jy iets implementeer: wie word geweier, watter bewyse identifiseer die sittende sessie, en wat gebeur wanneer 'n sessie sterf sonder 'n skoon ontkoppeling. 'n Beleid wat niemand in daardie terme gestel het nie, kan later nie getoets word nie.
Uitwissing gebeur voor jou koppelhaak
In die bedienerkode van 2.6 verwyder die vroeë opstelling vir 'n nuwe kliënt bestaande gevalle met dieselfde naam wanneer gelyktydigheid afgeskakel is. Daardie verwydering vind plaas voordat die koppelhanteringsketting loop. 'n Script wat die duplikaat raaksien en mislukking terugstuur, weier dus die nuweling nadat die sittende sessie reeds laat val is - presies die uitkoms wat die beleid wou voorkom. Die callback-volgorde in die upstream-implementering is die enigste betroubare antwoord vir jou bou.
| 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 |
Om die statuslêer te peil is ook nie 'n hek nie. Twee pogings wat saam opdaag, kan albei 'n leë slot sien voordat een van hulle vasskryf, en albei gaan voort.
Skuif die besluit na die verifikasie
Die bestuurskoppelvlak kan die verifikasiebesluit oorneem nadat die sertifikaat geverifieer is. In daardie reëling is die kontroleerder nie 'n monitor nie: dit ontvang elke kliëntgeval wat koppel en antwoord of daardie geval mag voortgaan. Omdat die antwoord voor die vestiging kom, laat 'n weiering die sittende sessie ongemoeid. Dieselfde kanaal rapporteer ontkoppelings, en so leer die kontroleerder dat 'n slot wettig vrygestel is.
Elke nuwe geval moet daardie hek passeer, insluitend herverbindings en enige pad wat sonder 'n prompt weer verifieer. 'n Hek wat sekere gevalle nooit bereik nie, beskerm niks, en die versuim bly onsigbaar totdat iemand die ompad gebruik.
Tokkens kan verby die hek stap
Sodra 'n token uitgereik is, kan die bediener dit intern valideer en eksterne verifikasie vir daardie verbinding oorslaan. Die bestuursoproep vind nooit plaas nie, so 'n slotkontrole wat net daar geïmplementeer is, sien nooit die nuwe geval nie. Daardie gedrag is 'n gerief vir gebruikers en 'n gat vir 'n gelyktydigheidsbeleid. Laat token-geverifieerde verbindings 'n ekwivalente gesaghebbende kontrole slaag, of skakel die tokenpad af wanneer die beleid 'n besluit oor elke verbinding vereis.
Moenie dit vergoed deur elke token onvoorwaardelik te aanvaar nie. 'n Vervalle of ongeldige token moet steeds misluk, en dit moet deur dieselfde besluitpunt as alles anders misluk.
Bind die bespreking aan 'n geval, nie aan 'n adres nie
Adres is swak identiteit: 'n herverbinding van dieselfde skootrekenaar kan van 'n ander adres kom, en 'n gekopieerde geloofsbrief kan van dieselfde adres kom. Sleutel die bespreking aan die kliëntgeval wat die bediener toeken, sodat 'n herverifikasie van die reeds toegelate geval as die eienaar erken word. 'n Nuwe gevalidentifiseerder moet sy eie slot deur die eerste-wen-besluit kry, selfs wanneer dit dieselfde token aanbied.
Stel net die bespreking vry wat aan die mislukte poging behoort. 'n Vertraagde ontkoppelgebeurtenis van 'n ouer poging mag nie die slot van 'n nuwer eienaar skoonmaak nie, en daarom noem die vrystelling die geval eerder as die rekening. Nadat die kontroleerder herbegin het, versoen die lewende sessies voordat jy iemand toelaat, en pas dieselfde reël op elke poort toe wat die rekening bedien.
Besluit afsonderlik hoe 'n werklik verouderde slot herwin word. 'n Administrateur het 'n gedokumenteerde manier nodig om dit skoon te maak, en daardie pad moet nie bereikbaar wees vir 'n gebruiker wat net op herverbind klik nie.
Toets die pare wat saak maak: twee byna gelyktydige aanmeldings, 'n herverbinding na 'n skoon afbreek, 'n herverifikasie van die sittende sessie, 'n geweierde nuweling en 'n herbegin van die kontroleerder. In elke geval moet die sittende sessie bruikbaar bly en die nuweling geweier word sonder skade aan ander rekeninge.