Unu serva adreso sur ĉiu OpenVPN-nodo: kion ĝi ne faras
Rezervu privatan /32 sur ĉiu nodo, por ke kliento atingas la servilon, kiun ĝi elektis. La adreso ne faras malsukcesotransiron, ne movas seancojn kaj ne elektas sanan nodon.
Kliento konektiĝas al unu el pluraj OpenVPN-serviloj kaj poste bezonas malgrandan servon, kiu ruliĝas sur tiu nodo: statpaĝo, metrika finpunkto, sekurkopia agento. Doni al ĉiu nodo la saman privatan servan adreson igas la agordon de la kliento identa sendepende de tio, sur kiun servilon ĝi surteriĝis. Tiu komforto estas reala, kaj same facile trolegebla: la komuna adreso diras al vi, kiun nodon vi atingis, ne ke io estas redunda.
Kial la sama adreso sur ĉiu nodo funkcias
Ĉiu nodo posedas la adreson loke kaj respondas por ĝi, do kliento, kiu atingas ĝin tra sia nuna tunelo, ricevas la servon ĉe la malproksima fino de tiu tunelo. Nenio estas kunordigata inter nodoj, kaj neniu trafiko transiras de unu nodo al alia.
La adreso estas loka etikedo, ripetita anstataŭ replikita. Ĉiu nodo respondas nur por si mem, kaj neniu el ili plusendas trafikon por la adreso nome de alia nodo. Tio tenas unu klientan agordon valida dum la serviloj restas sendependaj. Ĝi ankaŭ estas kial la dezajno bezonas neniun kunordigon inter la nodoj.
Tial la sama agordo funkcias sur ĉiu servilo sen enkursiga protokolo inter ili. Ĝi ankaŭ estas kial la dezajno diras nenion pri sano: la adreso ekzistas sur malsana nodo same kiel sur sana, ĉar ĝi estas ligita al la gastiganto, ne al tio, ke la servo estas utila.
Administru ĝin al la bukla interfaco, ne al la tunelo
Meti la adreson sur buklan interfacon malkunligas ĝin de la vivdaŭro de ajna tunela aparato, do rekonekto aŭ reŝargo de agordo ne forigas ĝin. La adreso ekzistas tiel longe, kiel la gastiganto.
Adreso sur lo ne estas filtrilo. La servo ankoraŭ devas aŭskulti sur ĝi, kaj la fajroŝirmilo de la gastiganto ankoraŭ taksas la realan envenan vojon, kiu alvenas sur la tunela interfaco. Ĉiu, kiu supozas, ke buklo signifas nur-lokan, finiĝas aŭ blokante legitimajn klientojn aŭ elmontrante ion, kion ĝi ne intencis.
Daŭrigu la administradon per la reta agordo de la gastiganto anstataŭ re-aldoni ĝin el hoko. Agorda hoko ne ekfunkcios sur nodo, kie neniu tunelo leviĝis, kaj la serva adreso ne devus dependi de tunela agado. Metu la adreson en la interfacan agordon, kiun posedas via distribuo, poste restartigu unufoje kaj kontrolu ĝin. Restartigo estas la sola testo, kiu postvivas postan agordan ŝanĝon.
ip address show dev lo | grep 10.250.0.1
ip address add 10.250.0.1/32 dev loPuŝu unu itineron kaj celas unu cellokon
La kliento bezonas gastigantan itineron por la adreso, ofertitan de la servilo, al kiu ĝi konektiĝas. Ĉar ĉiu servilo ofertas la saman cellokon, la profilo ne ŝanĝiĝas, kiam la kliento moviĝas.
Kontrolu, kion la kliento instalas, antaŭ ol kulpigi la servon.
ip route get 10.250.0.1Por HTTP-servo, donu al la adreso nomon kaj atestilon por tiu nomo. La komuna IP ne estas identeco, kaj ĝi ne forigas TLS-kontrolon, nek pravigas kopii unu privatan ŝlosilon al ĉiu nodo. Nomo, kiu solviĝas al la komuna adreso, tenas la atestilan historion ordinara kaj lasas al vi identecon po nodo, se vi bezonas unu.
Kion la komuna adreso ne povas fari
Ĝi ne provizas malsukcesotransiron. Se la elektita nodo mortas, la adreso mortas kun ĝi, kaj la kliento devas rekonektiĝi aliloke.
Ĝi ne migras vivan TCP-seancon, ĉar nova konekto finiĝas sur alia gastiganto sen scio pri la malnova.
Ĝi ne elektas sanan nodon, ne ekvilibrigas ŝargon kaj ne sinkronigas datumojn inter nodoj. Ĉiu el tiuj estas aparta mekanismo kun propraj fiaskmanieroj, kaj ŝajnigi, ke la adres-truko kovras ilin, estas kiel simpla dezajno akiras senmeritan reputacion de rezistemo. Se du tuneloj estas aktivaj samtempe, la signifo de la celloko fariĝas ambigua, do tenu eksplicita la supozon de unu aktiva tunelo.
Tenu la servan identecon kun la nomo
Skribu, kion la adreso signifas: ĝi atingas la servon sur la nodo, al kiu la kliento nun estas konektita. Tiu unu frazo malhelpas la plejparton de la miskompreno, kiun tiu ĉi ŝablono allogas.
Poste dokumentu la partojn kune: la adreson, la interfacon, sur kiu ĝi vivas, la itineron, kiun la servilo puŝas, kaj la nomon kaj atestilon, kiujn la servo prezentas. Kvar malgrandaj faktoj, kiujn estonta leganto povas kontroli, en la ordo, en kiu ĝi kontrolos ilin.
Se la postulo estas stabila celloko por noda loka servo, la ŝablono taŭgas kaj kostas preskaŭ nenion.
Se la postulo estas havebleco, iru unu tavolon supren: ŝarĝegaligilo, serva nomo kun sankontroloj, aŭ orkestra sistemo, kiu jam scias, kiel anstataŭigi nodon.
Decidi tion frue tenas la komunan adreson tio, kio ĝi estas, oportuna etikedo, anstataŭ komponanto, de kiu oni silente atendas laboron, por kiu ĝi neniam estis desegnita.