OpenVPN koji se pokrene prije mreže nije kvar

Pokrenete klijent pri dizanju sustava, jedinica javlja da je aktivna, a tunela nema. Prirodan zaključak je da se usluga nije uspjela pokrenuti, a prirodna popravka je pokrenuti je ponovno. Oboje je dovoljno često pogrešno da zavrijedi pravilo: klijent koji radi i ponavlja pokušaje izvana izgleda jednako kao pokvaren. Razlika je u tome što proces radi, a ne u stanju jedinice.

Mit: pokrenuta usluga znači tunel koji radi

Aktivna jedinica dokazuje da je proces pokrenut i da nije izašao. Ne dokazuje da je profil učitan, certifikat prihvaćen ili da je druga strana odgovorila. Zapakirani klijent može minutama sjediti u petlji pokušaja dok systemd javlja samo uspjeh. Taj jaz između stanja i ponašanja cijela je tema.

Suprotan slučaj jednako je čest. Proces je možda izašao nakon što nije uspio pročitati ključ, a jedinica tada javlja neuspjelo stanje koje ne govori zašto. Za razlikovanje oba stanja potreban je dnevnik.

Čitajte dnevnik za instancu, a ne stanje jedinice. Redak s razlogom je u dnevniku, ne na oznaci stanja.

Mit: postavke ponavljanja pokrivaju svaki kvar

Rješavanje imena i transportna ponavljanja odvojene su kontrole s odvojenim zadanim vrijednostima. resolv-retry upravlja ponovljenim pretragama udaljenog imena hosta, a dokumentirana zadana vrijednost pokušava beskonačno. connect-retry postavlja interval između pokušaja, dok connect-retry-max može ograničiti koliko se puta pokušava svaki udaljeni zapis. Provjerite koju fazu dnevnik navodi prije nego što ikoju od njih 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 iznova pokušava ne napreduje.

Beskrajno ponavljanje pokušaja s neodobrenim certifikatom nije razlog da uklonite provjeru. To je razlog da pročitate pogrešku.

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

Veza kojom već upravlja NetworkManager ili zapakirana jedinica ne treba drugi pokretač priključen na nju. Dva procesa koja se natječu za iste rute stvaraju dvostruka sučelja, zbunjujuće dnevnike i tunel koji treperi iz razloga koje nitko ne vidi. Drugi primjerak obično dolazi kao zaobilazno rješenje zato što je prvi spor.

Odlučite koja komponenta posjeduje tunel prije nego što išta dodate. Zatim uklonite drugi pokretač umjesto da ga onemogućite i nadate se.

Vlasnik također određuje odakle dolaze ponavljanja i vjerodajnice, zato ova odluka prethodi svakom podešavanju. Vlasništvo je prvo upravo zbog tog razloga.

Što zapravo 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 razrješava li se VPN ime hosta, odgovara li slušatelj ili je li zarobljeni portal pustio uređaj.

Pročitajte instaliranu jedinicu i sve drop-in datoteke prije nego što dodate ovisnosti. Široki After= na svakoj mrežnoj usluzi odgađa dizanje bez uspostavljanja veze koja vam zapravo treba.

Poredajte ovisnost koju možete testirati, a sve ostalo provjerite probom spremnosti. Proba koja otvara tunel bolja je od mjerača vremena koji nagađa.

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

Dizanje je jedan događaj među mnogima. Pristupna veza se mijenja, sesija portala istječe, partner se restartira. Razlikujte interno ponovno povezivanje od izlaska procesa kojim upravlja upravitelj usluga, jer njih dvoje imaju različite vlasnike i ostavljaju različite dokaze.

Interaktivna autentifikacija ograničava oporavak bez nadzora. Pozadinska jedinica ne otključava privjesak s ključevima radne površine i ne odgovara na MFA upit, zato slijedite odobreni raspored vjerodajnica za kontekst usluge.

Odvojeno odredite š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.