Isang VPN account sa dalawang server: tatlong ledger ng estado

Ang isang account na makakapasok sa alinman sa dalawang VPN node ay naglalabas ng tanong sa disenyo bago pa maging tanong sa software. Ang pananaw ng account, ang network na pagmamay-ari ng bawat node at ang sesyong hawak ng konektadong kliyente ay tatlong magkakaibang uri ng estado, at nabibigo ang mga ito sa magkakaibang paraan kapag kinokopya mo sila. Ang pagkopya ng tatlo sa isang sistema ay karaniwang paraan ng pagkawala ng isa sa kanila.

Daanan ang tatlong ledger sa ibaba nang sunud-sunod. Bawat isa ay nagtatanong kung ano ang may awtoridad, ano ang lokal, at ano ang nangyayari kapag wala ang kabilang node, at ang mga sagot ay hindi nagmumula sa isa’t isa.

Sino ang makakakonekta: isang awtoridad, maraming node

Magsimula sa ledger ng pagtanggap: aling pinagmulan ng pagkakakilanlan ang may awtoridad, aling mga tagapagbigay ng sertipiko ang pinagkakatiwalaan, aling mga account ang karapat-dapat, aling pangalawang salik ang nalalapat, at ano ang maaabot ng bawat account. Pagkatapos isulat kung paano nalalaman ng bawat node ang mga pagbabago, at gaano kabilis.

Ang pinagsasaluhang database ay isang posibleng bahagi ng sagot na iyon. Hindi ito patunay na ang bawat kaugnay na patakaran ay naninirahan doon, o na inilalapat ng bawat node ang pagbabago sa parehong sandali. Ang account na hindi pinagana sa node A ngunit tinatanggap pa rin sa node B ay nangangahulugang hindi pa tapos ang proseso ng pag-alis.

Magpasya kung ano ang gagawin ng node kapag hindi maabot ang awtoridad. Ang pagtanggap ng naka-cache na kredensyal habang may pagkawala ay pagpiling patakaran na may gastos sa seguridad, at ang pagtanggi sa mga ito ay pagpiling patakaran na may gastos sa pagiging magagamit. Pareho silang maipagtatanggol; ang iwanan itong walang dokumento ay hindi.

Panatilihing hiwalay ang awtoridad ng tagapagbigay sa datos ng account. Maraming gateway ang maaaring magtiwala sa parehong CA nang hindi hawak ang susi ng lagda nito, at kailangan pa rin ng bawat node ang sarili nitong sertipiko ng server at sarili nitong ugnayan ng pagtitiwala sa panig ng kliyente.

Ano ang pagmamay-ari ng node: mga address at ruta

Ang ikalawang ledger ay lokal sa bawat node: address ng pakikinig, pagkakakilanlan ng server, pool ng address, mga ruta patungo sa pribadong yaman, patakaran ng resolver at kung paano lumalabas ang trapiko patungo sa internet. Ang parehong account ay maaaring pagsilbihan ng alinman sa dalawang node habang nananatiling magkaiba ang mga bagay na ito.

Ang daan pabalik ang bahaging nakakalimutan. Kung ang dalawang node ay namimigay ng address mula sa parehong pool, hindi matukoy ng pribadong network kung kaninong node ang isang kliyente, at ang sagot ay maaaring mapunta sa maling lugar. Ang magkaibang pool ay nangangailangan din ng mga ruta at pahintulot, kaya ang magkaibang saklaw ng numero ay hindi kumpletong disenyo.

Ituro ang mga kliyente sa isang node nang sadya. Ang pagpili ng DNS, mga listahan ng endpoint ng kliyente at isang serbisyong front-end ay magkaibang mekanismo na may magkaibang pag-uugali sa kalusugan at paglipat kapag nabigo. Ang pumili ng isa ay maayos; ang ituring ang «pagbabalanse ng karga» bilang disenyo ay nag-iiwan sa daan pabalik at pag-uugali kapag nabigo na hindi natukoy.

Nakakatulong dito ang isang dokumentadong halimbawa ng produkto. Tinatrato ng dokumentasyon ng replikasyon ng Pritunl ang VPN network bilang bagay sa bawat replika, at ang mga kliyente sa magkaibang replika ay nangangailangan ng karagdagang ruta at konektibidad upang maabot ang isa’t isa. Iyon ay kaayusang partikular sa produkto, hindi resipi para sa Community OpenVPN, ngunit ipinapakita nito kung bakit binabago ng pagdagdag ng replika ang network at hindi lamang ang imbakan ng account.

Ano ang sesyon: buhay na estado, hindi isang hilera

Ang ikatlong ledger ay ang buhay na sesyon. Ang konektadong kliyente ay may estado ng protocol at pagtatalaga ng network sa node na tumanggap sa kanya. Ang pagiging kilala ng account sa kabilang node ay hindi nagbibigay sa node na iyon ng sesyon, mga susi o kakayahang ipagpatuloy ang mga packet.

Maging tahasan kung ano ang nangyayari kapag nabigo ang isang node. Ang sinusuportahang resulta ay maaaring muling pagkonekta sa kabilang node na may bagong pagpapatunay at bagong address, pagkatapos ay gumagaling ang aplikasyon sa sarili nitong paraan. Kung kailangan ang tuloy-tuloy na paglilipat, ang pangangailangang iyon ay nangangailangan ng tahasang suporta sa implementasyon, hindi hinuha mula sa replikasyon ng database. Isulat ang sagot kung saan ito makikita ng naka-duty na inhinyero.

Ang mga tuntunin ng kapasidad ay nangangailangan ng parehong pagtrato. Ang limitasyon ng dalawang sabay na sesyon sa bawat account ay maipapatupad lamang sa mga node kung may awtoridad na may magkakaugnay na pananaw sa mga okupadong puwesto. Ang mga listahang lokal sa node at makasaysayang talaan ng account ay hindi nagsasama-sama tungo sa pananaw na iyon.

Pagsubok sa tatlong ledger

Sanayin ang bawat isa nang hiwalay. Pumasok sa pamamagitan ng node A, pagkatapos sa node B, at tiyakin na parehong nagtagumpay ang mga ito sa inaasahang saklaw ng address. Bawiin ang isang pagkakakilanlan at suriin ang dalawang node, hindi lamang ang sinubukan mo nang nagkataon. Pagkatapos ihinto ang isang node at obserbahan kung ano talaga ang ginagawa ng kliyente at ng pribadong aplikasyon.

Isama ang daan pabalik sa pagsubok ng pagtanggap. Ang kliyenteng kumokonekta sa B ngunit hindi makatanggap ng mga sagot mula sa yaman sa likod ng A ay nakapasa sa pagsusuri ng pagtanggap at nabigo sa pagsusuri ng network, at ang pagkakaibang iyon ay dapat lumitaw sa ulat.

Ang disenyo ng account na may maraming node ay kumpleto lamang kapag ang tatlong ledger ay may tahasang may-ari, daan ng pagbabago at pag-uugali kapag nabigo. Ang pagkopya ng file ng pagsasaayos sa mga node ay hindi sumasagot sa alinman sa mga tanong na iyon.