Aling instance ng OpenVPN ang talagang gumagamit ng iyong PiVPN profile?

Nagwawrite ang PiVPN ng server configuration at client profile, pagkatapos ay lumalabas; hindi ito kailanman nagiging prosesong nagdadala ng iyong traffic. Kaya ang bigong handshake, kliyenteng tumatawag sa maling endpoint, o serbisyong bumabalik nang mali pagkatapos ng reboot ay hindi maipapaliwanag mula sa mga menu ng installer. Ang mga sintomas na iyon ay pag-aari ng daemon ng OpenVPN na tumatakbo ngayon, ng configuration na aktuwal na ni-load ng daemon na iyon, at ng log kung saan ito itinuro. Apat na read-only na utos ang karaniwang nag-aayos nito, at wala sa mga ito ang nagbabago ng iyong mga certificate o key.

Ang helper at ang daemon ay magkaibang bagay

Madaling ipaliwanag ang kalituhan: isang direktoryo ang may file na ginawa ng helper, file na binabasa ng daemon, at kung minsan ay lumang kopya ng dalawa. Ang helper ay isang provisioning script. Nag-iinstall ito ng mga package, nagsusulat ng unit file at nagpi-print ng client profile, at pagkatapos ay tapos na ang trabaho nito. Ang natitira ay isang entry sa service manager at isang command line.

Sa isang systemd host, magsimula sa aktibong unit sa halip na sa listahan ng direktoryo. Depende ang pangalan sa packaging: ang mga image ng Debian at Raspberry Pi OS ay karaniwang naglalabas ng template instance tulad ng openvpn-server@server, samantalang ang mas lumang mga install ay gumagamit ng openvpn@server. Itanong sa manager kung alin ang tumatakbo sa halip na hulaan mula sa pangalan ng file.

systemctl list-units --type=service --all | grep -i openvpn
systemctl cat openvpn-server@server

Basahin ExecStart= sa output na iyon. Pinangalanan nito ang executable at ang mga opsiyon na aktuwal na inilulunsad ng manager, kabilang ang anumang --config path; ang configuration file sa tabi nito na walang command na tumutukoy ay hindi bahagi ng tumatakbong tunnel.

Subaybayan ang config chain na ni-resolve ng daemon

OpenVPN ay hindi nag-i-scan ng direktoryo para sa mga setting. Binabasa nito ang file na ipinasa gamit ang --config, sinusundan ang anumang config directive sa loob nito, at pagkatapos ay inilalapat ang mga opsiyon ng command line. Inilalarawan ng manual 2.6 ang pagkakasunod-sunod na iyon, at mahalaga ito kapag hindi magkasundo ang dalawang file tungkol sa port, device o cipher.

I-dump muna ang aktuwal na invocation, pagkatapos ay tingnan ang mga directive na nagpapasya sa identity at reachability. Parehong read-only ang dalawang utos at ligtas sa isang live na server, kahit na ang pangalawa ay nagpi-print ng mga path na baka ayaw mo sa pampublikong ticket.

systemctl show -p ExecStart --value openvpn-server@server
grep -E '^(config|dev|proto|port|local|log|log-append|status|ca|cert|key|tls-auth|tls-crypt)' /etc/openvpn/server/server.conf

Ang file na .ovpn sa home directory ay client artifact. Hindi ito binabasa ng server daemon, kaya ang pag-edit sa file na iyon upang ayusin ang bigong handshake sa panig ng server ay walang naaabot.

Ang mga include ang isa pang bitag. Ang isang config na linya ay humihila ng pangalawang file na ang mga opsiyon ay pinoproseso sa puntong iyon, kaya ang mas huling single-value na directive ay maaaring mangibabaw sa sinasabi ng pangunahing file. Kung mukhang tama ang nakikitang file at iba pa rin ang kilos ng daemon, basahin ang kasamang file bago magbago ng anuman.

Itugma ang log sa proseso, hindi sa error na naaalala mo

Dalawang log destination ang karaniwan, at isa lang sa mga ito ang journal. Kapag nakatakda ang log-append, nagsusulat ang daemon sa file na iyon at kakaunti lang ang itinatago ng journal bukod sa startup lines. Kung wala ito, journalctl ang pinagmulan ng mga event.

journalctl -u openvpn-server@server -n 80 --no-pager

Iugnay ang isang pagtatangkang kumonekta sa isang time window. Itala ang endpoint ng kliyente, pagkatapos ay basahin ang mga server event mula sa parehong mga segundo. Ang TLS handshake na hindi kailanman nakarating sa exchange ng certificate ay tumutukoy sa reachability o hindi pagkakatugma ng protocol, samantalang ang pagtanggi sa authentication ay dumarating pagkatapos ng kasunduan sa mga parameter ng tunnel.

Walang pinapatunayan ang lumang log entry tungkol sa profile na na-download mo limang minuto ang nakalipas. Muling buuin ang client file, kumonekta nang isang beses, at basahin lamang ang mga linyang lumitaw sa pagtatangkang iyon.

Itala ang unang partikular na failure, hindi ang huling pangkalahatan. Ang bind error, walang sagot na panlabas na exchange, pagtanggi sa certificate at pagtanggi sa account ay bawat isa ay nagdadala sa iyo sa ibang layer, at madalas itinatago ng timeout sa dulo ang kapaki-pakinabang na event sa itaas.

Ang muling pagbuo ng tunnel ay hindi diagnostic na hakbang

Ang nakatutuksong shortcut ay magtayo ng pangalawa, mas simpleng tunnel: static key, walang certificate, walang karagdagang authentication. Madalas itong kumonekta, at pinapatunayan lamang na dalawang host ang makakapagpadala ng UDP o TCP sa isa't isa. Wala itong sinasabi tungkol sa dahilan ng pagbigo ng deployment na may certificate, at tahimik nitong pinapalitan ang security model na hiniling sa iyong panatilihin.

Ganoon din sa tls-auth o tls-crypt, pagluwag sa verify-x509-name, o pagtapon sa pangalawang factor para makakuha ng berdeng status. Ang tunnel na kumokonekta dahil inalis ang verification ay ibang sistema, hindi isang naayos.

Gumawa ng isang limitadong pagbabago sa layer na pinangalanan ng log, i-restart ang parehong unit, at ulitin ang nag-iisang pagtatangka kumonekta. Pinapanatili nitong tapat ang paghahambing, at nag-iiwan ito ng pagbabagong maaari mong ibalik.

Ano ang ipapasa sa susunod na tao

Isulat ang apat na katotohanan habang hawak mo pa ang mga ito: ang bersyon ng OpenVPN mula sa openvpn --version, ang aktibong unit, ang config chain kasama ang mga include nito, at ang log window na sumasaklaw sa isang pagtatangka. Ang apat na iyon ay ginagawang reproducible case ang malabong reklamo.

I-redact bago magbahagi. Ang mga private key, auth-user-pass na file, static key material at kumpletong client bundle ay hindi kabilang sa ticket; sapat na karaniwan ang mga pangalan ng opsiyon at hugis ng chain para sa pangalawang pares ng mata.

Kung buo ang chain at nakaturo pa rin ang log sa network, ang susunod na hakbang ay ang landas sa pagitan ng client at server sa halip na isa pang install. Iyon ang tanging bahagi ng kuwento na hindi kailanman pag-aari ng helper.