De ce o unitate VPN pornește înainte de rețea și apoi moare

Porniți mașina, autentificați-vă și aflați că tunelul a urcat și a murit câteva secunde mai târziu. Profilul era în regulă, certificatul era în regulă, iar singura urmă rămasă este jurnalul acelei porniri. Ce s-a întâmplat de obicei este o cursă: unitatea a pornit înainte ca mașina să aibă o adresă, iar ordinea pe care o declara nu însemna ceea ce pare. Tot ce urmează este despre a dovedi acea cursă din dovezi și a o închide corect.

Ținta este un punct de întâlnire, nu un manager

network-online.target nu are habar ce este o rețea. Este un punct de coordonare care adună serviciul ce ar trebui să întârzie pornirea până când legătura devine utilizabilă, și deleagă definiția managerului de rețea care deține mașina. Pe majoritatea stațiilor de lucru și serverelor asta înseamnă un serviciu de așteptare furnizat de NetworkManager sau de systemd-networkd. Dacă nu activați niciunul, ținta nu are pe ce să aștepte, așa că se finalizează în momentul în care ceva o trage, ceea ce poate fi mult înainte ca DHCP să răspundă. Linia de ordonare din unitatea dvs. era sinceră și tot inutilă.

Prin urmare, prima întrebare nu este ce declară unitatea dvs. Ci dacă ceva de pe această mașină chiar face așteptarea.

Citiți ultima pornire, nu fișierul unității

Fișierele unităților descriu intenția, iar jurnalul descrie ce s-a întâmplat. Cereți doar acea pornire, cu marcaje de timp monotone, astfel încât fiecare mesaj să stea pe un singur ceas. Apoi găsiți două linii: momentul în care unitatea tunelului a început să pornească și momentul în care a apărut adresa sau s-a terminat serviciul de așteptare. Ordonați cele două numere și cursa este fie confirmată, fie exclusă.

Vizualizarea dependențelor confirmă acest lucru. Dacă un lanț critic pentru unitatea tunelului nu conține niciun serviciu de așteptare, nimic de pe acea cale nu a întârziat pornirea, iar ținta nu a făcut munca pe care ați presupus-o. Două vizualizări, o concluzie.

systemctl list-units --type=service --state=running | grep wait-online
journalctl -b -o short-monotonic -u openvpn-client@office

Adăugați așteptarea, apoi noua încercare

Folosiți un drop-in în loc să editați o unitate împachetată, pentru ca o actualizare de pachet să nu arunce schimbarea în tăcere. Două directive contează: unitatea trebuie ordonată după țintă și trebuie să tragă ținta în aceeași tranzacție. Doar ordinea nu invocă ținta; dorința o face.

Unitatea împachetată a clientului OpenVPN le poartă deja pe amândouă. Unitățile scrise de mână poartă de obicei una sau niciuna, ceea ce merită verificat înainte de a adăuga ceva.

[Service]
Restart=on-failure
RestartSec=15

De ce un somn fix este o capcană

Un somn în ExecStartPre pare o corecție de ordonare și se comportă ca o întârziere cu pași în plus. Încetinește fiecare pornire, inclusiv pe cele care erau sănătoase, și tot pierde când legătura durează mai mult decât numărul pe care l-ați ales.

Mai rău, ascunde dacă serviciul de așteptare funcționează, așa că următoarea defecțiune apare ca o problemă complet nouă, nu ca aceeași cu altă sincronizare. O întârziere scurtă de repornire este instrumentul mai bun: nu costă nimic la o pornire sănătoasă și transformă o cursă pierdută într-o altă încercare. Păstrați intervalul modest și lăsați unitatea să reușească. Dacă se repornește la nesfârșit, profilul este stricat și nicio cantitate de încercări nu va schimba asta, așa că citiți jurnalul în loc să măriți intervalul.

Când ordinea este corectă și numele tot eșuează

O unitate activă cu o rută de tunel înseamnă că ordonarea și-a făcut treaba și că defecțiunea rămasă este un nivel mai sus. Forma obișnuită este o setare de resolver aplicată de scriptul up al tunelului înainte ca legătura sau resolverul să fie gata să o păstreze. Comparați starea resolverului în timpul defecțiunii cu starea de după o repornire a unității tunelului.

Dacă repornirea repară căutările, aveți un defect de ordonare la pornire, nu un server DNS greșit, iar cele două necesită corecții diferite. Apoi dovediți totul cu o pornire la rece în loc de o repornire a serviciului, pentru că repornirea rulează împotriva unei rețele deja pornite și va ascunde exact defectul pe care îl urmăriți. Repetați cu legătura în mod deliberat lentă și tratați o unitate care funcționează doar când rețeaua este rapidă ca fiind încă stricată.