Care instanță OpenVPN folosește de fapt profilul tău PiVPN?

PiVPN scrie o configurație de server și un profil de client, apoi iese; nu devine niciodată procesul care transportă traficul tău. De aceea, un handshake eșuat, un client care apelează un endpoint greșit sau un serviciu care revine defect după o repornire nu pot fi explicate din meniurile instalatorului. Aceste simptome aparțin demonului OpenVPN care rulează acum, configurației pe care acel demon a încărcat-o efectiv și jurnalului către care a fost îndreptat. Patru comenzi doar pentru citire rezolvă de obicei problema, și niciuna nu îți schimbă certificatele sau cheile.

Ajutorul și demonul sunt obiecte diferite

Confuzia este ușor de explicat: un director conține fișierul generat de ajutor, fișierul pe care îl citește demonul și uneori o copie învechită a ambelor. Un ajutor este un script de provizionare. Instalează pachete, scrie fișiere de unitate și tipărește un profil de client, apoi treaba lui se termină. Ce rămâne este o intrare în managerul de servicii și o linie de comandă.

Pe un host systemd, pornește de la unitatea activă în locul listării directorului. Numele depinde de împachetare: imaginile Debian și Raspberry Pi OS expun de obicei o instanță șablon precum openvpn-server@server, în timp ce instalările mai vechi folosesc openvpn@server. Întreabă managerul care rulează în loc să ghicești după numele unui fișier.

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

Citește ExecStart= în acea ieșire. Indică executabilul și opțiunile pe care managerul le lansează efectiv, inclusiv orice --config cale; un fișier de configurare aflat alături la care nu face referire nicio comandă nu face parte din tunelul care rulează.

Urmărește lanțul de configurare pe care demonul l-a rezolvat

OpenVPN nu scanează un director după setări. Citește fișierul transmis cu --config, urmează orice config directivă din el și apoi aplică opțiunile liniei de comandă. Manualul 2.6 descrie această ordine, iar asta contează când două fișiere nu sunt de acord cu privire la port, dispozitiv sau cifru.

Mai întâi afișează invocarea efectivă, apoi uită-te la directivele care decid identitatea și accesibilitatea. Ambele comenzi sunt doar pentru citire și sigure pe un server activ, deși a doua tipărește căi pe care poate nu le vrei într-un tichet public.

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

Un fișier .ovpn într-un director home este un artefact de client. Demonul serverului nu îl citește niciodată, așa că editarea acelui fișier pentru a repara o defecțiune de handshake pe partea serverului nu obține nimic.

Includerile sunt cealaltă capcană. O linie config aduce un al doilea fișier ale cărui opțiuni sunt procesate în acel punct, așa că o directivă ulterioară cu o singură valoare poate suprascrie ceea ce fișierul principal pare să spună. Dacă fișierul vizibil pare corect și demonul se comportă totuși diferit, citește fișierul inclus înainte de a schimba ceva.

Potrivește jurnalul cu procesul, nu cu eroarea pe care ți-o amintești

Două destinații de jurnal sunt obișnuite, și doar una dintre ele este journal. Cu log-append setat, demonul scrie în acel fișier, iar journal păstrează puțin dincolo de liniile de pornire. Fără asta, journalctl este sursa evenimentelor.

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

Corelează o singură încercare de conectare cu o fereastră de timp. Notează endpointul clientului, apoi citește evenimentele serverului din aceleași secunde. Un handshake TLS care nu ajunge niciodată la schimbul de certificate indică accesibilitate sau nepotrivire de protocol, în timp ce o respingere a autentificării vine după ce parametrii tunelului au fost deja conveniți.

O intrare veche în jurnal nu dovedește nimic despre un profil descărcat acum cinci minute. Regenerează fișierul client, conectează-te o dată și citește doar liniile care au apărut în timpul acelei încercări.

Notează prima defecțiune concretă, nu ultima generică. O eroare de bind, un schimb extern fără răspuns, o respingere de certificat și o respingere de cont te trimit fiecare la alt strat, iar un timeout la final ascunde adesea evenimentul util de deasupra.

Reconstruirea tunelului nu este un pas de diagnostic

Scurtătura tentantă este să ridici un al doilea tunel, mai simplu: cheie statică, fără certificate, fără autentificare suplimentară. Se va conecta des, și dovedește doar că două gazde pot trece UDP sau TCP între ele. Nu spune nimic despre de ce eșuează implementarea autentificată cu certificate și înlocuiește în liniște modelul de securitate pe care trebuia să îl păstrezi.

Același lucru este valabil pentru dezactivarea tls-auth sau tls-crypt, relaxarea verify-x509-name, sau renunțarea la un al doilea factor pentru a obține un statut verde. Un tunel care se conectează pentru că verificarea a fost eliminată este alt sistem, nu unul reparat.

Fă o singură schimbare limitată la stratul pe care jurnalul l-a numit, repornește aceeași unitate și repetă singura încercare de conectare. Asta păstrează comparația onestă și lasă o schimbare pe care o poți anula.

Ce să predai următoarei persoane

Notează patru fapte cât timp încă le ai: versiunea OpenVPN din openvpn --version, unitatea care este activă, lanțul de configurare cu includerile sale și fereastra de jurnal care acoperă o încercare. Acele patru transformă o plângere vagă într-un caz reproductibil.

Redactează înainte de a partaja. Cheile private, auth-user-pass fișiere, materialul de cheie statică și pachetele complete de client nu își au locul într-un tichet; numele opțiunilor și forma lanțului sunt de obicei suficiente pentru o a doua pereche de ochi.

Dacă lanțul este intact și jurnalul încă indică rețeaua, următorul pas este calea dintre client și server în loc de o altă instalare. Aceasta este singura parte a poveștii pe care ajutorul nu a deținut-o niciodată.