Nanalo ang unang sesyon: pagpigil sa mga pag-login ng OpenVPN bago ang pagpapaalis
Ang pagtanggi sa susunod na pag-login ay hindi katulad ng pagpapalit sa luma. Dapat mauna ang desisyon bago ang pagpapaalis ng parehong pangalan, at ang pagsusuri ng slot ay dapat atomiko.
Ang patakarang nagpapahintulot ng isang sesyon kada account ay tila tapos na hanggang dumating ang ikalawang pag-login. Dalawang kinalabasan ang posible: pinapalitan ng bagong dating ang kasalukuyang sesyon, o pinapanatili ng kasalukuyang sesyon ang slot at tinatanggihan ang bagong dating. Ang pangalawa lamang ang patakarang nananalo ang unang sesyon. Ang opsyong kliyente na pinipili ng karamihan ay nagpapagana ng sabayang pagpasok at kaya hindi ito nagbubunga.
Dalawang kontrata ang nagtatago sa likod ng isang setting
Kapag patay ang sabayang pagpasok, ang ikalawang koneksyong may parehong pangalan ng sertipiko ay maaaring mag-alis sa sesyong tumatakbo na. Ang pagpapagana nito ay nagpapahintulot ng maraming sesyon nang sabay, na kabaligtaran ng limitasyon. Wala sa dalawang estado ang patakaran ng pagtanggi, kaya dapat kunin ang desisyon sa ibang lugar.
Isulat ang kontrata bago magpatupad ng kahit ano: sino ang tinatanggihan, anong ebidensya ang kumikilala sa kasalukuyang sesyon, at ano ang nangyayari kapag namatay ang sesyon nang walang malinis na paghihiwalay. Ang patakarang walang nagpahayag sa ganitong paraan ay hindi masusubok mamaya.
Nauuna ang pagpapaalis bago ang iyong connect hook
Sa landas ng code ng server 2.6, inaalis ng maagang paghahanda para sa bagong kliyente ang mga umiiral na instance na may parehong pangalan kapag patay ang sabayang pagpasok. Nangyayari ang pag-alis na iyon bago tumakbo ang hanay ng mga tagahawak ng koneksyon. Kaya ang script na makakita ng duplicate at magbabalik ng kabiguan ay tinatanggihan ang bagong dating pagkatapos nang itapon ang kasalukuyang sesyon - eksaktong kinalabasang dapat pigilan ng patakaran. Ang pagkakasunod-sunod ng mga callback sa implementasyong upstream ang tanging maaasahang sagot para sa iyong 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 |
Ang pag-poll sa file ng estado ay hindi rin tarangkahan. Dalawang pagtatangkang sabay na dumarating ay maaaring parehong makakita ng bakanteng slot bago pa kumpirmahin ng isa, at parehong tumutuloy.
Ilipat ang desisyon sa pagpapatotoo
Maaaring akuin ng interface ng pamamahala ang desisyon sa pagpapatotoo pagkatapos ng beripikasyon ng sertipiko. Sa kaayusang iyon ang controller ay hindi tagamasid: tinatanggap nito ang bawat instance ng kliyenteng kumokonekta at sinasagot kung maaaring tumuloy ang instance na iyon. Dahil dumarating ang sagot bago ang pagtatatag, hinahayaan ng pagtanggi na hindi magalaw ang kasalukuyang sesyon. Ang parehong channel ay nag-uulat ng mga paghihiwalay, at sa gayon nalalaman ng controller na lehitimong napalaya ang isang slot.
Kailangang dumaan ng bawat bagong instance sa tarangkahang iyon, kasama ang mga muling pagkonekta at anumang landas na muling nagpapatotoo nang walang tanong. Ang tarangkahang hindi naaabot ng ilang instance ay walang pinoprotektahan, at nananatiling di-nakikita ang pagkaligta hanggang may sumubok sa daan-libot.
Maaaring dumaan ang mga token sa tabi ng tarangkahan
Kapag naisyu na ang isang token, maaaring patunayan ito ng server sa loob at laktawan ang panlabas na pagpapatotoo para sa koneksyong iyon. Hindi kailanman nangyayari ang tawag sa pamamahala, kaya ang pagsusuri ng slot na ipinatupad doon lamang ay hindi kailanman nakikita ang bagong instance. Ang pag-uugaling iyon ay kaginhawahan para sa mga gumagamit at butas para sa patakaran ng sabayang pagpasok. Padaluyin ang mga koneksyong pinatotohanan ng token sa katumbas na awtoridad na pagsusuri, o patayin ang landas ng token kapag hinihingi ng patakaran ang desisyon sa bawat koneksyon.
Huwag itong bawiin sa pamamagitan ng walang kondisyong pagtanggap sa bawat token. Ang token na nag-expire o di-wasto ay kailangan pa ring mabigo, at kailangan itong mabigo sa parehong punto ng desisyon gaya ng lahat ng iba.
Itali ang reserbasyon sa isang instance, hindi sa isang address
Mahinang pagkakakilanlan ang address: ang muling pagkonekta mula sa parehong laptop ay maaaring magmula sa ibang address, at ang kinopyang kredensyal ay maaaring magmula sa parehong address. Itali ang reserbasyon sa instance ng kliyenteng itinatalaga ng server, upang ang muling pagpapatotoo ng instance na tinanggap na ay makilala bilang may-ari. Ang bagong identifier ng instance ay kailangang makakuha ng sariling slot sa pamamagitan ng desisyong una ang nananalo, kahit na ipinapakita nito ang parehong token.
Palayain lamang ang reserbasyong kabilang sa bigong pagtatangka. Ang naantalang kaganapan ng paghihiwalay mula sa mas lumang pagtatangka ay hindi dapat magbura ng slot ng mas bagong may-ari, kaya pinapangalanan ng pagpapalaya ang instance at hindi ang account. Pagkatapos ng restart ng controller, itugma ang mga buhay na sesyon bago tumanggap ng kahit sino, at ilapat ang parehong tuntunin sa bawat gateway na naglilingkod sa account.
Magpasya nang hiwalay kung paano nababawi ang talagang lipas nang slot. Kailangan ng administrador ng dokumentadong paraan upang linisin ito, at ang landas na iyon ay hindi dapat maabot ng gumagamit na pumipindot lang ng kumonekta muli.
Subukan ang mga pares na mahalaga: dalawang halos sabay na pag-login, muling pagkonekta pagkatapos ng malinis na pagtatapos, muling pagpapatotoo ng kasalukuyang sesyon, tinanggihang bagong dating, at restart ng controller. Sa bawat kaso ang kasalukuyang sesyon ay dapat manatiling magagamit at ang bagong dating ay dapat tanggihan nang walang pinsala sa ibang account.