Flytta ett subnät till en ny VPN-tunnel utan avbrott

Res den nya tunneln, flytta ett subnät, och det subnätet misslyckas nu ibland medan allt annat är helt i ordning. Halvmigrerade VPN misslyckas precis så, eftersom tunneln aldrig var den svåra delen. Vägen omfattar också vilken rutt som vinner, vilka selektorer som matchar, vad åtkomstreglerna tillåter, hur svar kommer tillbaka och varje översättning som den gamla designen använde. Flytta bara tunneln och du har inte flyttat något av detta.

Tunneln är den lätta halvan av vägen

Ibland-misslyckanden efter en delvis migrering betyder vanligtvis att två vägar båda är möjliga. Vissa flöden väljer den nya tunneln, andra behåller den gamla, och en enhet som minns tillstånd ser då ett svar komma in på en väg som begäran aldrig använde. Två vägar är inte automatiskt säkrare än en; de är två saker som kan vara oense. Titta på rapporterna om fladder och inte tunnelräknarna, för räknarna kommer att se friska ut hela tiden.

Den användbara första frågan är inte vilken tunnel som är bättre. Det är vilka flöden som väljer vilken väg i dag, och om begäran och svaret får samma svar.

Bygg destinationen innan du föredrar den

Bekräfta att parterna är kompatibla och att den nya tunneln bär det adressområde du avser. Lägg till vidarebefordran och de tjänstetillstånd den behöver medan den fortfarande är den icke-föredragna vägen, så att själva övergången bara ändrar valet och ingenting annat.

Fråga den avlägsna platsen hur den kommer att returnera trafik. Om svar fortfarande lämnar genom den gamla tunneln skapar en ny lokal rutt asymmetri eller misslyckas i ett filter som minns tillstånd. Översättning hör hemma i designen av samma skäl: en ändrad källadress ändrar också returvägen.

Skär smalt över och känn vägen tillbaka

Namnge det exakta subnätet och den plattformsstödda mekanism som föredrar dess nya rutt eller selektor. Policybaserade definitioner beter sig inte alltid som ruttmetriker, så läs reglerna för överlappande policyer i din implementation innan du antar att den mer specifika träffen vinner.

Flytta ett subnät, inte en plats. Håll administrationstillgång på en väg du inte rör, och skriv ner återställningen innan du tillämpar något: vilken rutt eller policy som går tillbaka, vem som gör det och hur de håller sig anslutna medan de gör det.

Asymmetri och gammalt tillstånd

Brandväggar och NAT-enheter minns gränssnittet ett flöde använde. När begäran och svar tar olika tunnlar kan enheten kasta svaret trots att varje väg fungerar för sig. Testa med ett flöde du öppnar efter ändringen, eftersom en etablerad session kan fortsätta använda den gamla vägen i timmar.

Om den observerade källadressen har flyttat sig, hitta varje policy som namnger den gamla. En migrering som tyst ändrar källan bryter regler som ingen klassade som en del av VPN-designen.

Bevisa båda svaren och dra sedan tillbaka den gamla policyn

Från en vanlig värd på det migrerade subnätet, nå den avsedda tjänsten och kontrollera den observerade källan och svarsgränssnittet. Testa sedan ett nätverk som ska stanna på den gamla tunneln, eftersom en migrering bara är klar när båda svaren är rätt. Det andra testet är det folk hoppar över, och det är det som fångar en selektor som är bredare än du menade.

Dra tillbaka den inaktuella policyn först när inget kvarvarande subnät är beroende av den, och registrera den slutliga rutten med sin ägare i selektorinventariet. Klart är inte att den nya tunneln rapporterar uppe; klart är att varje nätverk följer sin avsedda väg.