OpenVPN koji kreće prije mreže nije kvar

Pokrenete klijent pri podizanju, unit prijavljuje aktivno, a tunela nema. Prirodan zaključak je da servis nije startao, a prirodan popravak je pokrenuti ga ponovno. Oboje je dovoljno često pogrešno da zaslužuje pravilo: klijent koji radi i ponavlja pokušaje izvana izgleda točno kao pokvaren. Razlika je u tome što proces radi, a ne u stanju unita.

Mit: pokrenut servis znači tunel koji radi

Aktivan unit dokazuje da je proces pokrenut i da nije izašao. Ne dokazuje da se profil učitao, da je certifikat prihvaćen ili da je druga strana odgovorila. Upakirani klijent može minutama sjediti u petlji pokušaja dok systemd ne izvještava ništa osim uspjeha. Taj jaz između stanja i ponašanja je cijela tema.

Suprotan slučaj jednako je čest. Proces je mogao izaći nakon što nije uspio pročitati ključ, a unit tada prijavljuje stanje neuspjeha koje ne govori zašto. Za razlikovanje oba stanja potreban je dnevnik.

Čitajte dnevnik instance, a ne stanje unita. Redak razloga je u dnevniku, a ne u oznaci stanja.

Mit: postavke ponavljanja pokrivaju svaki kvar

Rješavanje imena i ponavljanja prijenosa odvojeni su upravljači s odvojenim zadanim vrijednostima. resolv-retry upravlja ponovljenim pretragama udaljenog imena hosta, a dokumentirana zadana vrijednost pokušava beskonačno. connect-retry postavlja razmak između pokušaja, dok connect-retry-max može ograničiti koliko se puta pokušava svaki udaljeni unos. Provjerite koji stupanj dnevnik navodi prije nego bilo što od toga promijenite.

Ništa od toga ne vrijedi za iskrivljeni profil, nečitljiv privatni ključ ili odbijen račun. Njima treba ispravak, a klijent koji ih stalno ponavlja ne napreduje.

Beskonačno ponavljanje neodobrenog certifikata nije razlog za uklanjanje provjere. To je razlog da pročitate grešku.

Mit: jedan pokretač je dovoljan, pa dodajte još jedan

Veza kojom već upravlja NetworkManager ili upakirani unit ne treba drugi pokretač. Dva procesa koja se natječu za iste rute stvaraju dvostruka sučelja, zbunjujuće dnevnike i tunel koji treperi zbog razloga koje nitko ne vidi. Druga kopija obično dolazi kao zaobilazno rješenje jer je prva spora.

Odlučite koji komponent ima vlasništvo nad tunelom prije nego što bilo što dodate. Zatim uklonite drugi pokretač umjesto da ga onemogućite i nadate se.

Vlasnik određuje i odakle dolaze ponavljanja i vjerodajnice, zato ova odluka dolazi prije bilo kakvog podešavanja. Vlasništvo je prvo upravo iz tog razloga.

Što stvarno treba redoslijed

Redoslijed može čekati konfiguriranu adresu, i to je sve što jamči. network-online.target odgađa aktivaciju dok upravitelj ne smatra mrežu podignutom, a definicija podignute ovisi o upravitelju. Ne govori ništa o tome rješava li se ime hosta VPN-a, odgovara li slušatelj ili je li portal s prijavom pustio uređaj.

Pročitajte instalirani unit i sve drop-in datoteke prije nego dodate ovisnosti. Široki After= na svakom mrežnom servisu odgađa podizanje bez uspostavljanja veze koja vam stvarno treba.

Poredajte ovisnost koju možete testirati, a sve ostalo provjerite sondom spremnosti. Sonda koja otvara tunel pobjeđuje tajmer koji nagađa.

Što se događa nakon što se tunel prvi put podigne

Podizanje je jedan događaj među mnogima. Pristupna veza se mijenja, sesija portala istječe, partner se ponovno pokreće. Razlikujte unutarnje ponovno spajanje od izlaska procesa koji rješava upravitelj servisa, jer njih dvoje imaju različite vlasnike i ostavljaju različite dokaze.

Interaktivna autentifikacija ograničava oporavak bez nadzora. Pozadinski unit ne otključava privjesak ključeva radne površine i ne odgovara na MFA upit, zato slijedite odobreni raspored vjerodajnica za kontekst servisa.

Odvojeno odlučite što aplikacije smiju raditi dok je tunel pao. Ponavljanje vraća vezu, dok politika blokiranja odlučuje je li izravni promet dopušten u tom jazu.