OpenVPN koji se pokrene prije nego što mreža bude spremna nije neuspjeh

Pokrenete klijent pri dizanju sistema, jedinica prijavi da je aktivna, a tunela nema. Prirodan zaključak je da servis nije uspio da se pokrene, a prirodna popravka je da ga pokrenete ponovo. Oboje je dovoljno često pogrešno da vrijedi pravilo: klijent koji radi i ponavlja pokušaje izvana izgleda isto kao pokvaren. Razlika je u tome šta proces radi, a ne u stanju jedinice.

Mit: pokrenut servis 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. Zapakovan klijent može minutama sjediti u petlji pokušaja dok systemd prijavljuje samo uspjeh. Taj jaz između stanja i ponašanja je cijela tema.

Suprotan slučaj je jednako čest. Proces je možda izašao nakon što nije uspio pročitati ključ, a jedinica tada prijavljuje 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 neuspjeh

Razrješavanje imena i transportna ponavljanja su odvojene 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 bilo šta od toga promijenite.

Ništa od toga ne vrijedi za iskrivljeni profil, nečitljiv privatni ključ ili odbijen račun. Njima treba ispravka, 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 grešku.

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

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

Odredite koja komponenta posjeduje tunel prije nego što bilo š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.

Šta zapravo treba redoslijed

Redoslijed može čekati konfigurisanu adresu i to je sve što garantuje. network-online.target odgađa aktivaciju dok menadžer ne smatra mrežu podignutom, a definicija podignute zavisi od menadžera. Ne govori ništa o tome da li se VPN ime hosta razrješava, da li slušalac odgovara ili da li je zarobljeni portal pustio uređaj.

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

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

Šta se dešava nakon što se tunel prvi put podigne

Dizanje je jedan događaj među mnogima. Pristupni link se mijenja, sesija portala istječe, partner se restartuje. Razlikujte interno ponovno povezivanje od izlaska procesa kojim upravlja servisni menadžer, jer njih dvoje imaju različite vlasnike i ostavljaju različite dokaze.

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

Odvojeno odredite šta aplikacije smiju raditi dok je tunel pao. Ponavljanje vraća vezu, dok politika blokiranja odlučuje je li direktni saobraćaj dozvoljen u tom jazu.