Filialas keičia interneto tiekėją, o failų serveris išlaiko savo adresą. Toks rezultatas yra normalus maršrutizuotame svetainės VPN ir stebina kiekvieną, kuris mano, kad tunelio galinio taško adresas yra programos adresas. Abu gyvena skirtinguose dizaino sluoksniuose, ir pasislinko tik vienas. Elgtis su jais kaip su vienu yra būdas, kuriuo tiekėjo migracija virsta pernumeravimo projektu.

Du adresų planai, kurie juda nepriklausomai

Vidinis planas aprašo privačius adresus, kuriuos naudoja programos: filialo serveris adresu 10.55.8.20, būstinės prefiksas, kuris nukreipia į jį, ir grįžimo maršrutas. Išorinis planas aprašo, kaip du šliuzai pasiekia vienas kitą: partnerio adresai, klausymosi prievadai ir kelias per internetą.

Tiekėjo keitimas paliečia išorinį planą. Jis pats savaime nereikalauja keisti vidinio plano.

Laikyti du inventorius atskirai yra praktinė priežastis naudoti perdangą net tada, kai programa jau pati šifruoja savo srautą. Perdanga suteikia stabilią vidinę topologiją, kuri atlaiko išorinius pokyčius. Programa išlaiko savo adresą, ugniasienės taisykles ir DNS įrašus. Keičiasi tik transporto įrašai, ir tai yra daug mažesnė peržiūra.

Išorinis tunelis neša vidinį pokalbį

Šliuzo-šliuzo tunelyje išorinė IP antraštė adresuoja abu šliuzus. Vidinė antraštė vis dar įvardija tikruosius programos galinius taškus. RFC 7296 šliuzo-šliuzo aprašymas tai laiko įprastu maršrutizavimu, kuris pristato srautą per tunelio galinius taškus.

Todėl filialo serveris gali išlaikyti 10.55.8.20, kol keičiasi viešasis šliuzo adresas. Vidiniame pakete tiekėjo adreso apskritai nėra.

Atskyrimas yra dizaino savybė, o ne automatinė garantija. Jei pakaitinis uplink negali sukurti palaikomo tunelio arba vidiniai maršrutai neįdiegiami iš naujo, programa praranda savo kelią, nors jos adresas nepasikeitė.

Tiekėjo perkėlimas vis dar turi kontrolinį sąrašą

Išoriniame kontroliniame sąraše yra penki punktai: partnerio adresas arba palaikomas vardas, klausytojas ir bet koks filtravimas aukščiau, vertimas kelyje, laukiama partnerio tapatybė ir kito šliuzo leidžiami nustatymai. Kiekvienas gali nepavykti atskirai. Laikykite atskirą atkūrimo kelią, kol keičiate jungtį, kuri neša administravimą. Nutraukti nuotolinę prieigą uplink perjungimo metu yra sutrikimas, kurį sukėlėte patys.

Po to patikrinkite filialo prefiksą, maršrutą abiem kryptimis, apsaugos politiką ir vieną realų programos srautą. Ką tik autentifikuotas tunelis nesutaiso maršruto, kuris rodo į seną privatų potinklį.

Adresų sutapimas su kita prijungta svetaine yra atskira planavimo problema. Tiekėjo keitimas jos nesukuria, bet migracija paprastai yra tas momentas, kai ji išryškėja.

Kas neišlieka: viešasis šaltinis ir sesijos

Stabilus privatus serverio adresas nėra stabilus viešasis šaltinis. Jei naršymas išeina tiesiai per naują tiekėją, svetainės mato naują į tiekėją atsuktą adresą.

Išlaikyti tą adresą stabiliu reikia apgalvoto išėjimo dizaino su savo prieinamumu ir politika. Jis neateina nemokamai su tuneliu.

Nustatytos sesijos taip pat neišgyvena kelio pasikeitimo. Tunelis gali atsistatyti per sekundes ir vis tiek nutraukti ilgalaikius ryšius, pririštus prie seno kelio. Planuokite perjungimą tokiam langui, kai pakartotinis prisijungimas yra priimtinas. Netvirtinkite, kad migracija bus nematoma, jei konkretūs klientai ir jų laiko limitai nebuvo išbandyti.

Patikrinkite perkėlimą keturiais patikrinimais

Po pakeitimo patikrinkite keturis dalykus iš eilės: tunelis sukurtas su numatytu partneriu, vidinis maršrutas iki filialo prefikso egzistuoja, politika leidžia programos srautą ir programa atsako. Kiekvienas turi savo komandą.

Linux šliuze šie trys apima to sąrašo vidurį:

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/health

Transporto adresus laikykite viename inventoriuje, o programų adresus kitame. Atnaujinkite tik tuos įrašus, kurie tikrai pasislinko. Vidinių priklausomybių pernumeravimas dėl pasikeitusio išorinio tunelio adreso yra išvengiamas darbas.

Susiję straipsniai