Flytt ett subnett til en ny VPN-tunnel uten avbrudd

Reis den nye tunnelen, flytt ett subnett, og det subnettet feiler nå av og til mens alt annet er helt i orden. Halvt migrerte VPN-er feiler akkurat slik, fordi tunnelen aldri var den vanskelige delen. Veien omfatter også hvilken rute som vinner, hvilke selektorer som passer, hva tilgangsreglene tillater, hvordan svar kommer tilbake, og enhver oversettelse det gamle designet brukte. Flytt bare tunnelen, og du har ikke flyttet noe av dette.

Tunnelen er den lette halvdelen av veien

Av og til-feil etter en delvis migrering betyr vanligvis at to veier begge er mulige. Noen strømmer velger den nye tunnelen, andre beholder den gamle, og en enhet som husker tilstand ser da et svar komme inn på en vei forespørselen aldri brukte. To veier er ikke automatisk tryggere enn én; de er to ting som kan være uenige. Følg med på rapportene om vifting og ikke tunnel-tellerne, for tellerne vil se sunne ut hele veien.

Det nyttige første spørsmålet er ikke hvilken tunnel som er bedre. Det er hvilke strømmer som velger hvilken vei i dag, og om forespørselen og svaret får samme svar.

Bygg destinasjonen før du foretrekker den

Bekreft at partene er kompatible og at den nye tunnelen bærer adresseområdet du har tenkt. Legg til videresendingen og tjenestetillatelsene den trenger mens den fortsatt er den ikke-foretrukne veien, slik at selve overgangen bare endrer valget og ingenting annet.

Spør det fjerne stedet hvordan det vil returnere trafikk. Hvis svar fortsatt forlater gjennom den gamle tunnelen, skaper en ny lokal rute asymmetri eller feiler i et filter som husker tilstand. Oversettelse hører hjemme i designet av samme grunn: en endret kildeadresse endrer også returveien.

Skjær smalt over, og kjenn veien tilbake

Navngi det nøyaktige subnettet og den plattformstøttede mekanismen som foretrekker dens nye rute eller selektor. Policybaserte definisjoner oppfører seg ikke alltid som rutemetrikker, så les reglene for overlappende policyer i implementasjonen din før du antar at den mer spesifikke treffet vinner.

Flytt ett subnett, ikke ett sted. Hold administrasjonstilgang på en vei du ikke rører, og skriv ned tilbakerullingen før du bruker noe: hvilken rute eller policy som går tilbake, hvem som gjør det, og hvordan de holder seg tilkoblet mens de gjør det.

Asymmetri og gammel tilstand

Brannmurer og NAT-enheter husker grensesnittet en strøm brukte. Når forespørsel og svar tar forskjellige tunneler, kan enheten forkaste svaret selv om hver vei virker alene. Test med en strøm du åpner etter endringen, fordi en etablert økt kan fortsette å bruke den gamle veien i timer.

Hvis den observerte kildeadressen har flyttet seg, finn hver policy som navngir den gamle. En migrering som stille endrer kilden, bryter regler ingen klassifiserte som en del av VPN-designet.

Bevis begge svarene, og pensjoner deretter den gamle policyen

Fra en vanlig vert på det migrerte subnettet, nå den tiltenkte tjenesten og kontroller den observerte kilden og svar-grensesnittet. Test deretter et nettverk som skal bli på den gamle tunnelen, fordi en migrering først er ferdig når begge svarene er riktige. Den andre testen er den folk hopper over, og det er den som fanger en selektor som er bredere enn du mente.

Pensjoner den utdaterte policyen først når ingen gjenværende subnett er avhengig av den, og registrer den endelige ruten med eieren i selektor-inventaret. Ferdig er ikke at den nye tunnelen rapporterer oppe; ferdig er at hvert nettverk følger sin tiltenkte vei.