Hindi bumubukas ang OpenVPN: basahin ang unang linya, hindi ang config

Ang VPN na namamatay sa unang segundo ay ibang hayop kaysa sa isang kumokonekta at pagkatapos ay nabibigo, at ang karaniwang pagkakamali ay ituring silang pareho. Walang handshake dito, walang palitan ng sertipiko at walang rutang susuriin. Isang linya sa journal ang nagpapasya kung alin sa ilang walang kaugnayang pag-aayos ang naaangkop, at ang paglaktaw dito ay nagkakahalaga ng isang hapon sa pag-edit ng config na hindi kailanman nabasa. Basahin muna ang linyang iyon.

May tatlong command na read-only na makakapagdala sa iyo doon: journalctl -u openvpn@server -b --no-pager muna, systemctl status openvpn@server pangalawa, at ss -lunp para sa mga tagapakinig ng UDP at sa kanilang mga may-ari.

Pinipili ng unang linya ang sangay

Ang banggaan ng port at kulang na binary ay parehong pumapatay sa pagsisimula sa loob ng isang segundo, at nag-iiwan sila ng magkaibang unang linya. Ang mensahe tungkol sa address na ginagamit na ay tumutukoy sa port; ang kulang na executable ay tumutukoy sa landas na wala na; ang nabigong kundisyon o kulang na config file ay tumutukoy sa file. Ang tatlong iyon ay humahantong sa magkaibang pag-aayos, at wala sa kanila ang bumubuti sa muling pag-install ng client. Kopyahin ang unang kabiguan sa iyong mga tala bago magpatakbo ng anumang iba.

Mag-ingat sa retry loop na nagtatago ng orihinal na linya. Ang isang unit na may patakaran sa restart ay maaaring maglibing sa unang kabiguan sa ilalim ng isang dosenang magkakatulad, kaya ang journalctl -b na sinasala ayon sa unit at binabasa mula sa itaas ay mas mabuti kaysa sa dulo.

Sino pa ang may hawak ng port 1194

Ang salarin ay karaniwang hindi isang pangalawang server na sinadyang i-configure ng isang tao. Asahan ang isang client na mano-manong sinimulan na buhay pa sa ibang terminal, isang pangalawang profile na nagkataong pumili ng parehong port, o isang bundle ng vendor na ang sariling tunnel ay may hawak ng 1194. Ang may-ari ng socket ay lumilitaw sa ss -lunp; ibigay ang PID na iyon sa systemctl status upang malaman kung may unit na responsable. Ipatumba ito sa sarili nitong daan ng kontrol, hindi gamit ang signal.

Ang signal sa isang prosesong pinamamahalaan ng unit ay karaniwang nag-uudyok ng restart, at ang parehong kabiguan ay muling lumilitaw makalipas ang ilang sandali na parang bagong problema. Gamitin ang systemctl stop para sa isang unit, ang sariling service command ng bundle para sa install ng vendor, at signal lamang para sa isang bagay na ikaw mismo ang nagsimula sa shell na iyon.

Mga natirang unit pagkatapos ng paglilinis

Ang paglilinis ay nagbubura ng mga binary; ang mga unit file na isinulat sa pamamagitan ng kamay, karaniwang nasa ilalim ng /etc/systemd/system, ay nakakaligtas dito. Muling susubukan ng Systemd ang isang unit na tumuturo sa landas na wala na, at ang mensahe ay tungkol sa nawawalang file na iyon sa halip na sa pagtanggal kahapon. systemctl status ay nagpapakita ng fragment path ng unit malapit sa itaas, kaya suriin ito gamit ang dpkg -S bago magbura ng kahit ano. Kapag wala na ang ulila, nililinis ng systemctl daemon-reload at systemctl reset-failed ang estado; kung hindi, minamana ito ng bawat susunod na pagsusuri ng estado.

Kapag ang which openvpn ay sumagot ng isang bagay sa ilalim ng /usr/local, ang binary na gumagana ay galing sa installer ng vendor at hindi sa apt. Ang ganitong installer ay karaniwang nagdadala ng sarili nitong tagapakinig, sariling boot entry at sariling direktoryo ng config, kaya ang pagtanggal ng nakikitang command ay nag-iiwan sa socket na okupado.

I-uninstall ito sa paraang dokumentado ng vendor, tiyakin na libre ang port gamit ang ss -lunp, at idagdag ang client ng distribusyon lamang kung kailangan mo ito.

Ayusin ang estado bago muling subukan

Linisin ang nabigong estado bago maghinuha mula rito: tinatanggal ng systemctl reset-failed ang mga counter, at pagkatapos ay iniuulat ng systemctl status ang kasalukuyang kalagayan ng unit sa halip na ang kasaysayan nito. Simulan ito nang isang beses at basahin ang journal ng mismong pagkakataong iyon sa halip na ang pinagsamang estado ng makina. Ang isang unit na nag-uulat na aktibo habang wala namang dinadala ang tunnel ay isang hiwalay na problema, at isang mas karaniwan. Ang dalawa ay pinagsasama sa mga ulat ng bug dahil pareho silang nagtatapos sa sinasabi ng user na hindi gumagana ang VPN.

Itala ang sangay na tinahak mo: banggaan ng port, kulang na binary, kulang na config. Ang susunod na pangyayari ay mas mabilis mong makikilala.