Å forkorte DPD-timeren gjør ikke VPN-failover raskere
Gjenoppretting har fire faser, og timeren for død peer styrer én av dem. Mål deteksjon, peervalg, ruter og applikasjonsgjenoppretting hver for seg.
Tunneler faller, gjenoppretting tar nitti sekunder, og timeren for død peer er satt til ti, så timeren får skylden. Den resonnementet hopper over tre faser som skjer etter deteksjonen og vanligvis bruker mesteparten av tiden. Deteksjon av livstegn merker stillheten; deretter tar peervalg, autentisering, ruteinstallasjon og applikasjonens gjenoppkobling hver sin runde. Å forkorte den første fasen kan ikke forkorte de andre, og det kan tilføre uro til et system som allerede slet.
Fire faser, hvorav du kan ta tiden på én
Skriv gjenopprettingen som fire hendelser med tidsstempler. Feilen blir observerbar: den siste nyttige beskyttede trafikken og den første mislykkede forespørselen. Den ansvarlige mekanismen reagerer: deteksjon av livstegn, en rutemonitor eller en annen dokumentert utløser. Alternativet blir brukbart: peervalg, autentisering, en ny assosiasjon og en rute som faktisk bærer den tiltenkte trafikken. Applikasjonen gjenopprettes: en ny operasjon lykkes, og det som var i gang har et definert utfall.
IKEv2s regler for livstegn beskriver bevis om peeren og utvekslingene dens, og sier ingenting om en database eller filtjeneste bak den peeren. Å lese en livstegn-timeout som en helsesjekk for hele veien er feilen som starter timerjakten.
Hvorfor timeren er det minst interessante tallet
Konfigurerte verdier er ikke utskiftbare enheter. Noen er gjenforsøksintervaller, noen er øvre grenser for et forsøk, og noen kjører samtidig med andre. Å legge dem sammen gir et tall som ser ut som en prediksjon og oppfører seg som et rykte. Les dokumentasjonen for feltet du er i ferd med å røre, og noter hvilken av de tre typene det er.
Andre faser er slett ikke timere. En gjenoppkoblings-backoff, en interaktiv autentiseringsforespørsel eller en klient som bare revurderer konfigurasjonen sin ved omstart kan hver for seg dominere avbruddet mens hver protokolltimer sitter komfortabelt lavt.
Mål fasen som faktisk er treg
Fang feilen én gang, med tidsstempler på begge sider, og sammenlign deretter de fire hendelsene i stedet for protokollens egne tellere. Ett skikkelig utført observasjonsvindu slår en måned med tuning.
ip -4 route get 203.0.113.10
tcpdump -ni any -c 20 "esp or icmp"
Hvis det alternative endepunktet aldri svarer, hjelper ingen timerendring, fordi utilgjengelighet ikke er et deteksjonsproblem. Hvis ny sikkerhetstilstand dannes raskt, men ruten fortsatt peker på den døde veien, er problemet ruteinstallasjon, og nok en livstegnjustering tilfører bare uro.
Alternativet må allerede være brukbart
En sikkerhetskopi definert i en konfigurasjon er ikke en sikkerhetskopi som virker. Den må være nåbar fra klientens nåværende nettverk, kunne autentisere samme identitet og være tillatt å bære samme trafikk under samme policy. Oppdager du noen av disse tre hullene under et avbrudd, blir timerdrøftingen irrelevant. Test alternativet mens den primære er frisk, for det er den eneste tiden du kan lese begge loggene side ved side.
Forhåndsprovider alternativet, test det bevisst mens den primære er frisk, og noter hvilken av de fire fasene som tar tiden. Den registreringen er det som gjør den neste endringen til en måling i stedet for en gjetning.
Uro ved tilbakefall og administrasjonsveien
Å gjenopprette den primære er en egen beslutning. Aggressiv tilbakefall kan avbryte arbeid som allerede var gjenopprettet på sikkerhetskopien, og en flagrende rute kan se ut som en ustabil tunnel når den egentlige feilen er en rute som stadig svinger mellom to like alternativer.
To ruter med lik kostnad uten preferanse er den vanlige kilden til synlig flagring, fordi hver monitor reagerer på den andres valg. Bestem hvilken rute som foretrekkes under normale forhold, og gjør den preferansen eksplisitt i konfigurasjonen i stedet for å overlate den til ruterekkefølgen. Definer ønsket tilbakefallsatferd og hvem som eier den, på forhånd. Behold de forrige innstillingene og en uavhengig administrasjonsvei, fordi en endring som fjerner din egen tilgang under et avbrudd gjør en nettverkshendelse om til et stedlig besøk.
Gjenta deretter samme arbeidsmengde og sammenlign de samme fire tidsstemplene. En kortere gjenoppretting som fortsatt lar applikasjonen vente på den samme manglende ruten eller innloggingen er ikke fremgang, det er et annet tall på samme graf.