Ktorá inštancia OpenVPN vlastne používa tvoj profil PiVPN?

PiVPN zapíše konfiguráciu servera a profil klienta a potom skončí; nikdy sa nestane procesom, ktorý prenáša tvoju prevádzku. Preto neúspešný handshake, klient volajúci nesprávny koncový bod alebo služba, ktorá sa po reštarte vráti nesprávne, sa nedajú vysvetliť z ponúk inštalátora. Tieto príznaky patria tomu démonovi OpenVPN, ktorý práve beží, konfigurácii, ktorú tento démon skutočne načítal, a logu, na ktorý bol nasmerovaný. Štyri príkazy len na čítanie to zvyčajne vyriešia a žiadny z nich nemení tvoje certifikáty ani kľúče.

Pomocník a démon sú rôzne objekty

Zmatek sa dá ľahko vysvetliť: jeden adresár obsahuje súbor, ktorý vytvoril pomocník, súbor, ktorý číta démon, a niekedy aj zastaranú kópiu oboch. Pomocník je provisioningový skript. Nainštaluje balíky, zapíše unit súbory a vytlačí profil klienta, a tým jeho práca končí. Čo zostane, je záznam v správcovi služieb a príkazový riadok.

Na hostiteľovi so systemd začni od aktívnej jednotky, nie od výpisu adresára. Názov závisí od balenia: obrazy Debian a Raspberry Pi OS zvyčajne ponúkajú šablónovú inštanciu ako openvpn-server@server, zatiaľ čo staršie inštalácie používajú openvpn@server. Spýtaj sa správcu, ktorá beží, namiesto hádania z názvu súboru.

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

Prečítaj si ExecStart= v tomto výstupe. Uvádza spustiteľný súbor a voľby, ktoré správca skutočne spúšťa, vrátane akejkoľvek --config cesty; konfiguračný súbor, ktorý leží vedľa a na ktorý neodkazuje žiadny príkaz, nie je súčasťou bežiaceho tunela.

Sleduj reťazec konfigurácie, ktorý démon vyriešil

OpenVPN neprehľadáva adresár kvôli nastaveniam. Číta súbor odovzdaný s --config, nasleduje všetky config direktívy v ňom a potom aplikuje voľby príkazového riadka. Manuál 2.6 opisuje toto poradie a to je dôležité, keď sa dva súbory nezhodujú v porte, zariadení alebo šifre.

Najprv vypíš efektívne volanie a potom sa pozri na direktívy, ktoré určujú identitu a dosiahnuteľnosť. Oba príkazy sú len na čítanie a bezpečné na živom serveri, hoci druhý vypisuje cesty, ktoré možno nechceš vo verejnom tikete.

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

Súbor .ovpn v domovskom adresári je artefakt klienta. Serverový démon ho nikdy nečíta, takže úprava tohto súboru na opravu zlyhania handshake na strane servera nič nedosiahne.

Vloženia sú druhá pasca. Riadok config pritiahne druhý súbor, ktorého voľby sa spracujú na tomto mieste, takže neskoršia direktíva s jednou hodnotou môže prepísať to, čo hlavný súbor zdanlivo hovorí. Ak viditeľný súbor vyzerá správne a démon sa napriek tomu správa inak, prečítaj vložený súbor skôr, než čokoľvek zmeníš.

Priraď log k procesu, nie k chybe, ktorú si pamätáš

Dve cieľové miesta logu sú bežné a len jedno z nich je journal. S log-append démon zapisuje do tohto súboru a journal si okrem štartovacích riadkov veľa neponechá. Bez toho je journalctl zdrojom udalostí.

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

Spoj jeden pokus o pripojenie s jedným časovým oknom. Poznač si koncový bod klienta a potom čítaj udalosti servera z tých istých sekúnd. TLS handshake, ktorý nikdy nedôjde k výmene certifikátov, ukazuje na dosiahnuteľnosť alebo nesúlad protokolu, zatiaľ čo odmietnutie autentifikácie prichádza po tom, ako sú parametre tunela už dohodnuté.

Starý záznam v logu nič nedokazuje o profile, ktorý si stiahol pred piatimi minútami. Znova vygeneruj klientsky súbor, pripoj sa raz a čítaj len riadky, ktoré sa počas tohto pokusu objavili.

Zaznamenaj prvé konkrétne zlyhanie, nie posledné všeobecné. Chyba pri bind, nezodpovedaná vonkajšia výmena, odmietnutie certifikátu a odmietnutie konta ťa každé pošlú do inej vrstvy a časový limit na konci často skrýva užitočnú udalosť nad ním.

Prestavanie tunela nie je diagnostický krok

Lákavá skratka je postaviť druhý, jednoduchší tunel: statický kľúč, žiadne certifikáty, žiadna dodatočná autentifikácia. Často sa pripojí a dokazuje len to, že dva hostitelia dokážu medzi sebou prepustiť UDP alebo TCP. Nič nehovorí o tom, prečo nasadenie s certifikátmi zlyháva, a potichu nahrádza bezpečnostný model, ktorý si mal zachovať.

To isté platí pre vypnutie tls-auth alebo tls-crypt, uvoľnenie verify-x509-name, alebo zrušenie druhého faktora kvôli zelenému stavu. Tunel, ktorý sa pripojí preto, že bolo overenie odstránené, je iný systém, nie opravený.

Urob jednu obmedzenú zmenu vo vrstve, ktorú log označil, reštartuj tú istú jednotku a zopakuj jediný pokus o pripojenie. To udrží porovnanie čestné a zanechá zmenu, ktorú môžeš vrátiť.

Čo odovzdať ďalšiemu človeku

Zapíš štyri fakty, kým ich ešte máš: verziu OpenVPN z openvpn --version, aktívnu jednotku, reťazec konfigurácie s jeho vloženiami a okno logu pokrývajúce jeden pokus. Tie štyri premenia neurčitú sťažnosť na reprodukovateľný prípad.

Pred zdieľaním rediguj. Súkromné kľúče, auth-user-pass súbory, materiál statického kľúča a kompletné klientske balíky do tiketu nepatria; názvy volieb a tvar reťazca zvyčajne stačia pre druhý pár očí.

Ak je reťazec neporušený a log stále ukazuje na sieť, ďalším krokom je cesta medzi klientom a serverom namiesto ďalšej inštalácie. To je jediná časť príbehu, ktorú pomocník nikdy nevlastnil.