OpenVPN neće da se pokrene: čitajte prvi red, ne konfiguraciju

VPN koji umre u prvoj sekundi je druga životinja od onog koji se poveže pa onda padne, a uobičajena greška je tretirati ih kao isto. Ovde nema handshakea, nema razmene sertifikata i nema rute za pregled. Jedan red u dnevniku odlučuje koji od nekoliko nepovezanih popravki važi, a preskakanje tog reda košta pola dana uređivanja konfiguracije koja nikada nije pročitana. Pročitajte taj red prvi.

Tri komande samo za čitanje vode vas tamo: prvo journalctl -u openvpn@server -b --no-pager, zatim systemctl status openvpn@server, i ss -lunp za UDP osluškivače i njihove vlasnike.

Prvi red bira granu

Sukob portova i nedostajući binarni fajl oboje ubijaju pokretanje u roku od sekunde i ostavljaju različite prve redove. Poruka da je adresa već u upotrebi imenuje port; nedostajući izvršni fajl imenuje putanju koja više ne postoji; neispunjen uslov ili odsutan konfiguracioni fajl imenuje fajl. Ta tri vode ka različitim popravkama i nijedna se ne poboljšava reinstalacijom klijenta. Kopirajte prvi neuspeh u svoje beleške pre nego što pokrenete bilo šta drugo.

Pazite na petlju ponovnih pokušaja koja skriva originalni red. Unit sa politikom restarta može zakopati prvi neuspeh pod desetak identičnih, pa journalctl -b filtriran po unitu i čitan odozgo pobeđuje rep.

Ko još drži port 1194

Krivac obično nije drugi server koji je neko namerno podesio. Očekujte ručno pokrenut klijent koji je još živ u drugom terminalu, drugi profil koji je slučajno izabrao isti port, ili paket dobavljača čiji sopstveni tunel drži 1194. Vlasnik soketa se pojavljuje u ss -lunp; prosledite taj PID u systemctl status da saznate da li je odgovoran neki unit. Isključite ga kroz sopstvenu kontrolnu putanju, a ne signalom.

Signal procesu kojim upravlja unit obično izaziva restart i isti neuspeh se vraća nekoliko trenutaka kasnije kao novi problem. Koristite systemctl stop za unit, sopstvenu servisnu komandu paketa za instalaciju dobavljača, a signal samo za nešto što ste sami pokrenuli u tom shellu.

Zaostali uniti posle uklanjanja

Uklanjanje briše binarne fajlove; fajlovi unita pisani ručno, obično pod /etc/systemd/system, to preživljavaju. Systemd tada ponovo pokušava unit koji pokazuje na putanju koja više ne postoji, a poruka se tiče tog nedostajućeg fajla, a ne jučerašnjeg uklanjanja. systemctl status prikazuje putanju fragmenta unita pri vrhu, pa je proverite pomoću dpkg -S pre nego što bilo šta obrišete. Kada siroče nestane, systemctl daemon-reload i systemctl reset-failed čiste stanje; inače ga nasleđuje svaka kasnija provera statusa.

Kada which openvpn odgovori nečim pod /usr/local, binarni fajl u igri je došao od instalatera dobavljača, a ne od apt. Takav instalater obično donosi sopstveni osluškivač, sopstveni unos za podizanje i sopstveni direktorijum konfiguracije, pa uklanjanje vidljive komande ostavlja soket zauzetim.

Deinstalirajte ga onako kako dobavljač dokumentuje, potvrdite da je port slobodan pomoću ss -lunp i dodajte klijent iz distribucije samo ako vam treba.

Sredite stanje pre ponovnog pokušaja

Očistite neuspešno stanje pre nego što iz njega izvučete zaključke: systemctl reset-failed uklanja brojače, a systemctl status zatim prijavljuje trenutno stanje unita, a ne njegovu istoriju. Pokrenite ga jednom i čitajte dnevnik te instance, a ne zbirno stanje mašine. Unit koji prijavljuje aktivnost dok tunel ne nosi ništa je odvojen problem, i mnogo češći. Dvoje se spajaju u prijavama grešaka jer se oba završavaju korisnikovim rečima da VPN ne radi.

Zabeležite granu koju ste izabrali: sukob portova, nedostajući binarni fajl, nedostajuća konfiguracija. Sledeći put će se brže prepoznati.