Vad en VPN-övergång måste bevara från en privat förbindelse

Privata förbindelser är lätta att beskriva och svåra att ersätta, eftersom avtalet omfattade mer än en kabel. Den bar en överlämning, en adressplan, en latensförväntan och en supportöverenskommelse, och tunneln som ersätter den ärver alla fyra, oavsett om någon skrev ned dem. Övergångar misslyckas när teamet kopierar routingkonfigurationen och kallar resten ett driftsproblem. Börja med kraven och bevisa sedan vart och ett på den nya vägen innan den gamla sägs upp.

Gör förbindelsen till en lista över egenskaper

Den första frågan är vad den gamla tjänsten faktiskt lämnade över: en routad länk med ett litet subnät, eller ett lager 2-segment som delas mellan platser. Den skillnaden avgör om en IP-tunnel alls kan återskapa den, eftersom en tunnel transporterar paket mellan två adresser och inte transporterar broadcast-upptäckt eller godtyckliga EtherTypes. En förbindelse som presenterade sig som en switchport är en annan migrering än en som presenterade ett /30.

Skriv ned platsernas prefix, gateway-adresserna, applikationerna som bäddar in adresser i sin egen konfiguration och prefixen som överlappar någon annanstans i miljön. En adressplan som överlever migreringen är ett designresultat, inte ett antagande. De fyra listorna blir också acceptanskriterier senare, så förvara dem där testarna kan läsa dem.

Routa den nya vägen i båda riktningarna

En tunnel som kommer upp är bara halva vägen. Den bortre sidan behöver en väg tillbaka till varje lokalt prefix, och den lokala sidan måste föredra tunneln för dessa prefix utan att stjäla trafik som fortfarande ska ut via internet. Asymmetrisk vidarebefordran är det vanliga symptomet på att en av dessa halvor är rätt gjord. Granska den bortre sidans tabell lika noggrant som din egen, eftersom returvägen är den som ingen konfigurerade.

ip route get 10.20.0.10

Principbaserad routing gör uppdelningen explicit: märk trafiken som hör till platsparet och ge den en tabell vars standard är tunneln. IPsec levererar den skyddade associationen och policyn som avgör vad som kommer in i den, men inte vägarna runt den, som IPsec-arkitekturen beskriver. När märkningen matchar för brett går även vanlig webbtrafik från platsen in i tunneln och ut genom fel utgång.

Byt med en återställning som du redan har testat

Två levande vägar med olika ägare bjuder in till asymmetrisk vidarebefordran, så ta upp den nya inom ett definierat fönster och flytta prefix i en annonserad ordning. Låt den gamla förbindelsen vara konfigurerad och behåll en out-of-band-hanteringsväg som inte beror på någon av tunnlarna. Flytta ett prefix i taget där applikationerna tillåter det, och följ sessionstabellen mellan flyttarna.

Bestäm i förväg vilka bevis som auktoriserar bytet och vilket villkor som utlöser återställningen. En återställning som kräver att den nya VPN:en repareras genom den misslyckade anslutningen är ingen återställning. Formulera utlösaren som ett mätbart villkor och inte som en känsla i rummet.

Acceptera med trafiken som förbindelsen faktiskt bar

Ping bevisar nåbarhet och lite annat. Testa namnutslagning, de långvariga sessionerna, de nekade flödena och de paketstorlekar som den gamla vägen klarade utan fragmentering. MTU är där tunnlar oftast skiljer sig från en förbindelse, eftersom inkapsling förbrukar byte som applikationen antog var tillgängliga. Mät den största nyttolasten som passerar utan fragmentering i båda riktningarna, inte bara mot servern.

ping -M do -s 1400 -c 3 10.20.0.10

Om en nyttolast på 1400 byte passerar och 1472 inte, är vägens maximum mindre än applikationerna förväntar sig, och du har hittat en verklig regression, inte en kosmetisk. Jämför resultatet med kraven som skrevs i första steget och avveckla förbindelsen först när ägarna av dessa applikationer accepterar mätningen. Den signaturen är det som gör ett lyckat test till en accepterad migrering.