Flyt et enkelt subnet til en ny VPN-tunnel uden afbrydelse

Rejs den nye tunnel, flyt et subnet, og det subnet fejler nu periodisk, mens alt andet fungerer helt fint. Halvt migrerede VPN'er fejler præcis sådan, fordi tunnelen aldrig var den svære del. Vejen omfatter også, hvilken rute der vinder, hvilke selektorer der matcher, hvad adgangsreglerne tillader, hvordan svar kommer tilbage, og enhver oversættelse, som det gamle design anvendte. Flyt kun tunnelen, og du har ikke flyttet noget af det.

Tunnelen er den nemme halvdel af vejen

Periodiske fejl efter en delvis migrering betyder normalt, at to veje begge er mulige. Nogle flows vælger den nye tunnel, andre beholder den gamle, og en enhed, der husker tilstand, ser så et svar ankomme ad en vej, som anmodningen aldrig brugte. To veje er ikke automatisk sikrere end én; det er to ting, der kan være uenige. Hold øje med rapporterne om omslag i stedet for tunnel-tællerne, for tællerne vil se sunde ud hele vejen igennem.

Det nyttige første spørgsmål er ikke, hvilken tunnel der er bedre. Det er, hvilke flows der vælger hvilken vej i dag, og om anmodningen og svaret får det samme svar.

Byg destinationen, før du foretrækker den

Bekræft, at parterne er kompatible, og at den nye tunnel bærer det adresseomfang, du har tænkt dig. Tilføj videresendelsen og de service-tilladelser, den har brug for, mens den stadig er den ikke-foretrukne vej, så selve skiftet kun ændrer valget og intet andet.

Spørg det fjerne sted, hvordan det vil returnere trafik. Hvis svar stadig forlader gennem den gamle tunnel, skaber en ny lokal rute asymmetri eller fejler i et filter, der husker tilstand. Oversættelse hører hjemme i designet af samme grund: en ændret kildeadresse ændrer også returvejen.

Skift snævert, og kend vejen tilbage

Navngiv det præcise subnet og den platformsunderstøttede mekanisme, der foretrækker dets nye rute eller selektor. Politikbaserede definitioner opfører sig ikke altid som rutemetrikker, så læs reglerne for overlappende politikker i din implementering, før du antager, at det mere specifikke match vinder.

Flyt et subnet, ikke et sted. Hold administrationsadgang på en vej, du ikke rører, og skriv tilbagerulningen ned, før du anvender noget: hvilken rute eller politik der rulles tilbage, hvem der gør det, og hvordan de forbliver forbundet, mens de gør det.

Asymmetri og forældet tilstand

Firewalls og NAT-enheder husker den grænseflade, et flow brugte. Når anmodning og svar tager forskellige tunneler, kan enheden droppe svaret, selvom hver vej virker alene. Test med et flow, du åbner efter ændringen, fordi en etableret session kan blive ved med at bruge den gamle vej i timer.

Hvis den observerede kildeadresse har flyttet sig, find hver politik, der nævner den gamle. En migrering, der stille ændrer kilden, bryder regler, som ingen klassificerede som en del af VPN-designet.

Bevis begge svar, og pensionér derefter den gamle politik

Fra en almindelig vært på det migrerede subnet, nå den tilsigtede tjeneste, og kontrollér den observerede kilde og svar-grænsefladen. Test derefter et netværk, som skal blive på den gamle tunnel, fordi en migrering først er færdig, når begge svar er rigtige. Den anden test er den, folk springer over, og det er den, der fanger en selektor, der er bredere, end du mente.

Pensionér den forældede politik, først når intet tilbageværende subnet afhænger af den, og registrér den endelige rute med sin ejer i selektor-inventaret. Færdiggørelse er ikke, at den nye tunnel rapporterer oppe; det er, at hvert netværk følger sin tilsigtede vej.