Flytt eitt subnett til ein ny VPN-tunnel utan avbrot

Reis den nye tunnelen, flytt eitt subnett, og det subnettet feilar no av og til medan alt anna er heilt i orden. Halvt migrerte VPN-ar feilar nett slik, fordi tunnelen aldri var den vanskelege delen. Vegen omfattar òg kva rute som vinn, kva selektorar som passar, kva tilgangsreglane lèt til, korleis svar kjem tilbake, og kvar oversetjing den gamle utforminga brukte. Flytt berre tunnelen, og du har ikkje flytt noko av dette.

Tunnelen er den lette halvdelen av vegen

Av og til-feil etter ei delvis migrering tyder vanlegvis at to vegar begge er mogelege. Nokre straumar vel den nye tunnelen, andre held på den gamle, og eit apparat som hugsar tilstand ser då eit svar kome inn på ein veg førespurnaden aldri brukte. To vegar er ikkje automatisk tryggare enn éin; dei er to ting som kan vere usamde. Fylg med på rapportane om vifting og ikkje tunnel-teljarane, for teljarane vil sjå sunne ut heile vegen.

Det nyttige fyrste spørsmålet er ikkje kva tunnel som er betre. Det er kva straumar som vel kva veg i dag, og om førespurnaden og svaret får same svar.

Bygg destinasjonen før du føretrekkjer han

Stadfest at partane er kompatible og at den nye tunnelen ber adresseområdet du har tenkt. Legg til vidaresendinga og tenesteløyva han treng medan han enno er den ikkje-føretrekte vegen, slik at sjølve overgangen berre endrar valet og ingenting anna.

Spør det fjerne staden korleis han vil returnere trafikk. Viss svar enno går ut gjennom den gamle tunnelen, skapar ei ny lokal rute asymmetri eller feilar i eit filter som hugsar tilstand. Oversetjing høyrer heime i utforminga av same grunn: ei endra kjeldeadresse endrar òg returvegen.

Skjer smalt over, og kjenn vegen tilbake

Namngje det nøyaktige subnettet og den plattformstøtta mekanismen som føretrekkjer den nye ruta eller selektoren hans. Policybaserte definisjonar oppfører seg ikkje alltid som rutemetrikkar, så les reglane for overlappande policyar i implementasjonen din før du reknar med at den meir spesifikke treffa vinn.

Flytt eitt subnett, ikkje ein stad. Hald administrasjonstilgang på ein veg du ikkje rører, og skriv ned tilbakerullinga før du brukar noko: kva rute eller policy som går tilbake, kven som gjer det, og korleis dei held seg tilkopla medan dei gjer det.

Asymmetri og gammal tilstand

Brannmurar og NAT-einingar hugsar grensesnittet ein straum brukte. Når førespurnad og svar tek ulike tunnelar, kan eininga kaste svaret sjølv om kvar veg verkar åleine. Test med ein straum du opnar etter endringa, fordi ei etablert økt kan halde fram med å bruke den gamle vegen i timar.

Viss den observerte kjeldeadressa har flytta seg, finn kvar policy som namngjev den gamle. Ei migrering som stille endrar kjelda, bryt reglar ingen klassifiserte som ein del av VPN-utforminga.

Prov begge svara, og pensjoner deretter den gamle policyen

Frå ein vanleg vert på det migrerte subnettet, nå den tiltenkte tenesta og kontroller den observerte kjelda og svar-grensesnittet. Test deretter eit nettverk som skal bli på den gamle tunnelen, fordi ei migrering fyrst er ferdig når begge svara er rette. Den andre testen er den folk hoppar over, og det er den som fangar ein selektor som er breiare enn du meinte.

Pensjoner den utdaterte policyen fyrst når ingen attverande subnett er avhengig av han, og registrer den endelege ruta med eigaren i selektor-inventaret. Ferdig er ikkje at den nye tunnelen rapporterer oppe; ferdig er at kvart nettverk fylgjer sin tiltenkte veg.