Ce trebuie să păstreze o migrare VPN de la un circuit privat

Circuitele private sunt ușor de descris și greu de înlocuit, pentru că contractul acoperea mai mult decât un cablu. Purta o predare, un plan de adrese, o așteptare de latență și o înțelegere de suport, iar tunelul care îl înlocuiește moștenește toate patru, indiferent dacă cineva le-a scris sau nu. Migrările eșuează când echipa copiază configurația de rutare și numește restul o problemă operațională. Începeți cu cerințele și apoi demonstrați fiecare pe calea nouă înainte ca vechea să fie anulată.

Transformați circuitul într-o listă de proprietăți

Prima întrebare este ce a predat de fapt serviciul vechi: o legătură rutată cu o subrețea mică, sau un segment de nivel 2 partajat între locații. Această distincție decide dacă un tunel IP îl poate reproduce, pentru că un tunel transportă pachete între două adrese și nu transportă descoperire prin broadcast sau EtherTypes arbitrare. Un circuit care se prezenta ca port de comutator este o altă migrare decât unul care prezenta un /30.

Notați prefixele locațiilor, adresele de gateway, aplicațiile care încorporează adrese în propria configurație și prefixele care se suprapun altundeva în mediu. Un plan de adrese care supraviețuiește migrării este un rezultat de proiectare, nu o presupunere. Acele patru liste devin mai târziu și criterii de acceptare, așa că păstrați-le unde testerii le pot citi.

Rutați calea nouă în ambele sensuri

Un tunel care urcă este doar jumătate de drum. Partea îndepărtată are nevoie de o rută înapoi către fiecare prefix local, iar partea locală trebuie să prefere tunelul pentru acele prefixe fără să fure traficul care încă trebuie să iasă prin internet. Forwardarea asimetrică este simptomul obișnuit al faptului că una dintre aceste jumătăți este corectă. Inspectați tabelul părții îndepărtate la fel de atent ca pe al dumneavoastră, pentru că ruta de întoarcere este cea pe care nimeni nu a configurat-o.

ip route get 10.20.0.10

Rutarea bazată pe politici face separarea explicită: marcați traficul care aparține perechii de locații și dați-i un tabel al cărui implicit este tunelul. IPsec furnizează asocierea protejată și politica ce decide ce intră în ea, dar nu rutele din jurul ei, așa cum arhitectura IPsec descrie. Când marcajul se potrivește prea larg, traficul web obișnuit din locație intră și el în tunel și iese pe ieșirea greșită.

Comutați cu o revenire pe care ați testat-o deja

Două căi active cu proprietari diferiți invită la forwardare asimetrică, așa că ridicați-o pe cea nouă într-o fereastră definită și mutați prefixele într-o ordine declarată. Păstrați circuitul vechi configurat și mențineți o cale de administrare în afara benzii care nu depinde de niciunul dintre tuneluri. Mutați un prefix odată unde aplicațiile permit, și urmăriți tabelul de sesiuni între mutări.

Decideți dinainte ce dovezi autorizează comutarea și ce condiție declanșează revenirea. O revenire care cere repararea noului VPN prin conexiunea eșuată nu este o revenire. Formulați declanșatorul ca o condiție măsurabilă, nu ca o senzație din cameră.

Acceptați cu traficul pe care circuitul chiar l-a purtat

Ping dovedește accesibilitatea și puțin altceva. Testați rezolvarea numelor, sesiunile de lungă durată, fluxurile refuzate și dimensiunile de pachet pe care calea veche le trata fără fragmentare. MTU este locul unde tunelurile diferă cel mai des de un circuit, pentru că încapsularea consumă octeți pe care aplicația îi presupunea disponibili. Măsurați cea mai mare încărcătură utilă care trece fără fragmentare în ambele sensuri, nu doar spre server.

ping -M do -s 1400 -c 3 10.20.0.10

Dacă o încărcătură de 1400 de octeți trece și 1472 nu, maximul căii este mai mic decât se așteaptă aplicațiile și ați găsit o regresie reală, nu cosmetică. Comparați rezultatul cu cerințele scrise în primul pas și retrageți circuitul doar când proprietarii acelor aplicații acceptă măsurătoarea. Acea semnătură este ceea ce transformă un test reușit într-o migrare acceptată.