La unua seanco venkas: limigado de OpenVPN-ensalutoj antaŭ elpelado
Rifuzi postan ensaluton ne samas al anstataŭigi la malnovan. La decido devas okazi antaŭ la elpelado de la samnoma seanco, kaj la kontrolaĵo de la loko devas esti atoma.
Politiko, kiu permesas unu seancn po konto, ŝajnas solvita ĝis alvenos la dua ensaluto. Du eblaj rezultoj: la novulo anstataŭigas la nunan seancn, aŭ la nuna seanco konservas la lokon kaj la novulo estas rifuzata. Nur la dua estas politiko de la unua seanco. La klienta opcio, al kiu plej multaj turniĝas, ebligas samtempecon kaj do ne produktas tion.
Du kontraktoj kaŝiĝas malantaŭ unu agordo
Kiam samtempeco estas malŝaltita, dua konekto kun la sama atestila nomo povas delokigi la jam kurantan seancn. Ŝalti samtempecon permesas plurajn seancjn samtempe, kio estas la malo de limo. Neniu el la du statoj estas rifuza politiko, do la decido devas esti farita tute alie.
Skribu la kontrakton antaŭ ol efektivigi ion ajn: kiu estas rifuzata, kia pruvo identigas la nunan seancn kaj kio okazas kiam seanco mortas sen pura malkonekto. Politiko, kiun neniu esprimis tiel, ne povas esti testita poste.
La elpelado okazas antaŭ via konekta hoko
En la servila kodvojo de 2.6, frua preparo por nova kliento forigas ekzistantajn instancojn kun la sama nomo kiam samtempeco estas malŝaltita. Tiu forigo okazas antaŭ ol la ĉeno de konektaj traktiloj ekfunkcias. Skripto, kiu rimarkas la duplikaton kaj redonas malsukceson, do rifuzas la novulon post kiam la nuna seanco jam estis forĵetita - ĝuste la rezulto, kiun la politiko celis malhelpi. La ordo de retrovokoj en la upstream-efektivigo estas la sola fidinda respondo por via konstruo.
| 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 |
Ankaŭ enketado de la statdosiero ne estas pordego. Du provoj alvenantaj kune povas ambaŭ vidi malplenan lokon antaŭ ol iu konfirmas, kaj ambaŭ daŭrigas.
Transloku la decidon en la aŭtentikigon
La administra interfaco povas transpreni la aŭtentikigan decidon post atestila kontrolo. En tiu aranĝo la regilo ne estas observanto: ĝi ricevas ĉiun konektiĝantan klientan instancon kaj respondas ĉu tiu instanco rajtas daŭrigi. Ĉar la respondo alvenas antaŭ la starigo, rifuzo lasas la nunan seancn netuŝita. La sama kanalo raportas malkonektojn, kaj tiel la regilo ekscias, ke loko estis laŭleĝe liberigita.
Ĉiu nova instanco devas trapasi tiun pordegon, inkluzive de rekonektoj kaj iu ajn vojo, kiu reaŭtentikigas sen demando. Pordego, kiun iuj instancoj neniam atingas, protektas nenion, kaj la preterlaso restas nevidebla ĝis iu provos la pretervojon.
Ĵetonoj povas preterpasi la pordegon
Post kiam ĵetono estas eldonita, la servilo povas validigi ĝin interne kaj preterpasi eksteran aŭtentikigon por tiu konekto. La administra voko neniam okazas, do loko-kontrolo efektivigita nur tie neniam vidas la novan instancon. Tiu konduto estas komforto por uzantoj kaj truo por samtempeca politiko. Devigu ĵetonajn konektojn trapasi ekvivalentan aŭtoritatan kontrolon, aŭ malŝaltu la ĵetunan vojon kiam la politiko postulas decidon pri ĉiu konekto.
Ne kompensu per senkondiĉa akcepto de ĉiu ĵetono. Eksvalidiĝinta aŭ nevalida ĵetono ankoraŭ devas malsukcesi, kaj ĝi devas malsukcesi tra la sama decida punkto kiel ĉio alia.
Ligu la rezervon al instanco, ne al adreso
Adreso estas malforta identeco: rekonekto de la sama tekkomputilo povas alveni de alia adreso, kaj kopiita legitimilo povas alveni de la sama. Ligu la rezervon al la klienta instanco, kiun la servilo atribuas, por ke reaŭtentikigo de la jam akceptita instanco estu rekonata kiel la posedanto. Nova instanca identigilo devas akiri sian propran lokon per la decido unua venkas, eĉ kiam ĝi prezentas la saman ĵetonon.
Liberigu nur la rezervon apartenantan al la malsukcesa provo. Malfrua malkonekta evento de pli malnova provo ne rajtas viŝi la lokon de pli nova posedanto, kaj tial la liberigo nomas la instancon anstataŭ la konton. Post restartigo de la regilo, akordigu la vivajn seancjn antaŭ ol akcepti iun, kaj apliku la saman regulon ĉe ĉiu pordego, kiu servas la konton.
Decidu aparte, kiel vere kaduka loko estas rekuperata. Administranto bezonas dokumentitan manieron purigi ĝin, kaj tiu vojo ne devus esti atingebla al uzanto, kiu simple klakas rekonekti.
Testu la parojn, kiuj gravas: du preskaŭ samtemaj ensalutoj, rekonekto post pura malmuntado, reaŭtentikigo de la nuna seanco, rifuzita novulo kaj restartigo de la regilo. En ĉiu kazo la nuna seanco devas resti uzebla kaj la novulo devas esti rifuzita sen flanka damaĝo al aliaj kontoj.