VPN-failover: når returvegen ligg att i den gamle tunnelen

Reservetunnelen kjem opp, den primære går ned, og applikasjonen får framleis tidsavbrot. På begge stader ser tunnelstatusen sunn ut, og det er nettopp det som er forvirrande. Ein failover som flyttar førespurnader til reserven, men lèt svara bli på den gamle vegen, er ikkje ein failover. Runboka nedanfor testar returvegen, ikkje berre handtrykket.

Registrer først rutene i begge endar; eit eittstadbilete kan ikkje vise ein asymmetrisk veg. Det er òg trinnet som oftast blir hoppa over under tidspress.

Registrer rutene til begge stadene før testen

For kvart verna prefiks, skriv den primære ruta, reservruta og preferansen som vel mellom dei. Ta med LAN-gatewayen bak kvar VPN-endepunkt, fordi endepunktet sjeldan er det siste hoppet.

Statiske metrikkar, spora ruter og dynamisk ruting uttrykkjer eignaheit ulikt. Vit kva designet ditt brukar, og kva som krevst for at alternativet blir aktivt. Skriv vilkåret ved sida av ruta, til dømes ein lågare metrikk til proben feilar.

Gjer dette på begge stader. Ein reserve som blir føretrekt på den eine sida og ignorert på den andre, produserer nøyaktig den asymmetrien du prøver å unngå.

Overvak førespurnader og svar i kvar fase

Bruk ein harmlaus tillaten applikasjon og observer tre fasar: normal, primær feil og gjenoppretting. Registrer i kvar fase kva tunnel som ber førespurnaden og kva som ber svaret. Ei tilgjengeleg peer-adresse beviser ikkje at den verna applikasjonsvegen fungerer. Registrer på begge stader slik at ein einvegsstraum blir synleg.

Viss førespurnadene flyttar seg og svara ikkje, kontroller ruta til den eksterne sida til klientprefikset og preferansen hennar for reserven. Det er ei rutingsavgjerd, ikkje ein tunnelfeil.

Gjenopprett den opphavlege tilstanden etter testen og stadfest at den primære blir føretrekt igjen. Ein gjenoppretta primær som ikkje blir føretrekt, er eit failover-design som ikkje er ferdig.

Handter økttilstand når gatewayen blir endra

Brannmurar og NAT kan halde tilkoplingstilstand på éin gateway, og eit vegbyte til ein annan gateway flyttar han ikkje med. Nokre applikasjonar koplar seg til på nytt sjølv; andre feilar til økta er gjenoppretta. Viss reserven endrar den offentlege kjelda eller den omsette private adressa, kan reglar for ekstern tilgang òg reagere. Dokumenter kvar forventa øktomstart i staden for å love failover utan avbrot.

Hald stabil adressering der applikasjonen krev det. Eit failover-design som endrar kjeldeadressa for kvar økt, er eit designval, og det bør skrivast ned. Det valet avgjer kor mykje av avbrotet brukarane faktisk merkar.

Test ein applikasjon som held ei lang økt, ikkje berre ein ny førespurnad.

Gjenopprett den primære og kontroller for flapping

Stadfest at ruteannonseringar eller preferansar stabiliserer seg utan å oscillere. Ein flappande primær kan vere meir forstyrrande enn eit klart avbrot, fordi kvar overgang nullstiller tilstanden.

Hald gatewayadministrasjonen tilgjengeleg via ein gjenopprettingsveg, slik at testen ikkje låser deg ute. Registrer fasane, dei observerte vegane og gjenopprettingstida; den registreringa er det som gjer den neste failoveren føreseieleg. vidareformidlingsnotata frå strongSwan er nyttige når endepunkta er Linux-vertar.