Sesioni i parë fiton: kufizimi i hyrjeve OpenVPN përpara dëbimit
Refuzimi i një hyrjeje të mëvonshme nuk është njësoj si zëvendësimi i asaj të vjetre. Vendimi duhet të merret përpara dëbimit me të njëjtin emër, dhe kontrolli i slotit duhet të jetë atomik.
Një politikë që lejon një sesion për llogari duket e zgjidhur derisa vjen hyrja e dytë. Dy rezultate janë të mundshme: i reja zë vendin e sesionit që po punon, ose sesioni që po punon mban slotin dhe i reja refuzohet. Vetëm i dyti është politikë ku sesioni i parë fiton. Opsioni i klientit ku mbështeten shumica aktivizon njëkohshmërinë dhe për këtë arsye nuk e prodhon këtë rezultat.
Dy kontrata fshihen pas një cilësimi
Me njëkohshmërinë e çaktivizuar, një lidhje e dytë me të njëjtin emër certifikate mund të dëbojë sesionin që tashmë po punon. Aktivizimi i njëkohshmërisë lejon disa sesione njëkohësisht, që është e kundërta e një kufizimi. Asnjëra prej gjendjeve nuk është politikë refuzimi, prandaj vendimi duhet të merret diku tjetër.
Shkruani kontratën përpara se të zbatoni çdo gjë: kush refuzohet, çfarë prove identifikon sesionin që po punon dhe çfarë ndodh kur një sesion vdes pa një shkëputje të pastër. Një politikë që askush nuk e ka formuluar kështu nuk mund të testohet më vonë.
Dëbimi ndodh përpara grepit tuaj të lidhjes
Në rrugën e kodit të serverit 2.6, përgatitja e hershme për një klient të re heq shembujt ekzistues me të njëjtin emër kur njëkohshmëria është e çaktivizuar. Ai heqje ndodh përpara se të ekzekutohet zinxhiri i trajtuesve të lidhjes. Prandaj një skript që vëren dublikatën dhe kthen dështim e refuzon të renë pasi sesioni që po punon është hedhur tashmë poshtë - pikërisht rezultati që politika duhej të parandalonte. Radha e thirrjeve të kthimit në zbatimin upstream është përgjigjja e vetme e besueshme për ndërtimin tuaj.
| 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 |
Anketimi i skedarit të gjendjes nuk është as portë. Dy përpjekje që vijnë bashkë mund ta shohin të dyja një slot bosh përpara se ndonjëra ta konfirmojë, dhe të dyja vazhdojnë.
Zhvendosni vendimin në vërtetim
Ndërfaqja e administrimit mund të marrë përsipër vendimin e vërtetimit pas verifikimit të certifikatës. Në këtë rregullim kontrolluesi nuk është vëzhgues: ai pranon çdo shembull klienti që lidhet dhe përgjigjet nëse ai shembull mund të vazhdojë. Meqenëse përgjigjja vjen përpara vendosjes, një refuzim e lë sesionin që po punon të paprekur. I njëjti kanal raporton shkëputjet, dhe kështu kontrolluesi mëson se një slot u lirua në mënyrë legjitime.
Çdo shembull i re duhet të kalojë nëpër këtë portë, përfshirë rilidhjet dhe çdo rrugë që rivërteton pa kërkesë. Një portë të cilën disa shembuj nuk e arrijnë kurrë nuk mbron asgjë, dhe ky lëshim mbetet i padukshëm derisa dikush të provojë anashkalimin.
Tokenët mund të kalojnë pranë portës
Pasi një token lëshohet, serveri mund ta vërtetojë atë brenda dhe të anashkalojë vërtetimin e jashtëm për atë lidhje. Thirrja e administrimit nuk ndodh kurrë, kështu që një kontroll sloti i zbatuar vetëm atje nuk e sheh kurrë shembullin e re. Ky sjellje është komoditet për përdoruesit dhe vrimë për një politikë njëkohshmërie. Bëni që lidhjet e vërtetuara me token të kalojnë një kontroll autoritativ ekuivalent, ose çaktivizoni rrugën e tokenit kur politika kërkon një vendim për çdo lidhje.
Mos e kompensoni duke pranuar çdo token pa kushte. Një token i skaduar ose i pavlefshëm duhet të dështojë gjithsesi, dhe duhet të dështojë përmes të njëjtës pikë vendimi si gjithçka tjetër.
Lidhni rezervimin me një shembull, jo me një adresë
Një adresë është identitet i dobët: një rilidhje nga i njëjti laptop mund të vijë nga një adresë tjetër, dhe një kredencial i kopjuar mund të vijë nga e njëjta adresë. Lidhni rezervimin me shembullin e klientit që cakton serveri, kështu që një rivërtetim i shembullit të pranuar tashmë njihet si pronar. Një identifikues i re shembulli duhet të fitojë slotin e vet përmes vendimit i pari fiton, edhe kur paraqet të njëjtin token.
Lëshoni vetëm rezervimin që i përket përpjekjes së dështuar. Një ngjarje e vonuar shkëputjeje nga një përpjekje më e vjetër nuk duhet të fshijë slotin e një pronari më të re, prandaj lëshimi emërton shembullin dhe jo llogarinë. Pas rinisjes së kontrolluesit, rakordoni sesionet e gjalla përpara se të pranoni dikë, dhe zbatoni të njëjtin rregull në çdo portë që shërben llogarinë.
Vendosni veçmas se si rikuperohet një slot vërtet i vjetruar. Administratorit i duhet një mënyrë e dokumentuar për ta pastruar, dhe ajo rrugë nuk duhet të jetë e arritshme për një përdorues që thjesht klikon rilidhu.
Testoni çiftet që kanë rëndësi: dy hyrje pothuajse njëkohësisht, një rilidhje pas një mbylljeje të pastër, një rivërtetim i sesionit që po punon, një i re i refuzuar dhe një rinisje e kontrolluesit. Në çdo rast sesioni që po punon duhet të mbetet i përdorshëm dhe i reja duhet të refuzohet pa dëme anësore për llogaritë e tjera.