Eén subnet migreren naar een nieuwe VPN-tunnel zonder onderbreking

Breng de nieuwe tunnel omhoog, verplaats één subnet, en dat subnet faalt nu af en toe terwijl al het andere volkomen in orde is. Half gemigreerde VPN's falen precies zo, omdat de tunnel nooit het moeilijke deel was. Het pad omvat ook welke route wint, welke selectors overeenkomen, wat de toegangsregels toestaan, hoe antwoorden terugkomen en elke vertaling die het oude ontwerp toepaste. Verplaats alleen de tunnel en je hebt daar niets van verplaatst.

De tunnel is de makkelijke helft van het pad

Af en toe falen na een gedeeltelijke migratie betekent meestal dat twee paden allebei aannemelijk zijn. Sommige stromen kiezen de nieuwe tunnel, andere houden de oude, en een apparaat dat toestand onthoudt ziet dan een antwoord binnenkomen over een pad dat het verzoek nooit gebruikte. Twee paden zijn niet automatisch veiliger dan één; het zijn twee dingen die het oneens kunnen zijn. Kijk naar de rapporten over omslaan en niet naar de tunnelstellers, want de tellers zien er de hele tijd gezond uit.

De nuttige eerste vraag is niet welke tunnel beter is. Het is welke stromen vandaag welk pad kiezen, en of het verzoek en het antwoord hetzelfde antwoord krijgen.

Bouw de bestemming voordat je haar verkiest

Bevestig dat de peers compatibel zijn en dat de nieuwe tunnel het adresbereik draagt dat je bedoelt. Voeg de doorsturing en de dienstmachtigingen toe die hij nodig heeft terwijl hij nog het niet-verkozen pad is, zodat de omschakeling zelf alleen de selectie verandert en niets anders.

Vraag de externe site hoe die het verkeer terugstuurt. Als antwoorden nog steeds via de oude tunnel vertrekken, veroorzaakt een nieuwe lokale route asymmetrie of faalt die op een filter dat toestand onthoudt. Vertaling hoort om dezelfde reden in het ontwerp: een gewijzigd bronadres wijzigt ook de terugweg.

Schakel smal over, en ken de weg terug

Noem het exacte subnet en het platformondersteunde mechanisme dat zijn nieuwe route of selector verkiest. Beleidsgebaseerde definities gedragen zich niet altijd als routemetrieken, dus lees de regels voor overlappende beleidsregels in jouw implementatie voordat je aanneemt dat de specifiekere overeenkomst wint.

Verplaats één subnet, niet één site. Houd beheertoegang op een pad dat je niet aanraakt, en schrijf het terugdraaien op voordat je iets toepast: welke route of welk beleid teruggaat, wie dat doet, en hoe zij verbonden blijven terwijl zij dat doen.

Asymmetrie en verouderde toestand

Firewalls en NAT-apparaten onthouden de interface die een stroom gebruikte. Wanneer verzoek en antwoord verschillende tunnels nemen, kan het apparaat het antwoord laten vallen, ook al werkt elk pad op zichzelf. Test met een stroom die je na de wijziging opent, want een bestaande sessie kan urenlang het oude pad blijven gebruiken.

Als het waargenomen bronadres is verschoven, zoek dan elk beleid dat het oude noemt. Een migratie die de bron stil wijzigt, breekt regels die niemand als deel van het VPN-ontwerp had ingedeeld.

Bewijs beide antwoorden, en trek dan het oude beleid terug

Bereik vanaf een gewone host op het gemigreerde subnet de bedoelde dienst en controleer de waargenomen bron en de antwoordinterface. Test daarna een netwerk dat op de oude tunnel moet blijven, want een migratie is pas klaar als beide antwoorden kloppen. De tweede test is degene die mensen overslaan, en het is degene die een selector vangt die breder is dan bedoeld.

Trek het verouderde beleid pas terug als geen resterend subnet er nog van afhangt, en leg de definitieve route met zijn eigenaar vast in de selectorinventaris. Klaar is niet dat de nieuwe tunnel omhoog meldt; klaar is dat elk netwerk zijn bedoelde pad volgt.