OpenVPN spuštěné před připraveností sítě není selhání

Klienta spustíte při bootu, jednotka hlásí aktivní stav a tunel nikde. Přirozený závěr je, že služba se nenastartovala, a přirozená oprava je spustit ji znovu. Obojí je dost často špatně, aby stálo za pravidlo: běžící klient, který to zkouší znovu, vypadá zvenku přesně jako rozbitý. Rozdíl je v tom, co proces dělá, ne ve stavu jednotky.

Mýtus: spuštěná služba znamená funkční tunel

Aktivní jednotka dokazuje, že proces byl spuštěn a neskončil. Nedokazuje, že se načetl profil, že byl přijat certifikát nebo že protistrana odpověděla. Zabalený klient může minuty sedět ve smyčce opakování, zatímco systemd hlásí jen úspěch. Tahle mezera mezi stavem a chováním je celé téma.

Opačný případ je stejně častý. Proces mohl skončit poté, co nedokázal přečíst klíč, a jednotka pak hlásí selhaný stav, který nic neříká o příčině. K rozlišení obou stavů je potřeba log.

Čtěte journal pro danou instanci, ne stav jednotky. Řádek s důvodem je v logu, ne ve štítku stavu.

Mýtus: nastavení opakování pokryje každé selhání

Překlad jmen a transportní opakování jsou samostatné ovládací prvky se samostatnými výchozími hodnotami. resolv-retry řídí opakované dotazy na vzdálené jméno hostitele a dokumentovaná výchozí hodnota zkouší donekonečna. connect-retry nastavuje interval mezi pokusy, zatímco connect-retry-max může omezit, kolikrát se každý vzdálený záznam zkusí. Než cokoli z toho změníte, zjistěte, kterou fázi log pojmenovává.

Nic z toho neplatí pro poškozený profil, nečitelný soukromý klíč nebo odmítnutý účet. Ty potřebují opravu a klient, který je pořád zkouší, nepostupuje.

Nekonečné opakování u neschváleného certifikátu není důvod odebrat ověřování. Je to důvod si přečíst chybu.

Mýtus: jeden spouštěč stačí, tak přidejte další

Připojení, které už spravuje NetworkManager nebo balíčkovaná jednotka, nepotřebuje druhý spouštěč. Dva procesy soutěžící o stejné trasy vytvářejí duplicitní rozhraní, matoucí logy a tunel, který kmitá z důvodů, které nikdo nevidí. Druhá kopie obvykle přichází jako obejití toho, že první je pomalá.

Rozhodněte, která komponenta tunel vlastní dřív, než cokoli přidáte. Pak druhý spouštěč odstraňte, místo abyste ho vypínali a doufali.

Vlastník také určuje, odkud přicházejí opakování a přihlašovací údaje, a proto toto rozhodnutí předchází každému ladění. Vlastnictví je první právě z tohoto důvodu.

Co skutečně potřebuje pořadí

Pořadí může počkat na nakonfigurovanou adresu, a to je vše, co zaručuje. network-online.target odkládá aktivaci, dokud správce nepovažuje síť za připravenou, a definice připravenosti závisí na správci. Neříká nic o tom, zda se jméno VPN přeloží, zda naslouchající strana odpoví nebo zda zajatý portál zařízení pustil.

Před přidáním závislostí si přečtěte nainstalovanou jednotku a všechny drop-in soubory. Široké After= na každé síťové službě odkládá boot, aniž by navázalo připojení, které skutečně potřebujete.

Seřaďte závislost, kterou umíte otestovat, a vše ostatní ověřte sondou připravenosti. Sonda, která otevře tunel, je lepší než časovač, který hádá.

Co se děje poté, co tunel poprvé naskočí

Boot je jedna událost z mnoha. Přístupové spojení se mění, relace portálu vyprší, protějšek restartuje. Rozlišujte vnitřní opětovné připojení od ukončení procesu, které řeší správce služeb, protože obě mají různé vlastníky a zanechávají různé důkazy.

Interaktivní autentizace omezuje obnovu bez dozoru. Jednotka na pozadí neodemkne klíčenku na ploše ani neodpoví na výzvu MFA, proto dodržte schválené uspořádání přihlašovacích údajů pro kontext služby.

Zvlášť rozhodněte, co smějí aplikace dělat, dokud je tunel dole. Opakování obnoví spojení, zatímco blokovací politika rozhoduje, zda je v té mezeře povolen přímý provoz.