VPN-failover: når returvejen bliver på den gamle tunnel

Backuptunnelen kommer op, den primære går ned, og applikationen får stadig timeout. På begge steder ser tunnelstatus sund ud, og det er netop det, der gør det forvirrende. En failover, der flytter forespørgsler til backup, men lader svarene blive på den gamle vej, er ikke en failover. Runbooken nedenfor tester returvejen, ikke bare håndtrykket.

Registrér først ruterne i begge ender; et enkeltstedsbillede kan ikke vise en asymmetrisk vej. Det er også det trin, der oftest springes over under tidspres.

Registrér begge steders ruter før testen

For hvert beskyttet præfiks skal du skrive den primære rute, backup-ruten og den præference, der vælger mellem dem. Medtag LAN-gatewayen bag hvert VPN-endepunkt, fordi endepunktet sjældent er det sidste hop.

Statiske metrikker, sporede ruter og dynamisk routing udtrykker egnethed forskelligt. Vid, hvilken din design bruger, og hvad der skal til, for at alternativet bliver aktivt. Skriv betingelsen ved siden af ruten, for eksempel en lavere metrik, indtil proben fejler.

Gør dette på begge steder. En backup, der foretrækkes på den ene side og ignoreres på den anden, producerer præcis den asymmetri, du prøver at undgå.

Overvåg forespørgsler og svar i hver fase

Brug en harmløs tilladt applikation, og observer tre faser: normal, primær fejl og genopretning. Registrér i hver fase, hvilken tunnel der bærer forespørgslen, og hvilken der bærer svaret. En tilgængelig peer-adresse beviser ikke, at den beskyttede applikationsvej virker. Registrér på begge steder, så en envejsstrøm bliver synlig.

Hvis forespørgslerne flytter sig, og svarene ikke gør, så kontrollér det fjerne steds rute til klientpræfikset og dets præference for backup. Det er en routingbeslutning, ikke en tunnelfejl.

Gendan den oprindelige tilstand efter testen, og bekræft at den primære foretrækkes igen. En gendannet primær, der ikke foretrækkes, er et failover-design, der ikke er færdigt.

Håndtér sessionstilstand, når gatewayen skifter

Firewalls og NAT kan holde forbindelsestilstand på én gateway, og et vejskift til en anden gateway flytter den ikke med. Nogle applikationer genopretter forbindelsen selv; andre fejler, indtil sessionen er genoprettet. Hvis backup ændrer den offentlige kilde eller den oversatte private adresse, kan fjernadgangsregler også reagere. Dokumentér enhver forventet sessionsgenstart i stedet for at love failover uden afbrydelse.

Bevar stabil adressering, hvor applikationen kræver det. Et failover-design, der ændrer kildeadressen for hver session, er et designvalg, og det bør skrives ned. Det valg bestemmer, hvor meget af afbrydelsen brugerne reelt bemærker.

Test en applikation, der holder en lang session, ikke kun en ny forespørgsel.

Gendan den primære, og kontrollér for flapping

Bekræft, at ruteannonceringer eller præferencer falder til ro uden at oscillere. En flappende primær kan være mere forstyrrende end en klar afbrydelse, fordi hver overgang nulstiller tilstand.

Hold gatewayadministration tilgængelig via en genopretningsvej, så testen ikke selv låser dig ude. Registrér faserne, de observerede veje og genopretningstiden; den registrering er det, der gør den næste failover forudsigelig. strongSwans videresendelsesnoter er nyttige, når endepunkterne er Linux-værter.