OpenVPN: asocierea locală eșuează la pornire — așteptare sau reîncercare

Pentru un server OpenVPN care nu pornește la boot se oferă două soluții: așteptarea adresei sau lăsarea serviciului să reîncerce până când asocierea reușește. Ambele tratează același simptom cu un comportament de eșec diferit. Așteptarea codifică o precondiție precisă și eșuează zgomotos când aceasta lipsește; reîncercarea ascunde precondiția și continuă să încerce. Care dintre ele își are locul în unit-ul dvs. depinde de faptul dacă adresa este o dependență proiectată sau o întâmplare de timing.

Ambele sunt mai bune decât un sleep fix, care nu așteaptă nimic și nu raportează ce aștepta.

Ce cere de fapt opțiunea local

local numește adresa la care daemonul își asociază socketul, iar asocierea la o adresă care încă nu există eșuează imediat cu o eroare despre adresa solicitată. Când opțiunea lipsește, daemonul ascultă pe toate adresele, de aceea același profil funcționează pe o mașină a cărei interfață nu a urcat încă: ascultă peste tot în locul singurei adrese pe care ați numit-o. Această diferență este întregul eșec și rămâne invizibilă până la o repornire.

Cerința nu este ca interfața să fie activă într-un sens general. Adresa trebuie atribuită interfeței corecte în momentul asocierii și trebuie să fie interfața de bază, nu un tunel pe care același daemon l-ar crea mai târziu. O verificare făcută la câteva minute după autentificare nu dovedește nimic despre secvența de boot.

Așteptarea adresei sau reîncercarea asocierii

Așteptarea înseamnă un ExecStartPre care interoghează până când adresa apare, cu un număr limitat de încercări și o ieșire diferită de zero când timpul expiră. Reîncercarea înseamnă lăsarea procesului principal să eșueze și cererea ca managerul de servicii să îl pornească din nou, de exemplu Restart=on-failure cu RestartSec=5. Primul raportează o precondiție lipsă ca unit eșuat, în timp ce al doilea o raportează ca o serie de reporniri care se oprește în cele din urmă, ceea ce este mai zgomotos în jurnal dar supraviețuiește unei adrese care sosește târziu din motive pe care nu le puteți prevedea.

Preferați așteptarea când adresa este o dependență proiectată și reîncercarea când adresa apare de obicei dar timingul ei variază. Combinarea lor este rezonabilă: o așteptare limitată acoperă cazul obișnuit, iar o politică de repornire excepția. Ce nu ar trebui să facă niciuna este să ruleze la nesfârșit, pentru că un unit care reîncearcă fără sfârșit ascunde o configurație greșită în loc să o raporteze.

De ce network-online.target nu este suficient

network-online.target promite ceea ce implementarea de rețea activă înțelege prin online și nimic mai mult. Cu systemd-networkd, systemd-networkd-wait-online decide când este atins acel obiectiv, iar noțiunea sa implicită de online poate fi îndeplinită înainte ca adresa dvs. concretă să existe. Sub NetworkManager, serviciul wait-online aplică propriile reguli. Ordonarea după obiectiv este o bază solidă, nu o garanție că o adresă, un răspuns DNS sau un partener îndepărtat este gata.

Același raționament exclude alternativele obișnuite. O intrare de pornire automată de desktop așteaptă o sesiune de utilizator care poate nu se va deschide niciodată pe un server, iar o comandă cron întârziată adaugă timp scurs fără a numi resursa a cărei apariție o spera. Ambele pot părea reușite luni întregi și apoi pot eșua la singura pornire care contează.

Verificați asocierea după o pornire la rece

Verificați cu o pornire la rece reală, nu cu o repornire a serviciului, pentru că o repornire moștenește o adresă pe care secvența de boot a trebuit să o creeze. După pornire, ss -lntp sau ss -lunp arată adresa locală la care fiecare ascultător s-a asociat de fapt, iar journalctl -b -u openvpn-server@server arată dacă prima încercare a eșuat. Comparați adresa asociată cu cea din profil, apoi repetați comparația după o reconectare la rețea.

Dacă profilul nu a avut niciodată nevoie de o adresă fixă, eliminarea local este o simplificare legitimă, dar faceți din ea o decizie de securitate și nu un obicei de depanare.

Lărgirea ascultătorului schimbă cine poate ajunge la el, așa că asociați această schimbare cu politica de firewall care ar fi trebuit să îl restricționeze. Un serviciu care pornește fiabil pe fiecare interfață nu a rezolvat problema inițială; a mutat problema la marginea rețelei.