OpenVPN spustený pred sieťou nie je porucha

Klienta spustíte pri bootovaní, jednotka hlási aktívny stav a tunel nie je. Prirodzený záver je, že služba nenabehla, a prirodzená oprava je spustiť ju znova. Oboje je dosť často nesprávne, aby si zaslúžilo pravidlo: bežiaci klient, ktorý skúša znova, vyzerá zvonku presne ako pokazený. Rozdiel je v tom, čo proces robí, nie v stave jednotky.

Mýtus: spustená služba znamená fungujúci tunel

Aktívna jednotka dokazuje, že proces bol spustený a neskončil. Nedokazuje, že sa profil načítal, že certifikát bol prijatý alebo že druhý koniec odpovedal. Zabalení klient môže minúty sedieť v slučke opakovaní, kým systemd nehlási nič okrem úspechu. Tá medzera medzi stavom a správaním je celá téma.

Opačný prípad je rovnako bežný. Proces mohol skončiť po tom, čo nedokázal prečítať kľúč, a jednotka potom hlási stav zlyhania, ktorý nič nehovorí o príčine. Oba stavy potrebujú log, aby sa dali rozlíšiť.

Čítajte journal tejto inštancie, nie stav jednotky. Riadok s príčinou je v logu, nie v označení stavu.

Mýtus: nastavenia opakovania pokrývajú každé zlyhanie

Rozlišovanie mien a opakovania transportu sú samostatné ovládače so samostatnými predvolenými hodnotami. resolv-retry riadi opakované vyhľadávania vzdialeného mena hostiteľa a dokumentovaná predvolená hodnota skúša donekonečna. connect-retry určuje interval medzi pokusmi, kým connect-retry-max môže obmedziť, koľkokrát sa každý vzdialený záznam skúsi. Pred zmenou ktoréhokoľvek z nich skontrolujte, ktorú fázu log uvádza.

Nič z toho neplatí na poškodený profil, nečitateľný súkromný kľúč ani odmietnutý účet. Tie potrebujú opravu a klient, ktorý ich stále opakuje, nepostupuje.

Opakovať neschválený certifikát donekonečna nie je dôvod odstrániť overovanie. Je to dôvod prečítať si chybu.

Mýtus: jeden spúšťač stačí, tak pridajte ďalší

Pripojenie, ktoré už spravuje NetworkManager alebo zabalená jednotka, nepotrebuje druhý spúšťač. Dva procesy súťažiace o rovnaké trasy vytvárajú duplicitné rozhrania, mätúce logy a tunel, ktorý preblikáva z dôvodov, ktoré nikto nevidí. Druhá kópia zvyčajne prichádza ako obchádzka pre pomalosť prvej.

Rozhodnite, ktorý komponent vlastní tunel, skôr než čokoľvek pridáte. Potom odstráňte druhý spúšťač, namiesto toho, aby ste ho vypli a dúfali.

Vlastník určuje aj to, odkiaľ prichádzajú opakovania a prihlasovacie údaje, preto toto rozhodnutie prichádza pred akýmkoľvek ladením. Vlastníctvo je prvé práve z tohto dôvodu.

Čo skutočne potrebuje poradie

Poradie môže čakať na nakonfigurovanú adresu a to je všetko, čo zaručuje. network-online.target odkladá aktiváciu, kým správca nepovažuje sieť za pripravenú, a definícia pripravenosti závisí od správcu. Nehovorí nič o tom, či sa meno hostiteľa VPN rozlišuje, či poslucháč odpovedá alebo či portál s prihlásením pustil zariadenie dnu.

Prečítajte si nainštalovanú jednotku a všetky drop-in súbory, skôr než pridáte závislosti. Široký After= na každej sieťovej službe odkladá boot bez toho, aby vytvoril pripojenie, ktoré skutočne potrebujete.

Zoraďte závislosť, ktorú viete otestovať, a všetko ostatné overte sondou pripravenosti. Sonda, ktorá otvorí tunel, porazí časovač, ktorý háda.

Čo sa deje po prvom zdvihnutí tunela

Boot je jedna udalosť z mnohých. Prístupové spojenie sa mení, relácia portálu vyprší, partner sa reštartuje. Odlíšte interné opätovné pripojenie od ukončenia procesu, ktoré spracúva správca služieb, pretože tie dve majú iných vlastníkov a zanechávajú iné dôkazy.

Interaktívna autentifikácia obmedzuje obnovu bez dozoru. Jednotka na pozadí neodomkne kľúčenku pracovnej plochy a neodpovie na výzvu MFA, preto dodržte schválené usporiadanie prihlasovacích údajov pre kontext služby.

Oddelene rozhodnite, čo aplikácie smú robiť, kým je tunel dole. Opakovanie obnoví pripojenie, kým politika blokovania rozhoduje, či je v tej medzere povolená priama prevádzka.