Ŝanĝi provizanton sen renumeri la VPN-adresojn de la retejo
Enkursigita loka VPN konservas privatajn adresojn kiam la suprena ligo ŝanĝiĝas, sed la adreso de la kunulo, la identeco kaj la revena vojo ankoraŭ postulas laboron. Jen la disigo.
Filio ŝanĝas interretan provizanton, kaj la dosieroservilo konservas sian adreson. Tiu rezulto estas normala en enkursigita loka VPN kaj surpriza por ĉiu, kiu supozas, ke la finpunkta adreso de la tunelo estas la adreso de la aplikaĵo. La du vivas en malsamaj tavoloj de la desegno, kaj nur unu moviĝis. Trakti ilin kiel unu estas la maniero, kiel provizanta migrado fariĝas renumerada projekto.
Du adresplanoj, kiuj moviĝas sendepende
La interna plano priskribas la privatajn adresojn, kiujn uzas la aplikaĵoj: la filia servilo ĉe 10.55.8.20, la prefikso de la ĉefsidejo, kiu enkursigas al ĝi, kaj la revena vojo. La ekstera plano priskribas, kiel du pordegoj atingas unu la alian: kunulaj adresoj, aŭskultaj pordoj kaj la vojo tra la interreto.
Provizanta ŝanĝo tuŝas la eksteran planon. Ĝi mem ne postulas, ke la interna plano ŝanĝiĝu.
Teni la du inventarojn aparte estas la praktika kialo uzi supertavolon eĉ kiam la aplikaĵo jam ĉifras sian propran trafikon. La supertavolo donas al vi stabilan internan topologion, kiu postvivas eksteran ŝanĝiĝon. La aplikaĵo konservas sian adreson, siajn fajroŝirmilajn regulojn kaj siajn DNS-rikordojn. Nur la transportaj rikordoj ŝanĝiĝas, kaj tio estas multe pli malgranda revizio.
La ekstera tunelo portas la internan interparolon
En pordego-al-pordego-tunelo, la ekstera IP-kapo adresas la du pordegojn. La interna kapo ankoraŭ nomas la efektivajn finpunktojn de la aplikaĵo. La priskribo pordego-al-pordego en RFC 7296 traktas tion kiel ordinaran enkursigadon, kiu liveras trafikon tra la finpunktoj de la tunelo.
Tial la filia servilo povas konservi 10.55.8.20 dum la publika adreso de la pordego ŝanĝiĝas. La interna paketo tute ne enhavas la adreson de la provizanto.
La disigo estas eco de la desegno, ne aŭtomata garantio. Se la anstataŭa suprena ligo ne povas starigi la subtenatan tunelon, aŭ se la internaj vojoj ne estas reinstalitaj, la aplikaĵo perdas sian vojon eĉ se ĝia adreso restas sama.
La provizanta translokiĝo ankoraŭ havas kontrolan liston
La ekstera kontrol listo havas kvin erojn: la kunula adreso aŭ la prizorgata nomo, la aŭskultanto kaj iu ajn filtrilo supre, la traduko sur la vojo, la atendata kunula identeco kaj la permesataj agordoj de la alia pordego. Ĉiu povas malsukcesi per si mem. Tenu apartan savan vojon dum vi ŝanĝas la ligon, kiu portas administradon. Tranĉi la telealiron dum transiro al nova suprena ligo estas paneo, kiun vi mem kaŭzis.
Post tio, kontrolu la filian prefikson, la vojon en ambaŭ direktojn, la protektan politikon kaj unu realan aplikaĵan fluon. Ĵus aŭtentigita tunelo ne riparas vojon, kiu montras al la malnova privata subreto.
Adresa interkovro kun alia konektita loko estas aparta planada problemo. La provizanta ŝanĝo ne kreas ĝin, sed migrado estas kutime la momento, kiam ĝi montriĝas.
Kio ne postvivas: publika fonto kaj seancoj
Stabila privata servila adreso ne estas stabila publika fonto. Se retumado eliras rekte tra la nova provizanto, retejoj vidas la novan adreson turnitan al la provizanto.
Teni tiun adreson stabila postulas pripensitan eliran desegnon kun propra havebleco kaj politiko. Ĝi ne venas senpage kun la tunelo.
Ankaŭ establitaj seancoj ne postvivas vojan ŝanĝon. La tunelo povas restarigi sin en sekundoj kaj tamen rompi longdaŭrajn konektojn ligitajn al la malnova vojo. Planu la transiron por fenestro, en kiu rekonektoj estas akcepteblaj. Ne asertu, ke migrado estos nevidebla, se la konkretaj klientoj kaj iliaj tempolimoj ne estis testitaj.
Kontrolu la translokiĝon per kvar kontroloj
Post la ŝanĝo, kontrolu kvar aferojn laŭ ordo: la tunelo estas starigita kun la celita kunulo, la interna vojo al la filia prefikso ekzistas, la politiko permesas la aplikaĵan fluon kaj la aplikaĵo respondas. Ĉiu havas sian propran komandon.
Ĉe Linux-pordego, ĉi tiuj tri kovras la mezon de tiu listo:
ip route get 10.55.8.20
ip xfrm policy list
curl -sS -o /dev/null -w "%{http_code}" --max-time 8 http://10.55.8.20/healthTenu transportajn adresojn en unu inventaro kaj aplikaĵajn adresojn en alia. Ĝisdatigu nur la rikordojn, kiuj efektive moviĝis. Renumeri internajn dependecojn ĉar la ekstera adreso de la tunelo ŝanĝiĝis estas evitebla laboro.