OpenVPN ne startas: legu la unuan linion, ne la agordon

VPN, kiu mortas en la unua sekundo, estas alia besto ol tiu, kiu konektiĝas kaj poste fiaskas, kaj la kutima eraro estas trakti ilin kiel la saman. Ĉi tie estas nek manpremo, nek interŝanĝo de atestiloj, nek vojo por ekzameni. Unu linio en la ĵurnalo decidas, kiu el pluraj sentrilataj riparoj validas, kaj preterpasi ĝin kostas posttagmezon da redaktado de agordo, kiu neniam estis legita. Legu tiun linion unue.

Tri nurlegaj komandoj kondukas vin tien: unue journalctl -u openvpn@server -b --no-pager, poste systemctl status openvpn@server, kaj ss -lunp por la UDP-aŭskultantoj kaj iliaj posedantoj.

La unua linio elektas la branĉon

Porda konflikto kaj mankanta binaraĵo ambaŭ mortigas la starton ene de sekundo, kaj ili lasas malsamajn unuajn liniojn. Mesaĝo, ke la adreso jam uziĝas, nomas la pordon; mankanta plenumebla dosiero nomas vojon, kiu ne plu ekzistas; fiaskinta kondiĉo aŭ mankanta agorda dosiero nomas la dosieron. Tiuj tri kondukas al malsamaj riparoj, kaj neniun el ili plibonigas reinstalo de la kliento. Kopiu la unuan fiaskon en viajn notojn antaŭ ol lanĉi ion ajn alian.

Atentu la ripetan buklon, kiu kaŝas la originan linion. Unuo kun restarta politiko povas enterigi la unuan fiaskon sub dekduo da identaj, do journalctl -b filtrita laŭ la unuo kaj legita de la supro venkas la voston.

Kiu alia tenas pordon 1194

La kulpulo kutime ne estas dua servilo, kiun iu intence agordis. Atendu permane lanĉitan klienton ankoraŭ vivan en alia terminalo, duan profilon, kiu hazarde elektis la saman pordon, aŭ vendistan pakaĵon, kies propra tunelo tenas 1194. La posedanto de la ingo aperas en ss -lunp; donu tiun PID al systemctl status por ekscii, ĉu unuo respondecas. Mallevu ĝin tra sia propra kontrola vojo anstataŭ per signalo.

Signalo al procezo administrata de unuo kutime kaŭzas restarton, kaj la sama fiasko reaperas momentojn poste kvazaŭ nova problemo. Uzu systemctl stop por unuo, la propran servokomandon de la pakaĵo por vendista instalo, kaj signalon nur por io, kion vi mem lanĉis en tiu ŝelo.

Restintaj unuoj post forigo

Forigo viŝas binaraĵojn; permane skribitaj unuodosieroj, kutime sub /etc/systemd/system, postvivas ĝin. Systemd tiam reprovos unuon montrantan al vojo, kiu ne plu ekzistas, kaj la mesaĝo temas pri tiu mankanta dosiero, ne pri la hieraŭa forigo. systemctl status montras la fragmentan vojon de la unuo supre, do kontrolu ĝin per dpkg -S antaŭ ol forigi ion ajn. Post kiam la orfo malaperis, systemctl daemon-reload kaj systemctl reset-failed purigas la staton; alie ĉiu posta statokontrolo heredas ĝin.

Kiam which openvpn respondas per io sub /usr/local, la koncerna binaraĵo venis de vendista instalilo, ne de apt. Tia instalilo kutime alportas sian propran aŭskultanton, sian propran startan rikordon kaj sian propran agordan dosierujon, do forigi la videblan komandon lasas la ingon okupita.

Malinstalu ĝin per tio, kion la vendisto dokumentas, konfirmu, ke la pordo estas libera per ss -lunp, kaj aldonu la klienton de la distribuo nur se vi bezonas ĝin.

Ordigu la staton antaŭ ol reprovi

Purigu la fiaskan staton antaŭ ol tiri konkludojn el ĝi: systemctl reset-failed forigas la nombrilojn, kaj systemctl status tiam raportas la nunan staton de la unuo, ne ĝian historion. Lanĉu ĝin unufoje kaj legu la ĵurnalon de tiu ekzakta okazo, ne la agregatan staton de la maŝino. Unuo, kiu raportas sin aktiva dum la tunelo portas nenion, estas aparta problemo, kaj multe pli ofta. La du kunfandiĝas en cimraportoj ĉar ambaŭ finiĝas per la uzanto diranta, ke la VPN ne funkcias.

Notu la branĉon, kiun vi prenis: porda konflikto, mankanta binaraĵo, mankanta agordo. La venontan fojon estos pli rapide rekoni ĝin.