Welke OpenVPN-instantie gebruikt nu eigenlijk jouw PiVPN-profiel?

PiVPN schrijft een serverconfiguratie en een cliëntprofiel en stopt daarna; het wordt nooit het proces dat je verkeer draagt. Een mislukte handshake, een cliënt die het verkeerde eindpunt kiest, of een dienst die na een herstart verkeerd terugkomt, zijn dus niet te verklaren vanuit de menu's van de installer. Die symptomen horen bij de OpenVPN-daemon die nu draait, bij de configuratie die die daemon werkelijk laadde, en bij het log waarheen hij wees. Vier alleen-lezen-commando's lossen het meestal op, en geen ervan verandert je certificaten of sleutels.

De helper en de daemon zijn verschillende objecten

De verwarring is makkelijk uit te leggen: één map bevat het bestand dat de helper maakte, het bestand dat de daemon leest, en soms een verouderde kopie van beide. Een helper is een provisioning-script. Het installeert pakketten, schrijft unit-bestanden en drukt een cliëntprofiel af, en dan is zijn taak klaar. Wat overblijft is een vermelding in de servicemanager en een commandoregel.

Begin op een systemd-host bij de actieve unit in plaats van bij de mapinhoud. De naam hangt van de pakkettering af: Debian- en Raspberry Pi OS-images bieden meestal een template-instantie zoals openvpn-server@server, terwijl oudere installaties openvpn@server gebruiken. Vraag de manager welke draait in plaats van het uit een bestandsnaam te raden.

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

Lees ExecStart= in die uitvoer. Het noemt het uitvoerbare bestand en de opties die de manager werkelijk start, inclusief elk --config pad; een configuratiebestand ernaast waarnaar geen enkel commando verwijst, hoort niet bij de draaiende tunnel.

Volg de configuratieketen die de daemon heeft opgelost

OpenVPN scant geen map op instellingen. Het leest het bestand dat met --config wordt meegegeven, volgt elke config richtlijn erin en past daarna de commandoregelopties toe. De handleiding van 2.6 beschrijft die volgorde, en dat telt wanneer twee bestanden het oneens zijn over de poort, het apparaat of de cipher.

Gooi eerst de effectieve aanroep eruit en kijk dan naar de richtlijnen die identiteit en bereikbaarheid bepalen. Beide commando's zijn alleen-lezen en veilig op een live server, al print het tweede paden die je misschien niet in een openbaar ticket wilt.

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

Een .ovpn-bestand in een homedirectory is een cliëntartefact. De serverdaemon leest het nooit, dus dat bestand bewerken om een handshakefout aan de serverkant te verhelpen levert niets op.

Includes zijn de andere valkuil. Een config-regel trekt een tweede bestand binnen waarvan de opties op dat punt worden verwerkt, dus een latere richtlijn met één waarde kan overschrijven wat het hoofdrecht bestand schijnbaar zegt. Als het zichtbare bestand er correct uitziet en de daemon zich toch anders gedraagt, lees dan het inbegrepen bestand voordat je iets verandert.

Koppel het log aan het proces, niet aan de fout die je onthoudt

Twee logbestemmingen zijn gebruikelijk, en slechts één ervan is het journal. Met log-append schrijft de daemon naar dat bestand en het journal bewaart weinig buiten de opstartregels. Zonder dat is journalctl de bron van gebeurtenissen.

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

Correleer één verbindingspoging met één tijdvenster. Noteer het eindpunt van de cliënt en lees dan servergebeurtenissen uit dezelfde seconden. Een TLS-handshake die nooit de certificaatuitwisseling haalt, wijst op bereikbaarheid of protocolverschil, terwijl een authenticatieweigering pas komt nadat de tunnelparameters al zijn afgesproken.

Een oude logregel bewijst niets over een profiel dat je vijf minuten geleden hebt gedownload. Genereer het cliëntbestand opnieuw, verbind één keer en lees alleen de regels die tijdens die poging verschenen.

Noteer de eerste concrete fout, niet de laatste algemene. Een bind-fout, een onbeantwoorde buitenste uitwisseling, een certificaatweigering en een accountweigering sturen je elk naar een andere laag, en een time-out aan het eind verbergt vaak de nuttige gebeurtenis erboven.

De tunnel opnieuw bouwen is geen diagnostische stap

De verleidelijke kortere weg is een tweede, eenvoudiger tunnel opzetten: statische sleutel, geen certificaten, geen extra authenticatie. Hij zal vaak verbinden, en hij bewijst alleen dat twee hosts UDP of TCP tussen elkaar door kunnen laten gaan. Hij zegt niets over waarom de met certificaten geauthenticeerde uitrol mislukt, en hij vervangt stilletjes het beveiligingsmodel dat je moest behouden.

Hetzelfde geldt voor het uitschakelen van tls-auth of tls-crypt, het versoepelen van verify-x509-name, of het laten vallen van een tweede factor om een groene status te krijgen. Een tunnel die verbindt omdat de verificatie is verwijderd, is een ander systeem, niet een gerepareerd.

Doe één afgebakende wijziging in de laag die het log noemde, herstart dezelfde unit en herhaal de enkele verbindingspoging. Dat houdt de vergelijking eerlijk en laat een wijziging achter die je kunt terugdraaien.

Wat je aan de volgende persoon geeft

Schrijf vier feiten op zolang je ze nog hebt: de OpenVPN-versie uit openvpn --version, de unit die actief is, de configuratieketen met zijn includes en het logvenster dat één poging dekt. Die vier maken van een vage klacht een reproduceerbaar geval.

Redigeer voordat je deelt. Privésleutels, auth-user-pass-bestanden, statisch sleutelmateriaal en volledige cliëntbundels horen niet in een ticket; optienamen en de vorm van de keten zijn meestal genoeg voor een tweede paar ogen.

Als de keten intact is en het log nog naar het netwerk wijst, is de volgende stap het pad tussen cliënt en server in plaats van nog een installatie. Dat is het ene deel van het verhaal dat de helper nooit bezat.