Zkrácení časovače DPD nezrychlí přepnutí VPN

Tunely padají, obnova trvá devadesát sekund a časovač mrtvého partnera je nastaven na deset, takže se viní časovač. Tato úvaha přeskakuje tři fáze, které nastávají po detekci a obvykle zabírají většinu času. Detekce živosti si všimne ticha; poté výběr partnera, autentizace, instalace trasy a opětovné připojení aplikace vezmou každý svůj díl. Zkrácení první fáze nemůže zkrátit ostatní a může přidat zmatek systému, který už měl potíže.

Čtyři fáze, jednu z nich můžete změřit

Zapište obnovu jako čtyři události s časovými razítky. Selhání se stane pozorovatelným: poslední užitečný chráněný provoz a první neúspěšný požadavek. Vlastnící mechanismus reaguje: detekce živosti, monitor trasy nebo jiný zdokumentovaný spouštěč. Alternativa se stane použitelnou: výběr partnera, autentizace, nová asociace a trasa, která skutečně nese zamýšlený provoz. Aplikace se obnoví: nová operace uspěje a to, co bylo v běhu, má definovaný výsledek.

Pravidla živosti IKEv2 popisují důkazy o partnerovi a jeho výměnách a neříkají nic o databázi nebo souborové službě za tímto partnerem. Čtení vypršení živosti jako kontroly stavu celé cesty je chyba, která spouští hon na časovač.

Proč je časovač nejméně zajímavé číslo

Nakonfigurované hodnoty nejsou zaměnitelné jednotky. Některé jsou intervaly opakování, některé horní meze pokusu a některé běží souběžně s jinými. Jejich sečtením vznikne číslo, které vypadá jako předpověď a chová se jako fáma. Přečtěte si dokumentaci k poli, kterého se chystáte dotknout, a všimněte si, který ze tří druhů to je.

Jiné fáze vůbec nejsou časovače. Zpoždění opětovného připojení, interaktivní výzva k autentizaci nebo klient, který svou konfiguraci přehodnocuje jen při restartu, mohou každý dominovat výpadku, zatímco každý protokolový časovač zůstává pohodlně nízko.

Změřte fázi, která je skutečně pomalá

Zachyťte selhání jednou, s časovými razítky na obou stranách, a poté porovnejte čtyři události, ne vlastní počítadla protokolu. Jedno správně provedené pozorovací okno je lepší než měsíc ladění.

ip -4 route get 203.0.113.10
tcpdump -ni any -c 20 "esp or icmp"

Pokud alternativní koncový bod nikdy neodpoví, žádná změna časovače nepomůže, protože nedostupnost není problém detekce. Pokud se nový bezpečnostní stav vytvoří rychle, ale trasa stále ukazuje na mrtvou cestu, problém je v instalaci trasy a další úprava živosti jen přidá zmatek.

Alternativa musí být už použitelná

Záloha definovaná v konfiguraci není záloha, která funguje. Musí být dostupná z aktuální sítě klienta, schopná autentizovat stejnou identitu a mít povolení nést stejný provoz podle stejné politiky. Objevíte-li některou z těchto tří mezer během výpadku, diskuse o časovači se stane irelevantní. Testujte alternativu, dokud je primární v pořádku, protože to je jediná doba, kdy můžete číst oba záznamy vedle sebe.

Připravte alternativu předem, záměrně ji testujte, dokud je primární v pořádku, a zaznamenejte, která ze čtyř fází zabírá čas. Právě tento záznam dělá z další změny měření místo dohadu.

Zmatek při návratu a řídicí cesta

Obnova primární je samostatné rozhodnutí. Agresivní návrat může přerušit práci, která se už obnovila na záloze, a nestabilní cesta může vypadat jako nestabilní tunel, když skutečná závada je trasa, která neustále osciluje mezi dvěma rovnocennými možnostmi.

Dvě rovnocenné cesty bez preference jsou obvyklým zdrojem viditelného kmitání, protože každý monitor reaguje na volbu toho druhého. Rozhodněte, která cesta je za normálních podmínek preferovaná, a tuto preferenci učiňte v konfiguraci explicitní, místo abyste ji nechali na pořadí tras. Předem definujte požadované chování při návratu a kdo ho vlastní. Zachovejte předchozí nastavení a nezávislou řídicí cestu, protože změna, která vám během výpadku odebere vlastní přístup, mění síťový incident v návštěvu na místě.

Poté zopakujte stejnou zátěž a porovnejte stejná čtyři časová razítka. Kratší obnova, která aplikaci stále nechává čekat na stejnou chybějící trasu nebo přihlášení, není pokrok, je to jiné číslo na stejném grafu.