Kuri OpenVPN instancija iš tikrųjų naudoja tavo PiVPN profilį?

PiVPN įrašo serverio konfigūraciją ir kliento profilį, tada baigia darbą; jis niekada netampa procesu, kuris perduoda tavo srautą. Todėl nepavykusio rankos paspaudimo, netinkamą galinį tašką renkančio kliento ar po perkrovimo netinkamai grįžtančios paslaugos negalima paaiškinti diegėjo meniu. Šie simptomai priklauso tam OpenVPN demonui, kuris dabar veikia, konfigūracijai, kurią tas demonas faktiškai įkėlė, ir žurnalui, į kurį buvo nukreiptas. Keturios tik skaitymo komandos paprastai tai išsprendžia, ir nė viena jų nekeičia tavo sertifikatų ar raktų.

Pagalbinė priemonė ir demonas yra skirtingi objektai

Sumaištį lengva paaiškinti: viename kataloge yra failas, kurį sukūrė pagalbinė priemonė, failas, kurį skaito demonas, o kartais ir pasenusi abiejų kopija. Pagalbinė priemonė yra parengimo scenarijus. Ji įdiegia paketus, įrašo įrenginio failus ir atspausdina kliento profilį, tada jos darbas baigiasi. Lieka įrašas paslaugų tvarkyklėje ir komandų eilutė.

systemd hoste pradėk nuo aktyvaus įrenginio, o ne nuo katalogo sąrašo. Pavadinimas priklauso nuo pakavimo: Debian ir Raspberry Pi OS atvaizdai paprastai pateikia šablono egzempliorių, pavyzdžiui, openvpn-server@server, o senesni įdiegimai naudoja openvpn@server. Paklausk tvarkyklės, kuris veikia, o ne spėliok iš failo pavadinimo.

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

Perskaityk ExecStart= toje išvestyje. Jis nurodo vykdomąjį failą ir parinktis, kurias tvarkyklė iš tikrųjų paleidžia, įskaitant bet kokį --config kelią; netoliese gulintis konfigūracijos failas, į kurį nenurodo nė viena komanda, nėra veikiančio tunelio dalis.

Sek konfigūracijos grandinę, kurią išsprendė demonas

OpenVPN neskaito katalogo ieškodamas nustatymų. Jis skaito failą, perduotą su --config, seka visas config direktyvas jame ir tada taiko komandų eilutės parinktis. Vadovas 2.6 aprašo tą tvarką, ir tai svarbu, kai du failai nesutaria dėl prievado, įrenginio ar šifro.

Pirmiausia išvesk faktinį iškvietimą, tada pažiūrėk į direktyvas, kurios nustato tapatybę ir pasiekiamumą. Abi komandos yra tik skaitymo ir saugios veikiančiame serveryje, nors antroji atspausdina kelius, kurių galbūt nenorėtum viešame biliete.

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

Failas .ovpn namų kataloge yra kliento artefaktas. Serverio demonas jo niekada neskaito, todėl to failo redagavimas siekiant ištaisyti serverio pusės rankos paspaudimo gedimą nieko neduoda.

Įtraukimai yra kita gaudyklė. Eilutė config įtraukia antrą failą, kurio parinktys apdorojamos toje vietoje, todėl vėlesnė vienos reikšmės direktyva gali nepaisyti to, ką tarsi sako pagrindinis failas. Jei matomas failas atrodo teisingai, o demonas vis tiek elgiasi kitaip, perskaityk įtrauktą failą prieš ką nors keisdamas.

Susiek žurnalą su procesu, o ne su klaida, kurią prisimeni

Dvi žurnalo paskirties vietos yra įprastos, ir tik viena jų yra journal. Kai log-append nustatytas, demonas rašo į tą failą, o journal saugo mažai, išskyrus paleidimo eilutes. Be jo journalctl yra įvykių šaltinis.

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

Susiek vieną prisijungimo bandymą su vienu laiko intervalu. Užsirašyk kliento galinį tašką, tada skaityk serverio įvykius iš tų pačių sekundžių. TLS rankos paspaudimas, kuris niekada nepasiekia sertifikatų mainų, rodo pasiekiamumą arba protokolo neatitikimą, o autentifikavimo atmetimas ateina po to, kai tunelio parametrai jau suderinti.

Senas žurnalo įrašas nieko neįrodo apie profilį, kurį atsisiuntei prieš penkias minutes. Iš naujo sugeneruok kliento failą, prisijunk vieną kartą ir skaityk tik tas eilutes, kurios pasirodė per tą bandymą.

Užrašyk pirmą konkrečią nesėkmę, o ne paskutinę bendrą. Susiejimo klaida, neatsakytas išorinis mainai, sertifikato atmetimas ir paskyros atmetimas kiekvienas nukreipia tave į kitą sluoksnį, o pabaigos skirtasis laikas dažnai paslepia naudingą įvykį virš jo.

Tunelio perstatymas nėra diagnostinis žingsnis

Viliojantis trumpiausias kelias yra pastatyti antrą, paprastesnį tunelį: statinis raktas, jokių sertifikatų, jokio papildomo autentifikavimo. Jis dažnai prisijungs, ir tai įrodo tik tai, kad du hostai gali perduoti UDP arba TCP tarpusavyje. Jis nieko nesako apie tai, kodėl sertifikatų autentifikuotas diegimas nepavyksta, ir tyliai pakeičia saugumo modelį, kurį tau buvo liepta išlaikyti.

Tas pats galioja išjungiant tls-auth arba tls-crypt, silpninant verify-x509-name, arba atsisakant antrojo veiksnio dėl žalios būsenos. Tunelis, kuris prisijungia todėl, kad patikra buvo pašalinta, yra kita sistema, o ne suremontuota.

Atlik vieną ribotą pakeitimą tame sluoksnyje, kurį įvardijo žurnalas, paleisk iš naujo tą patį įrenginį ir pakartok vienintelį prisijungimo bandymą. Tai išlaiko sąžiningą palyginimą ir palieka pakeitimą, kurį gali atšaukti.

Ką perduoti kitam žmogui

Užrašyk keturis faktus, kol jų dar turi: OpenVPN versiją iš openvpn --version, aktyvų įrenginį, konfigūracijos grandinę su įtraukimais ir žurnalo langą, apimantį vieną bandymą. Tie keturi neaiškų skundą paverčia atkuriamu atveju.

Redaguok prieš bendrindamas. Privatūs raktai, auth-user-pass failai, statinio rakto medžiaga ir pilni kliento paketai nepriklauso bilietui; parinkčių pavadinimai ir grandinės forma paprastai pakanka antrai akių porai.

Jei grandinė nepažeista, o žurnalas vis dar rodo į tinklą, kitas žingsnis yra kelias tarp kliento ir serverio, o ne dar vienas diegimas. Tai vienintelė istorijos dalis, kurios pagalbinė priemonė niekada neturėjo.