Nova enkursigilo, sama VPN-servilo: translokigu ĝian publikan enirejon
La VPN-servilo restas en la LAN, do ŝanĝo de enkursigilo estas du transdonaĵoj: la vojo al ĝi kaj la publika enirejo, kiun klientoj konservis. Transdonu ambaŭ, poste testu de ekstere.
Vi konektas la novan enkursigilon, la interreto revenas, kaj la VPN-kliento sur via telefono ankoraŭ montras al adreso, kiu ne plu respondas. Nenio sur la VPN-servilo ŝanĝiĝis, ĉar la servilo neniam moviĝis. La enkursigilo estis la publika enirejo, kaj anstataŭigi ĝin anstataŭigis la adreson, la plusendan regulon kaj eble la ĝisdatigilon de dinamika DNS samtempe.
Traktu la ŝanĝon kiel du transdonaĵojn, ne unu, kaj konservu lokan vojon en la administran interfacon dum vi laboras.
Skribu la transdonon antaŭ ol malŝtopi
Notu la LAN-prefikson, la servilan adreson kaj kiel ĝi estas atribuata, la aŭskultanton kaj la transporton, kiujn la VPN fakte uzas, la envenan regulon, kiu publikigas ĝin, kaj la nomon, kiun klientoj konservis. Poste notu, kiu maŝino hodiaŭ ĝisdatigas la dinamikan DNS-rikordon: povas esti la enkursigilo, la servilo mem aŭ aparta agento sur alia gastiganto. Faru tion dum la malnovaj administraj paĝoj ankoraŭ ŝarĝiĝas. Ekrankopio de la envena regulo valoras pli ol memorata pordnumero.
Aldonu la privatajn prefiksojn, kiujn klientoj devas atingi, kaj kiel aparatoj en la LAN sendas respondojn reen al ili. Ambaŭ facile forgesiĝas, ĉar la anstataŭiga asistanto parolas pri interreta aliro, ne pri reiroj. Ankaŭ eksportu la malnovan agordon, se la vendinto subtenas ĝian restarigon, akceptante, ke savkopio de unu modelo malofte enportiĝas pure en alian.
Konservu tiun rikordon en protektita loko. Savkopio de enkursigilo povas enhavi akreditaĵojn por la WAN-ligilo. Traktu la eksportan dosieron kiel pasvorton, ne kiel noton pri agordoj.
Unue translokigu la adreson, poste la plusendadon
Se la nova enkursigilo konservas la saman LAN-prefikson, donu al la servilo la rezervon, kiun ĝi havis, aŭ egalvaloran statikan atribuon. Se la prefikso ŝanĝiĝas, unue ĝisdatigu la servilan adreson kaj ĉiun aŭskultantan ligon, kiu nomas ĝin, ĉar plusendado al la malnova adreso silente sendos trafikon nien.
Poste kredu precize unu envenan regulon por la transporto, kiun la VPN uzas. La gvidiloj de fabrikantoj, kiuj priskribas plusendadon al loka servilo, montras la mekanismon, ne universalan recepton, do mapu la regulon al via reala protokolo kaj pordo, ne al listo el blogo. Plusendado sur la nova enkursigilo ne povas forigi NAT je la nivelo de la provizanto, kiu staras super ĝi, kaj neniu loka regulo igos privatan adreson atingebla el la interreto, se la provizanto jam kunhavas unu kun vi.
Konfirmu, ke la propra fajroŝirmilo de la servilo ankoraŭ permesas tiun trafikon. Kontrolu, ĉu dua kluzo staras inter la enkursigilo kaj la interreto, ĉar multaj provizantoj liveras kombinatan modemojn kaj enkursigilojn. Legu la WAN-adreson sur la nova aparato kaj komparu ĝin kun la adreso, kiun klientoj solvas. Se ili diferencas, via plusendado surteriĝas sur io, kio ne estas la rando.
Decidu, kiu ĝisdatigas la publikan nomon
Ĝisdatigoj de la finpunkto bezonas unu posedanton kaj nur unu. Se la malnova enkursigilo publikigis la nomon, agordu subtenatan ĝisdatigilon sur la anstataŭaĵo kaj konfirmu, ke la rikordo vere ŝanĝiĝis. Se la servilo jam publikigis ĝin, lasu tiun aranĝon trankvila anstataŭ aldoni konkurencan ĝisdatigilon, kiu flirtas inter du adresoj.
Kiam la starigo publikigas ambaŭ adresajn familiojn, legu kaj la rikordon A kaj la rikordon AAAA. Ĉiu devas montri al servo, kiu vere aŭskultas kaj estas permesata tra sia propra fajroŝirmila vojo, kaj funkcianta IPv4-mapado diras nenion pri la IPv6-flanko. Konservu ankaŭ la identecajn kontrolojn en la klienta profilo: ŝanĝita publika adreso ne estas kaŭzo akcepti atestilon aŭ samtavolan ŝlosilon, kiu ne kongruas.
Pruvu la ŝanĝon de ekstere
Testu per rajtigita ekstera konekto kaj freŝa sesio, ne de interne de la LAN. Interna testo kontraŭ la publika adreso dependas de la konduto de reveno al la propra adreso kaj iras alian vojon ol reala kliento.
Sekvu la sinsekvon, kiun sekvas kliento: solvu la nomon, intertraktu la tunelon, aŭtentigu vin, poste plenumu unu operacion kontraŭ privata rimedo. Ĝuste tiun lastan paŝon homoj preterlasas, kaj nur ĝi pruvas la revenan vojon. Se la ensaluto sukcesas sed la privata operacio malsukcesas, komparu la novan LAN-prefikson, la itinerojn, kiujn la kliento elektis, kaj la respondan vojon de la rimedo kun viaj transdonaj notoj.
Nur post kiam ĉiuj kvar paŝoj pasas, la malnova enkursigilo estas sekura por retiriĝo. Malŝtopu ĝin, poste ripetu la eksteran teston ankoraŭfoje. Malaktuala rikordo, kiu ankoraŭ solviĝas al la malnova adreso, malsukcesas jam ĉe la unua paŝo, kaj tio pli facile diagnozeblas dum la malnova aparato ankoraŭ estas sur la breto.
Konservu la novan mapadon kun viaj reakiraj notoj
Arĥivu la finan servilan atribuon, la envenan regulon kaj la nomon de la ĝisdatiga posedanto apud la proceduro por loke atingi la enkursigilon. La sekva anstataŭigo devus komenciĝi de tiu paĝo, ne de traceroute.
Se la tunelo ankoraŭ malsukcesas de ekstere post ĉio supre, kontrolu, ĉu la publika adreso, kiun la enkursigilo raportas, kongruas kun tiu, kiun klientoj solvas. Tiu sola komparo apartigas DNS-problemon de plusendada problemo, kaj ĝi postulas malpli da tempo ol legi alian gvidilon pri pordplusendado.