Proč tunel Azure OpenVPN padá přibližně každých šedesát sekund

Tunel dokončí handshake, přenáší provoz asi minutu a potom se znovu připojí. Tato posloupnost vylučuje obvyklého podezřelého, protože firewall blokující port by zastavil handshake, ne relaci. Co máte, je neshoda o živosti: jedna strana rozhodla, že druhá ztichla, a strhla funkční tunel. Řádek v logu říká která strana, a ten volí opravu.

Přečtěte si ten řádek, než se dotknete jakéhokoli časovače.

Mýtus: něco na cestě tunel blokuje

Kdyby byl port blokovaný, spojení by selhalo hned na začátku a zůstalo by selhané. Opakující se cyklus znamená, že řídicí zprávy proudí, relace se navazují a něco později v konverzaci neustále vyprší. Blokování vytváří ticho, a tohle vytváří rytmus.

Rytmus je užitečná stopa. Vytvářejí ho časovače; ztráta paketů jen zřídka.

Přečtěte si důvod odpojení dřív než časovač

OpenVPN pojmenovává svůj důvod a každé jméno ukazuje na jiný subsystém. Session invalidated: KEEPALIVE_TIMEOUT je vypršení časovače, takže porovnejte hodnoty ping a ping-restart na obou stranách. AUTH_FAILED jsou přihlašovací údaje nebo stav certifikátu a žádná změna časovače nepomůže. Chyba TLS znamená, že protistrany vůbec nedosáhly fáze keepalive.

Zaznamenejte čas připojení, čas odpojení a zda je interval stabilní na sekundu. Toto jediné měření odděluje nakonfigurovaný plán od náhody.

Stabilní interval je časovač. Ten, který se posouvá, je spíš problém cesty nebo přesunutá relace.

Dva časovače keepalive, které se nikdy nedohodly

Profily exportované z portálu někdy stále nesou řádky keepalive nebo ping-restart zkopírované ze šablony komunitního serveru. Brána provádí vlastní detekci mrtvého partnera a prosazuje vlastní očekávání a oba plány se nemusejí shodovat. Když se rozcházejí, klient se restartuje podle plánu, se kterým brána nikdy nesouhlasila.

Tyto dvě hodnoty nejsou stejné řízení. ping je, jak často klient posílá ozvěnu, a ping-restart je, jak dlouho čeká, aniž by něco slyšel, než tunel strhne. Profil s krátkým ping-restart a brána, která odpovídá pomalu, se restartují v každém tichém období, což je přesně podoba jednominutového cyklu.

Nejmenší změna na straně klienta je neutralizovat časovače na nejvyšší úrovni profilu, mimo každý vložený blok:

keepalive 0 0

Uložte, znovu načtěte profil, znovu se připojte. Relace už v paměti si ponechává staré hodnoty, a proto úprava někdy vypadá, jako by nic neudělala.

Název certifikátu se vám může posunout pod nohama

Ověřování certifikátem Azure závisí na tom, zda klient důvěřuje názvu, který brána dnes předkládá. Řádek verify-x509-name ve starším stažení může připnout název, který přestavba brány nebo obnova certifikátu mezitím změnily, a nesoulad se projeví jako smyčka opakovaného připojení, ne jako jasná chyba. Smazání řádku obnoví konektivitu, což z něj dělá dobrý diagnostický nástroj a špatnou trvalou opravu, protože odstraní i ověřování. Jakmile tunel vydrží, obnovte řádek s názvem, který brána skutečně předkládá.

Otestujte druhou generaci klienta na stejném počítači, než začnete bránu upravovat. Pokud jeden klient cykluje a druhý drží, problém není v profilu.

Co změnit a v jakém pořadí

Dále zkontrolujte přesunutou relaci. Dvě zařízení sdílející jeden certifikát se mohou navzájem vytlačit a výsledek vypadá periodicky, protože obě strany se pořád znovu připojují. Porovnejte záznamy relací typu point-to-site pro stejnou identitu, která se objevuje znovu a znovu.

Potom otestujte nečinnou cestu nepřetržitým provozem po několik minut. Pokud kapky přestanou, zatímco provoz teče, důležitý časovač patří zařízení NAT nebo vyvažovači zátěže na cestě, ne OpenVPN.

Nastavení brány by se mělo měnit až po těchto čtyřech testech.