Proč vám VPN padá pokaždé, když se obmění klíče

Spojení funguje hodinu a pak zemře a klient nehlásí nic užitečnějšího než disconnected. Právě to období je stopa, protože něco na výměně obnovy se liší od úvodního handshake. Časovač jen rozhoduje, kdy se s tím setkáte. Uložte zprávy z této výměny místo konečného štítku.

Čtěte fázi, ne štítek

V IKEv2 se asociace IKE a asociace CHILD obnovují podle oddělených rozvrhů. Návrh, který byl přijatelný pro první vyjednávání, není automaticky přijatelný pro druhé. Jedna může dokončit, zatímco druhá je odmítnuta, což vytvoří tunel, který existuje napůl. Zachyťte výměnu nástrojem, který ji vlastní, ne řádkem klientského logu:

swanctl --list-sas
swanctl --log --level 2
ip xfrm state list

U OpenVPN je ekvivalentní událostí renegociace řízená verzí a nastavením nasazení. Jeho chování při autentizaci má vlastní režimy selhání. Zpráva, na které záleží, pojmenovává selhavší fázi a vy ji máte zaznamenat doslovně, místo abyste ji přeformulovali do tiketu.

Zapište si také časové značky. Výpadek v pevném intervalu po posledním úspěšném vyjednávání je velmi odlišné zjištění než ten, který přijde náhodně během používání, a interval je často jediný důkaz, který přežije.

Porovnejte návrh, který selhává

Odmítnutý návrh vytváří jasnou zprávu na respondéru. Obvyklou příčinou je rozdíl mezi oběma konci v algoritmu, délce klíče, skupině nebo životnosti. Počáteční vyjednávání CHILD mohlo uspět, protože ho zahájila druhá strana, což znamená, že použilo seznam návrhů druhé strany. Podívejte se na oba konce, než něco změníte.

Nesoulady životnosti si zaslouží zvláštní pozornost, protože hodnota, která na jednom konci vypadala velkoryse, může přimět druhý konec zahájit obnovu, kterou nedokáže dokončit. Dokumentace chování při obnově klíčů popisuje, jak se obnova asociace spouští a jak se oba konce mohou lišit ve svých časových očekáváních. Porovnejte, co každý konec tvrdí, že podporuje, místo co naznačuje konfigurační soubor.

Starý profil nebo šablona poskytovatele může připnout návrh, který aktuální vydání už nenabízí. Nesoulad se projeví jen tehdy, když je vynuceno nové vyjednávání.

Oddělte problém s přihlašovacími údaji od nedostupného protějšku

Obnova, která selže v autentizaci, vypadá v klientovi podobně a na serveru úplně jinak. Pokud se přihlašovací údaj při renegociaci znovu kontroluje, prošlý certifikát, zrušený účet nebo změněné heslo vytvoří výpadek přesně v intervalu obnovy, zatímco všechna předchozí spojení uspěla. Nedostupný protějšek je třetí možností a nevytváří žádné odmítnutí: pakety odejdou a nic neodpovídá. Tento případ obvykle sleduje změnu sítě, ne časovač, takže zkontrolujte, zda selhání následuje po roamingu, nečinném období nebo změně trasy.

Rozlište tři případy podle toho, co zaznamenal vzdálený konec. Odmítnutí s důvodem, selhání autentizace a ticho jsou tři různé opravy. Restart klienta je slije do jednoho neužitečného pozorování.

Zkontrolujte data certifikátu a stav účtu, než obviníte síť. Obojí je levné zkontrolovat a obojí je ve zprávě samotného klienta neviditelné.

Vynuťte jednu obnovu a přečtěte výsledek

Vynuťte jednu obnovu metodou podporovanou operátorem místo čekání hodiny na další. Ponechte požadovanou politiku selhání nedotčenou, zatímco to děláte. Vypnutí ověřování nebo natažení životnosti na den nechá symptom zmizet z vašich logů, aniž by cokoli opravilo. Také ponechá delší výpadek pro dalšího člověka.

Jakmile je oprava na místě, zkontrolujte obnovený tunel a poté odešlete nový požadavek z aplikace. Aplikační relace, která byla živá, když se asociace změnila, může potřebovat vlastní obnovu, i když je tunel znovu zdravý. Uživatelé to nahlásí jako VPN, která je stále rozbitá.

Zaznamenejte verze vydání, vyjednané časovače a fázi, která selhala. Další výskyt pak lze porovnat s tímto, místo aby byl znovu popsán z paměti.