VPN-failover: når returveien blir værende i den gamle tunnelen

Reservetunnelen kommer opp, den primære går ned, og applikasjonen får fortsatt tidsavbrudd. På begge steder ser tunnelstatusen sunn ut, og det er nettopp det som er forvirrende. En failover som flytter forespørsler til reserven, men lar svarene bli på den gamle veien, er ikke en failover. Runboken nedenfor tester returveien, ikke bare håndtrykket.

Registrer først rutene i begge ender; et enkeltstedsbilde kan ikke vise en asymmetrisk vei. Det er også trinnet som oftest hoppes over under tidspress.

Registrer rutene til begge stedene før testen

For hvert beskyttet prefiks, skriv den primære ruten, reservruten og preferansen som velger mellom dem. Ta med LAN-gatewayen bak hvert VPN-endepunkt, fordi endepunktet sjelden er det siste hoppet.

Statiske metrikker, sporede ruter og dynamisk ruting uttrykker egnethet forskjellig. Vit hvilken designet ditt bruker, og hva som kreves for at alternativet blir aktivt. Skriv betingelsen ved siden av ruten, for eksempel en lavere metrikk til proben feiler.

Gjør dette på begge steder. En reserve som foretrekkes på den ene siden og ignoreres på den andre, produserer nøyaktig den asymmetrien du prøver å unngå.

Overvåk forespørsler og svar i hver fase

Bruk en harmløs tillatt applikasjon og observer tre faser: normal, primær feil og gjenoppretting. Registrer i hver fase hvilken tunnel som bærer forespørselen og hvilken som bærer svaret. En tilgjengelig peer-adresse beviser ikke at den beskyttede applikasjonsveien fungerer. Registrer på begge steder slik at en enveisstrøm blir synlig.

Hvis forespørslene flytter seg og svarene ikke, kontroller den eksterne sidens rute til klientprefikset og dens preferanse for reserven. Det er en rutingsbeslutning, ikke en tunnelfeil.

Gjenopprett den opprinnelige tilstanden etter testen og bekreft at den primære foretrekkes igjen. En gjenopprettet primær som ikke foretrekkes, er et failover-design som ikke er ferdig.

Håndter økttilstand når gatewayen endres

Brannmurer og NAT kan holde tilkoblingstilstand på én gateway, og et veiskifte til en annen gateway flytter den ikke med. Noen applikasjoner kobler seg til på nytt selv; andre feiler til økten er gjenopprettet. Hvis reserven endrer den offentlige kilden eller den oversatte private adressen, kan regler for ekstern tilgang også reagere. Dokumenter enhver forventet øktomstart i stedet for å love failover uten avbrudd.

Hold stabil adressering der applikasjonen krever det. Et failover-design som endrer kildeadressen for hver økt, er et designvalg, og det bør skrives ned. Det valget avgjør hvor mye av avbruddet brukerne faktisk merker.

Test en applikasjon som holder en lang økt, ikke bare en ny forespørsel.

Gjenopprett den primære og kontroller for flapping

Bekreft at ruteannonseringer eller preferanser stabiliserer seg uten å oscillere. En flappende primær kan være mer forstyrrende enn et klart avbrudd, fordi hver overgang nullstiller tilstanden.

Hold gatewayadministrasjonen tilgjengelig via en gjenopprettingsvei, slik at testen ikke låser deg ute. Registrer fasene, de observerte veiene og gjenopprettingstiden; den registreringen er det som gjør den neste failoveren forutsigbar. strongSwans videresendingsnotater er nyttige når endepunktene er Linux-verter.