Cila instancë OpenVPN po përdor në të vërtetë profilin tënd PiVPN?

PiVPN shkruan një konfigurim serveri dhe një profil klienti, pastaj del; ai nuk bëhet kurrë procesi që mbart trafikun tënd. Prandaj një handshake i dështuar, një klient që thërret pikën e gabuar të fundit, ose një shërbim që kthehet gabim pas një rindezjeje nuk shpjegohen nga menytë e instaluesit. Këto simptoma i përkasin atij daemon-i OpenVPN që po punon tani, konfigurimit që ai daemon ngarkoi vërtet, dhe regjistrit ku u drejtua. Katër komanda vetëm-lexim zakonisht e zgjidhin, dhe asnjëra prej tyre nuk ndryshon certifikatat apo çelësat e tu.

Ndihmësi dhe daemon-i janë objekte të ndryshme

Konfuzioni shpjegohet lehtë: një drejtori mban skedarin që krijoi ndihmësi, skedarin që lexon daemon-i, dhe ndonjëherë një kopje të vjetër të të dyjave. Ndihmësi është një skript provizionimi. Instalon paketa, shkruan skedarë njësie dhe printon një profil klienti, dhe pastaj puna e tij mbaron. Ajo që mbetet është një zë në menaxherin e shërbimeve dhe një rresht komande.

Në një host systemd, fillo nga njësia aktive në vend të listës së drejtorisë. Emri varet nga paketimi: imazhet Debian dhe Raspberry Pi OS zakonisht ofrojnë një instancë shablloni si openvpn-server@server, ndërsa instalimet më të vjetra përdorin openvpn@server. Pyet menaxherin cila po punon në vend që ta hamendësosh nga emri i skedarit.

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

Lexo ExecStart= në atë dalje. Ai emërton ekzekutuesin dhe opsionet që menaxheri nis vërtet, duke përfshirë çdo --config shteg; një skedar konfigurimi aty pranë të cilin asnjë komandë nuk e referon nuk është pjesë e tunelit që punon.

Gjurmo zinxhirin e konfigurimit që zgjidhi daemon-i

OpenVPN nuk skanon një drejtori për cilësime. Lexon skedarin e kaluar me --config, ndjek çdo config direktivë brenda tij dhe pastaj zbaton opsionet e rreshtit të komandës. Manuali 2.6 përshkruan atë rend, dhe kjo ka rëndësi kur dy skedarë nuk bien dakord për portin, pajisjen ose shifrën.

Së pari nxirr thirrjen efektive, pastaj shiko direktivat që përcaktojnë identitetin dhe arritshmërinë. Të dyja komandat janë vetëm-lexim dhe të sigurta në një server të gjallë, ndonëse e dyta printon shtigje që mund të mos i duash në një biletë publike.

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

Një skedar .ovpn në një drejtori shtëpie është artefakt klienti. Daemon-i i serverit nuk e lexon kurrë, prandaj redaktimi i atij skedari për të rregulluar një dështim handshake në anën e serverit nuk arrin asgjë.

Inkluzionet janë kurthi tjetër. Një rresht config tërheq një skedar të dytë, opsionet e të cilit përpunohen në atë pikë, kështu që një direktivë e mëvonshme me një vlerë mund të mbivendoset mbi atë që skedari kryesor duket se thotë. Nëse skedari i dukshëm duket i saktë dhe daemon-i sillët ndryshe, lexo skedarin e përfshirë përpara se të ndryshosh ndonjë gjë.

Përputh regjistrin me procesin, jo me gabimin që mban mend

Dy destinacione regjistri janë të zakonshme, dhe vetëm njëri prej tyre është journal. Me log-append të vendosur, daemon-i shkruan në atë skedar dhe journal mban pak përveç rreshtave të nisjes. Pa atë, journalctl është burimi i ngjarjeve.

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

Lidh një përpjekje lidhjeje me një dritare kohore. Shëno pikën e fundit të klientit, pastaj lexo ngjarjet e serverit nga të njëjtat sekonda. Një handshake TLS që nuk arrin kurrë në shkëmbimin e certifikatave tregon arritshmëri ose mospërputhje protokolli, ndërsa një refuzim autentikimi vjen pasi parametrat e tunelit janë dakorduar tashmë.

Një zë i vjetër regjistri nuk provon asgjë për një profil që shkarkove pesë minuta më parë. Rigjenero skedarin e klientit, lidhu një herë dhe lexo vetëm rreshtat që u shfaqën gjatë asaj përpjekjeje.

Shëno dështimin e parë konkret, jo të fundit të përgjithshëm. Një gabim bind, një shkëmbim i jashtëm pa përgjigje, një refuzim certifikate dhe një refuzim llogarie të dërgojnë secili në një shtresë tjetër, dhe një afat kohor në fund shpesh fsheh ngjarjen e dobishme sipër.

Rindërtimi i tunelit nuk është hap diagnostikues

Rruga e shkurtër joshëse është të ngresh një tunel të dytë, më të thjeshtë: çelës statik, pa certifikata, pa autentikim shtesë. Shpesh do të lidhet, dhe provon vetëm se dy hoste mund të kalojnë UDP ose TCP mes tyre. Nuk thotë asgjë për arsyen pse dështon vendosja e autentikuar me certifikata, dhe zëvendëson në heshtje modelin e sigurisë që të kërkohej të mbahej.

E njëjta gjë vlen për çaktivizimin e tls-auth ose tls-crypt, lehtësimin e verify-x509-name, ose heqjen e një faktori të dytë për të marrë status jeshil. Një tunel që lidhet sepse verifikimi u hoq është një sistem tjetër, jo një i riparuar.

Bëj një ndryshim të vetëm të kufizuar në shtresën që emërtoi regjistri, rinis të njëjtën njësi dhe përsërit përpjekjen e vetme të lidhjes. Kjo e mban krahasimin të sinqertë, dhe lë një ndryshim që mund ta kthesh.

Çfarë t'i dorëzosh personit tjetër

Shkruaj katër fakte sa kohë i ke ende: versionin e OpenVPN nga openvpn --version, njësinë aktive, zinxhirin e konfigurimit me inkluzionet e tij dhe dritaren e regjistrit që mbulon një përpjekje. Ato katër e kthejnë një ankesë të paqartë në një rast të riprodhueshëm.

Redakto përpara se të ndash. Çelësat privatë, auth-user-pass skedarë, materiali i çelësit statik dhe paketat e plota të klientit nuk i përkasin një bilete; emrat e opsioneve dhe forma e zinxhirit zakonisht mjaftojnë për një palë sy të dytë.

Nëse zinxhiri është i paprekur dhe regjistri ende tregon rrjetin, hapi tjetër është rruga midis klientit dhe serverit në vend të një instalimi tjetër. Kjo është e vetmja pjesë e historisë që ndihmësi nuk e ka zotëruar kurrë.