OpenVPN nu pornește: citiți prima linie, nu configurația

Un VPN care moare în prima secundă este alt animal decât unul care se conectează și apoi eșuează, iar greșeala obișnuită este să le tratăm la fel. Aici nu există handshake, nici schimb de certificate și nici rută de examinat. O singură linie din journal decide care dintre mai multe reparații fără legătură se aplică, iar omiterea ei costă o după-amiază editând o configurație care nu a fost niciodată citită. Citiți acea linie mai întâi.

Trei comenzi doar-citire vă duc acolo: mai întâi journalctl -u openvpn@server -b --no-pager, apoi systemctl status openvpn@server, și ss -lunp pentru ascultătorii UDP și proprietarii lor.

Prima linie alege ramura

Un conflict de porturi și un binar lipsă ucid ambele pornirea într-o secundă, și lasă prime linii diferite. Un mesaj că adresa este deja folosită numește portul; un executabil lipsă numește o cale care nu mai există; o condiție eșuată sau un fișier de configurație absent numește fișierul. Acele trei duc la reparații diferite, și niciuna nu se îmbunătățește reinstalând clientul. Copiați primul eșec în notițe înainte de a rula orice altceva.

Urmăriți bucla de reîncercări care ascunde linia originală. O unitate cu o politică de repornire poate îngropa primul eșec sub o duzină de eșecuri identice, așa că journalctl -b filtrat după unitate și citit de sus bate coada.

Cine altcineva ține portul 1194

Vinovatul nu este de obicei un al doilea server configurat intenționat de cineva. Așteptați-vă la un client pornit manual încă viu într-un alt terminal, la un al doilea profil care a ales din întâmplare același port, sau la un pachet de furnizor al cărui tunel propriu ține 1194. Proprietarul socketului apare în ss -lunp; dați acel PID lui systemctl status pentru a afla dacă o unitate este responsabilă. Opriți-l prin propria cale de control, nu cu un semnal.

Un semnal către un proces gestionat de o unitate declanșează de obicei o repornire, iar același eșec reapare momente mai târziu ca o problemă nouă. Folosiți systemctl stop pentru o unitate, comanda de serviciu a pachetului însuși pentru o instalare de furnizor, și un semnal doar pentru ceva ce ați pornit singur în acel shell.

Unități rămase după o dezinstalare

O dezinstalare șterge binare; fișierele de unitate scrise manual, de obicei sub /etc/systemd/system, supraviețuiesc. Systemd încearcă apoi din nou o unitate care indică o cale ce nu mai există, iar mesajul privește acel fișier lipsă și nu eliminarea de ieri. systemctl status arată calea fragmentului unității aproape de partea de sus, așa că verificați-o cu dpkg -S înainte de a șterge ceva. Odată ce orfanul dispare, systemctl daemon-reload și systemctl reset-failed curăță starea; altfel fiecare verificare ulterioară de stare o moștenește.

Când which openvpn răspunde cu ceva sub /usr/local, binarul folosit a venit de la un instalator de furnizor și nu de la apt. Un astfel de instalator aduce de obicei propriul ascultător, propria intrare de boot și propriul director de configurație, așa că eliminarea comenzii vizibile lasă socketul ocupat.

Dezinstalați-l așa cum documentează furnizorul, confirmați că portul este liber cu ss -lunp, și adăugați clientul distribuției doar dacă aveți nevoie de el.

Puneți starea în ordine înainte de a reîncerca

Curățați starea de eșec înainte de a trage concluzii din ea: systemctl reset-failed elimină contoarele, iar systemctl status raportează apoi starea actuală a unității și nu istoricul ei. Porniți-o o dată și citiți journalul acelei rulări, nu starea agregată a mașinii. O unitate care raportează că este activă în timp ce tunelul nu transportă nimic este o problemă separată, și mult mai frecventă. Cele două se contopesc în rapoartele de erori pentru că ambele se termină cu utilizatorul spunând că VPN-ul nu funcționează.

Notați ramura pe care ați ales-o: conflict de porturi, binar lipsă, configurație lipsă. Data viitoare recunoașterea va fi mai rapidă.