Vilken OpenVPN-instans använder egentligen din PiVPN-profil?

PiVPN skriver en serverkonfiguration och en klientprofil och avslutar sedan; den blir aldrig processen som bär din trafik. Ett misslyckat handskakning, en klient som ringer fel slutpunkt eller en tjänst som kommer tillbaka fel efter en omstart kan därför inte förklaras från installerarens menyer. Symtomen tillhör den OpenVPN-demon som körs nu, konfigurationen som den demonen faktiskt laddade och loggen den pekades mot. Fyra skrivskyddade kommandon avgör det oftast, och ingen av dem ändrar dina certifikat eller nycklar.

Hjälparen och demonen är olika objekt

Förvirringen är lätt att förklara: en katalog innehåller filen som hjälparen skapade, filen som demonen läser och ibland en inaktuell kopia av båda. En hjälpare är ett provisioneringsskript. Det installerar paket, skriver unit-filer och skriver ut en klientprofil, och sedan är dess arbete över. Det som återstår är en post i tjänstehanteraren och en kommandorad.

På en systemd-värd börjar du vid den aktiva enheten i stället för kataloglistningen. Namnet beror på paketeringen: Debian- och Raspberry Pi OS-avbildningar exponerar oftast en mallinstans som openvpn-server@server, medan äldre installationer använder openvpn@server. Fråga hanteraren vilken som körs i stället för att gissa från ett filnamn.

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

Läs ExecStart= i den utskriften. Den namnger den körbara filen och de alternativ som hanteraren faktiskt startar, inklusive varje --config sökväg; en konfigurationsfil bredvid som ingen kommando refererar till är inte en del av den körande tunneln.

Följ konfigurationskedjan som demonen löste upp

OpenVPN skannar inte en katalog efter inställningar. Den läser filen som skickas med --config, följer alla config direktiv i den och tillämpar sedan kommandoradsalternativen. Manualen 2.6 beskriver den ordningen, och det spelar roll när två filer inte är överens om porten, enheten eller chiffret.

Skriv först ut det effektiva anropet och titta sedan på de direktiv som avgör identitet och nåbarhet. Båda kommandona är skrivskyddade och säkra på en levande server, även om det andra skriver ut sökvägar som du kanske inte vill ha i ett offentligt ärende.

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

En .ovpn-fil i en hemkatalog är en klientartefakt. Serverdemonen läser den aldrig, så att redigera filen för att rätta ett handskakningsfel på serversidan åstadkommer ingenting.

Inkluderingar är den andra fällan. En config-rad drar in en andra fil vars alternativ bearbetas på den punkten, så ett senare direktiv med ett enda värde kan åsidosätta vad huvudfilen till synes säger. Om den synliga filen ser korrekt ut och demonen ändå beter sig annorlunda, läs den inkluderade filen innan du ändrar något.

Knyt loggen till processen, inte till felet du minns

Två loggdestinationer är vanliga, och bara en av dem är journalen. Med log-append inställt skriver demonen till den filen, och journalen behåller lite utöver startraderna. Utan det är journalctl händelsekällan.

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

Korrelera ett anslutningsförsök med ett tidsfönster. Notera klientens slutpunkt och läs sedan serverhändelser från samma sekunder. En TLS-handskakning som aldrig når certifikatutbytet pekar på nåbarhet eller protokollavvikelse, medan ett autentiseringsavslag kommer efter att tunnelparametrarna redan är överenskomna.

En gammal loggpost bevisar ingenting om en profil du hämtade för fem minuter sedan. Generera om klientfilen, anslut en gång och läs bara de rader som dök upp under det försöket.

Notera det första konkreta felet i stället för det sista generiska. Ett bind-fel, ett obesvarat yttre utbyte, ett certifikatavslag och ett kontoavslag leder dig var och en till ett annat lager, och en timeout i slutet döljer ofta den användbara händelsen ovanför.

Att bygga om tunneln är inte ett diagnostiskt steg

Den frestande genvägen är att resa en andra, enklare tunnel: statisk nyckel, inga certifikat, ingen extra autentisering. Den kommer ofta att ansluta, och den bevisar bara att två värdar kan föra UDP eller TCP mellan sig. Den säger ingenting om varför den certifikatautentiserade utrullningen misslyckas, och den ersätter tyst den säkerhetsmodell du blev ombedd att behålla.

Det gäller också inaktivering av tls-auth eller tls-crypt, uppmjukning av verify-x509-name, eller att släppa en andra faktor för att få grön status. En tunnel som ansluter för att verifieringen togs bort är ett annat system, inte ett reparerat.

Gör en enda avgränsad ändring i det lager loggen namngav, starta om samma enhet och upprepa det enda anslutningsförsöket. Det håller jämförelsen ärlig och lämnar en ändring du kan rulla tillbaka.

Vad du ska lämna vidare till nästa person

Skriv ner fyra fakta medan du fortfarande har dem: OpenVPN-versionen från openvpn --version, enheten som är aktiv, konfigurationskedjan med sina inkluderingar och loggfönstret som täcker ett försök. De fyra gör ett vagt klagomål till ett reproducerbart fall.

Sladda före du delar. Privata nycklar, auth-user-pass-filer, statiskt nyckelmaterial och kompletta klientpaket hör inte hemma i ett ärende; alternativnamn och kedjans form räcker oftast för ett extra par ögon.

Om kedjan är intakt och loggen fortfarande pekar på nätverket, är nästa steg vägen mellan klient och server i stället för ännu en installation. Det är den enda delen av historien som hjälparen aldrig ägde.