OpenVPN care pornește înainte ca rețeaua să fie sus nu este o defecțiune

Pornești clientul la boot, unitatea raportează activ, iar tunelul nu este acolo. Concluzia naturală este că serviciul nu a pornit, iar remedierea naturală este să îl pornești din nou. Ambele sunt greșite destul de des pentru a merita o regulă: un client care rulează și reîncearcă arată exact ca unul stricat din exterior. Diferența stă în ce face procesul, nu în starea unității.

Mit: un serviciu pornit înseamnă un tunel funcțional

O unitate activă dovedește că procesul a fost lansat și nu s-a încheiat. Nu dovedește că profilul s-a încărcat, că certificatul a fost acceptat sau că celălalt capăt a răspuns. Un client împachetat poate sta minute întregi într-o buclă de reîncercări, în timp ce systemd nu raportează decât succes. Acel gol dintre stare și comportament este întreaga temă.

Cazul opus este la fel de obișnuit. Procesul poate să fi ieșit după ce nu a putut citi o cheie, iar unitatea raportează apoi o stare de eșec care nu spune nimic despre motiv. Ambele stări au nevoie de jurnal pentru a fi distinse.

Citește jurnalul instanței, nu starea unității. Linia motivului este în jurnal, nu în eticheta de stare.

Mit: setările de reîncercare acoperă orice eșec

Rezolvarea numelor și reîncercările de transport sunt controale separate, cu valori implicite separate. resolv-retry guvernează căutările repetate ale unui nume de gazdă la distanță, iar valoarea implicită documentată încearcă la nesfârșit. connect-retry stabilește intervalul dintre încercări, în timp ce connect-retry-max poate limita de câte ori este încercată fiecare intrare la distanță. Verifică ce etapă numește jurnalul înainte de a schimba oricare dintre ele.

Nimic din toate acestea nu se aplică unui profil malformat, unei chei private ilizibile sau unui cont respins. Acelea au nevoie de o corectare, iar un client care le reîncearcă nu progresează.

Să reîncerci la nesfârșit un certificat neaprobat nu este un motiv să elimini verificarea. Este un motiv să citești eroarea.

Mit: un singur lansator e suficient, așa că adaugă altul

O conexiune deja gestionată de NetworkManager sau de o unitate împachetată nu are nevoie de un al doilea lansator atașat. Două procese care concurează pentru aceleași rute produc interfețe duplicate, jurnale confuze și un tunel care oscilează din motive pe care nimeni nu le vede. A doua copie apare de obicei ca soluție pentru că prima este lentă.

Decide ce componentă deține tunelul înainte de a adăuga ceva. Apoi elimină celălalt lansator în loc să îl dezactivezi și să speri.

Proprietarul determină și de unde vin reîncercările și acreditările, de aceea această decizie vine înaintea oricărei reglaje. Proprietatea vine prima exact din acest motiv.

Ce are într-adevăr nevoie de ordine

Ordinea poate aștepta o adresă configurată, și asta este tot ce garantează. network-online.target întârzie activarea până când managerul consideră rețeaua sus, iar definiția lui sus depinde de manager. Nu spune nimic despre dacă numele gazdei VPN se rezolvă, dacă ascultătorul răspunde sau dacă un portal captiv a admis dispozitivul.

Citește unitatea instalată și orice drop-in înainte de a adăuga dependențe. Un After= larg pe fiecare serviciu de rețea întârzie pornirea fără a stabili conexiunea de care ai nevoie cu adevărat.

Ordonează dependența pe care o poți testa și verifică tot restul cu o sondă de disponibilitate. O sondă care deschide tunelul învinge un cronometru care ghicește.

Ce se întâmplă după ce tunelul urcă prima dată

Pornirea este un eveniment printre multe altele. Legătura de acces se schimbă, o sesiune de portal expiră, partenerul repornește. Distinge o reconectare internă de o ieșire de proces gestionată de managerul de servicii, pentru că cele două au proprietari diferiți și lasă dovezi diferite.

Autentificarea interactivă limitează recuperarea nesupravegheată. O unitate de fundal nu deblochează un inel de chei de desktop și nu răspunde la o solicitare MFA, așa că urmează aranjamentul de acreditări aprobat pentru contextul serviciului.

Decide separat ce pot face aplicațiile în timp ce tunelul este căzut. Reîncercarea restaurează o conexiune, în timp ce o politică de blocare decide dacă traficul direct este permis în acel interval.