Schimbați furnizorul fără a renumerota adresele VPN ale site-ului

O sucursală schimbă furnizorul de internet, iar serverul de fișiere își păstrează adresa. Acest rezultat este normal într-un VPN de site rutat și surprinzător pentru oricine presupune că adresa punctului final al tunelului este adresa aplicației. Cele două trăiesc în straturi diferite ale proiectării, și doar unul s-a mutat. A le trata ca un singur lucru este felul în care o migrare de furnizor devine un proiect de renumerotare.

Două planuri de adrese care se mișcă independent

Planul interior descrie adresele private pe care le folosesc aplicațiile: serverul sucursalei la 10.55.8.20, prefixul sediului central care rutează spre el și ruta de întoarcere. Planul exterior descrie cum două gateway-uri ajung unul la altul: adrese de pereche, porturi de ascultare și calea prin internet.

O schimbare de furnizor atinge planul exterior. Ea nu cere în sine modificarea planului interior.

Păstrarea celor două inventare separate este motivul practic pentru a rula un overlay chiar și atunci când aplicația își criptează deja propriul trafic. Overlay-ul vă oferă o topologie interioară stabilă care supraviețuiește schimbărilor exterioare. Aplicația își păstrează adresa, regulile de firewall și înregistrările DNS. Se schimbă doar intrările de transport, iar aceasta este o examinare mult mai mică.

Tunelul exterior poartă conversația interioară

Într-un tunel de la gateway la gateway, antetul IP exterior adresează cele două gateway-uri. Antetul interior numește în continuare punctele finale reale ale aplicației. Descrierea de la gateway la gateway din RFC 7296 tratează acest lucru ca rutare obișnuită care livrează trafic prin punctele finale ale tunelului.

De aceea serverul sucursalei poate păstra 10.55.8.20 în timp ce adresa publică a gateway-ului se schimbă. Pachetul interior nu conține deloc adresa furnizorului.

Separarea este o proprietate a proiectării, nu o garanție automată. Dacă legătura de înlocuire nu poate stabili tunelul acceptat, sau rutele interioare nu sunt reinstalate, aplicația își pierde calea chiar dacă adresa ei nu s-a schimbat.

Mutarea furnizorului are încă o listă de verificare

Lista exterioară are cinci puncte: adresa perechii sau numele întreținut, ascultătorul și orice filtrare din amonte, traducerea pe cale, identitatea așteptată a perechii și setările permise ale celuilalt gateway. Fiecare poate eșua singur. Păstrați o cale de recuperare separată în timp ce schimbați legătura care poartă administrarea. Întreruperea accesului la distanță în timpul unei schimbări de legătură este o pană pe care ați provocat-o singur.

După aceea, verificați prefixul sucursalei, ruta în ambele direcții, politica de protecție și un flux real de aplicație. Un tunel proaspăt autentificat nu repară o rută care indică vechea subrețea privată.

Suprapunerea de adrese cu un alt site conectat este o problemă separată de planificare. Schimbarea furnizorului nu o creează, dar migrarea este de obicei momentul în care apare.

Ce nu supraviețuiește: sursa publică și sesiunile

O adresă privată stabilă de server nu este o sursă publică stabilă. Dacă navigarea iese direct prin noul furnizor, site-urile văd noua adresă orientată spre furnizor.

Păstrarea acelei adrese stabile cere un proiect de ieșire deliberat, cu propria disponibilitate și politică. Nu vine gratis cu tunelul.

Nici sesiunile stabilite nu supraviețuiesc unei schimbări de cale. Tunelul se poate restabili în câteva secunde și totuși poate rupe conexiuni de durată fixate pe vechea cale. Planificați trecerea pentru o fereastră în care reconectările sunt acceptabile. Nu afirmați că o migrare va fi invizibilă dacă nu au fost testate clienții concreți și termenele lor.

Verificați mutarea cu patru controale

După schimbare, verificați patru lucruri în ordine: tunelul este stabilit cu perechea prevăzută, ruta interioară către prefixul sucursalei există, politica permite fluxul aplicației și aplicația răspunde. Fiecare are comanda sa.

Pe un gateway Linux, aceste trei acoperă mijlocul listei:

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

Păstrați adresele de transport într-un inventar și adresele aplicațiilor în altul. Actualizați doar intrările care s-au mutat cu adevărat. Renumerotarea dependențelor interne pentru că s-a schimbat adresa exterioară a tunelului este muncă evitabilă.