Která instance OpenVPN skutečně používá váš profil PiVPN?

PiVPN zapíše konfiguraci serveru a profil klienta a potom skončí; nikdy se nestane procesem, který přenáší váš provoz. Neúspěšný handshake, klient volající špatný koncový bod nebo služba, která se po restartu vrátí špatně, se tedy nedají vysvětlit z nabídek instalátoru. Tyto příznaky patří tomu démonu OpenVPN, který právě běží, konfiguraci, kterou tento démon skutečně načetl, a logu, na který byl nasměrován. Čtyři příkazy jen pro čtení to obvykle vyřeší a žádný z nich nemění vaše certifikáty ani klíče.

Pomocník a démon jsou různé objekty

Zmatek se dá snadno vysvětlit: jeden adresář obsahuje soubor, který vygeneroval pomocník, soubor, který čte démon, a někdy i zastaralou kopii obojího. Pomocník je provisioningový skript. Nainstaluje balíčky, zapíše unit soubory a vytiskne profil klienta, a tím jeho práce končí. Co zůstane, je záznam ve správci služeb a příkazový řádek.

Na hostiteli se systemd začněte od aktivní jednotky, ne od výpisu adresáře. Název závisí na balení: obrazy Debian a Raspberry Pi OS obvykle nabízejí šablonovou instanci jako openvpn-server@server, zatímco starší instalace používají openvpn@server. Zeptejte se správce, která běží, místo abyste hádali z názvu souboru.

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

Přečtěte si ExecStart= v tomto výstupu. Uvádí spustitelný soubor a volby, které správce skutečně spouští, včetně jakékoli --config cesty; konfigurační soubor, který leží poblíž a na který neodkazuje žádný příkaz, není součástí běžícího tunelu.

Sledujte konfigurační řetězec, který démon vyřešil

OpenVPN neprohledává adresář kvůli nastavení. Čte soubor předaný s --config, následuje všechny config direktivy uvnitř a potom aplikuje volby příkazového řádku. Manuál 2.6 popisuje toto pořadí a to je důležité, když se dva soubory neshodnou na portu, zařízení nebo šifře.

Nejprve vypište efektivní vyvolání a potom se podívejte na direktivy, které určují identitu a dosažitelnost. Oba příkazy jsou jen pro čtení a bezpečné na živém serveru, i když druhý vypisuje cesty, které ve veřejném tiketu možná nechcete.

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

Soubor .ovpn v domovském adresáři je artefakt klienta. Serverový démon jej nikdy nečte, takže úprava tohoto souboru pro opravu selhání handshake na straně serveru nic nevyřeší.

Vložení jsou druhá past. Řádek config přitáhne druhý soubor, jehož volby se zpracují na tomto místě, takže pozdější direktiva s jedinou hodnotou může přebít to, co hlavní soubor zdánlivě říká. Pokud viditelný soubor vypadá správně a démon se přesto chová jinak, přečtěte vložený soubor, než cokoli změníte.

Přiřaďte log procesu, ne chybě, kterou si pamatujete

Dvě cílová místa logu jsou běžná a jen jedno z nich je journal. S log-append nastaveným démon zapisuje do tohoto souboru a journal si kromě startovacích řádků moc neponechá. Bez něj je journalctl zdrojem událostí.

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

Spojte jeden pokus o připojení s jedním časovým oknem. Poznamenejte si koncový bod klienta a potom čtěte události serveru ze stejných sekund. TLS handshake, který nikdy nedojde k výměně certifikátů, ukazuje na dosažitelnost nebo nesoulad protokolu, zatímco odmítnutí autentizace přichází po tom, co jsou parametry tunelu již dohodnuty.

Starý záznam v logu nic nedokazuje o profilu, který jste stáhli před pěti minutami. Znovu vygenerujte klientský soubor, jednou se připojte a čtěte jen řádky, které se během tohoto pokusu objevily.

Zaznamenejte první konkrétní selhání, ne poslední obecné. Chyba při bind, nezodpovězená vnější výměna, odmítnutí certifikátu a odmítnutí účtu vás každé pošle do jiné vrstvy a časový limit na konci často skrývá užitečnou událost nad ním.

Znovupostavení tunelu není diagnostický krok

Lákavá zkratka je postavit druhý, jednodušší tunel: statický klíč, žádné certifikáty, žádná dodatečná autentizace. Často se připojí a dokazuje jen to, že dva hostitelé mezi sebou umí propustit UDP nebo TCP. Nic neříká o tom, proč nasazení s certifikáty selhává, a tiše nahrazuje bezpečnostní model, který jste měli zachovat.

Totéž platí pro vypnutí tls-auth nebo tls-crypt, uvolnění verify-x509-name, nebo zrušení druhého faktoru kvůli zelenému stavu. Tunel, který se připojí proto, že bylo ověření odstraněno, je jiný systém, ne opravený.

Proveďte jednu omezenou změnu ve vrstvě, kterou log označil, restartujte stejnou jednotku a zopakujte jediný pokus o připojení. To udrží srovnání poctivé a zanechá změnu, kterou můžete vrátit.

Co předat dalšímu člověku

Zapište si čtyři fakta, dokud je ještě máte: verzi OpenVPN z openvpn --version, jednotku, která je aktivní, konfigurační řetězec s jeho vloženími a okno logu pokrývající jeden pokus. Ty čtyři promění neurčitou stížnost v reprodukovatelný případ.

Před sdílením redigujte. Soukromé klíče, auth-user-pass soubory, materiál statického klíče a kompletní klientské balíčky do tiketu nepatří; názvy voleb a tvar řetězce obvykle stačí pro druhý pár očí.

Pokud je řetězec neporušený a log stále ukazuje na síť, dalším krokem je cesta mezi klientem a serverem místo další instalace. To je jediná část příběhu, kterou pomocník nikdy nevlastnil.