Unu VPN-konto trans du serviloj: tri stataj libroj

Unu konto, kiu povas ensaluti en iun ajn el du VPN-nodoj, starigas projektan demandon longe antaŭ ol ĝi starigas softvaran demandon. La konta vido, la reto, kiun posedas ĉiu nodo, kaj la sesio, kiun tenas konektita kliento, estas tri malsamaj specoj de stato, kaj ili fiaskas malsame, kiam vi kopias ilin ĉirkaŭen. Kopii ĉiujn tri en unu sistemon estas ofta maniero perdi unu el ili.

Trairu la tri librojn sube laŭ ordo. Ĉiu demandas, kio estas aŭtoritata, kio estas loka, kaj kio okazas, kiam la alia nodo forestas, kaj la respondoj ne sekvas unu el la alia.

Kiu rajtas konektiĝi: unu aŭtoritato, multaj nodoj

Komencu per la akcepta libro: kiu identfonto estas aŭtoritata, kiuj certifikat-eldonantoj estas fidataj, kiuj kontoj estas elekteblaj, kiu dua faktoro validas, kaj kion ĉiu konto povas atingi. Poste skribu, kiel ĉiu nodo ekscias pri ŝanĝoj, kaj kiom rapide.

Komuna datumbazo estas unu ebla komponento de tiu respondo. Ĝi ne pruvas, ke ĉiu koncerna politiko loĝas tie, nek ke ĉiu nodo aplikas ŝanĝon sammomente. Konto malŝaltita ĉe nodo A sed ankoraŭ akceptita ĉe nodo B signifas, ke la eliĝa procezo ne finiĝis.

Decidu, kion faras nodo, kiam la aŭtoritato neatingeblas. Akcepti kaŝmemorajn legitimilojn dum paneo estas politik-elekto kun sekureca kosto, kaj malakcepti ilin estas politik-elekto kun disponebla-kosto. Ambaŭ estas defendeblaj; lasi tion nedokumentita ne estas.

Tenu la eldonantan aŭtoritaton aparte de la kontaj datumoj. Pluraj pordegoj povas fidi la saman CA sen teni ĝian subskriban ŝlosilon, kaj ĉiu nodo ankoraŭ bezonas sian propran servilan atestilon kaj sian propran fido-rilaton ĉe la klienta flanko.

Kion posedas nodo: adresoj kaj itineroj

La dua libro estas loka por ĉiu nodo: aŭskulta adreso, servila identeco, adresa baseno, itineroj al privataj rimedoj, solva politiko, kaj kiel la trafiko eliras al la interreto. La sama konto povas esti servata de iu ajn nodo, dum ĉi tiuj objektoj restas apartaj.

La revena vojo estas la parto, kiu estas forgesata. Se ambaŭ nodoj disdonas adresojn el la sama baseno, la privata reto ne povas distingi, al kiu nodo apartenas donita kliento, kaj la respondo povas esti sendita al la malĝusta loko. Malsamaj basenoj ankaŭ bezonas itinerojn kaj permesojn, do aparta numero-intervalo ne estas kompleta projekto.

Direktu klientojn al nodo intence. DNS-elekto, klientaj finpunkto-listoj kaj fronta servo estas malsamaj mekanismoj kun malsama konduto pri sano kaj malsukcesa transiro. Elekti unu estas bone; trakti «ŝarĝan ekvilibradon» kiel la projekton lasas la revenan vojon kaj la fiasko-konduton nedifinitaj.

Dokumentita produkta ekzemplo helpas ĉi tie. La replika dokumentaro de Pritunl traktas la VPN-reton kiel objekton por ĉiu repliko, kaj klientoj sur malsamaj replikoj bezonas kromajn itinerojn kaj konekteblecon por atingi unu la alian. Tio estas produkto-specifa aranĝo, ne recepto por Community OpenVPN, sed ĝi montras, kial aldoni replikon ŝanĝas la reton kaj ne nur la kontan konservejon.

Kio estas sesio: viva stato, ne vico

La tria libro estas la viva sesio. Konektita kliento havas protokolan staton kaj retan asignon ĉe la nodo, kiu akceptis ĝin. Tio, ke la konto estas konata ĉe la alia nodo, ne donas al tiu nodo la sesion, la ŝlosilojn aŭ la kapablon daŭrigi la pakaĵojn.

Estu eksplicita pri tio, kio okazas, kiam nodo paneas. La subtenata rezulto povas esti rekonekto al la alia nodo kun freŝa aŭtentikigo kaj nova adreso, post kio la aplikaĵo resaniĝas laŭ sia propra maniero. Se seninterrompa transdono estas postulata, tiu postulo bezonas eksplicitan realigan subtenon, ne konkludon el datumbaza replikado. Skribu la respondon tie, kie la deĵora inĝeniero povas trovi ĝin.

Kapacitaj reguloj bezonas la saman traktadon. Limo de du samtempaj sesioj por konto povas esti devigata trans nodoj nur se iu aŭtoritato havas kunordigitan vidon de okupataj lokoj. Nodelokaj listoj kaj historia konta registro ne sumiĝas al tiu vido.

Provi la tri librojn

Ekzercu ĉiun aparte. Ensalutu tra nodo A, poste tra nodo B, kaj konfirmu, ke ambaŭ sukcesas kun la atenditaj adresintervaloj. Retiru identecon kaj kontrolu ambaŭ nodojn, ne nur tiun, kiun vi hazarde testis. Poste haltigu unu nodon kaj observu, kion la kliento kaj la privata aplikaĵo efektive faras.

Inkluzivu la revenan vojon en la akcepta testo. Kliento, kiu konektiĝas al B sed ne povas ricevi respondojn de rimedo malantaŭ A, trapasis la akceptan kontrolon kaj malsukcesis la retan, kaj tiu distingo devus aperi en la raporto.

Nur kiam ĉiuj tri libroj havas eksplicitan posedanton, ŝanĝvojon kaj fiasko-konduton, la multnoda konta projekto estas kompleta. Kopii agordan dosieron trans nodoj respondas neniun el tiuj demandoj.