Hvilken OpenVPN-instans bruker egentlig PiVPN-profilen din?

PiVPN skriver en serverkonfigurasjon og en klientprofil og avslutter deretter; den blir aldri prosessen som bærer trafikken din. Et mislykket håndtrykk, en klient som ringer feil endepunkt, eller en tjeneste som kommer feil tilbake etter en omstart, kan derfor ikke forklares ut fra installatørens menyer. Disse symptomene tilhører den OpenVPN-demonen som kjører nå, konfigurasjonen som den demonen faktisk lastet, og loggen den ble pekt på. Fire skrivebeskyttede kommandoer avgjør det som regel, og ingen av dem endrer sertifikatene eller nøklene dine.

Hjelperen og demonen er forskjellige objekter

Forvirringen er lett å forklare: én mappe inneholder filen hjelperen genererte, filen demonen leser, og noen ganger en utdatert kopi av begge. En hjelper er et provisjoneringsskript. Den installerer pakker, skriver unit-filer og skriver ut en klientprofil, og så er jobben dens over. Det som gjenstår, er en oppføring i tjenestebehandleren og en kommandolinje.

På en systemd-vert starter du ved den aktive enheten i stedet for mappelisten. Navnet avhenger av pakkingen: Debian- og Raspberry Pi OS-bilder eksponerer vanligvis en malinstans som openvpn-server@server, mens eldre installasjoner bruker openvpn@server. Spør behandleren hvilken som kjører i stedet for å gjette ut fra et filnavn.

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

Les ExecStart= i den utskriften. Den navngir den kjørbare filen og valgene behandleren faktisk starter, inkludert en eventuell --config bane; en konfigurasjonsfil som ligger ved siden av og som ingen kommando refererer til, er ikke en del av den kjørende tunnelen.

Følg konfigurasjonskjeden demonen løste opp

OpenVPN skanner ikke en mappe etter innstillinger. Den leser filen som sendes med --config, følger alle config direktiver i den og bruker deretter kommandolinjevalgene. Manualen 2.6 beskriver den rekkefølgen, og det betyr noe når to filer er uenige om porten, enheten eller chifferet.

Dump først det effektive kallet, og se deretter på direktivene som bestemmer identitet og tilgjengelighet. Begge kommandoene er skrivebeskyttede og trygge på en levende server, selv om den andre skriver ut baner du kanskje ikke vil ha i en offentlig sak.

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 hjemmemappe er et klientartefakt. Serverdemonen leser den aldri, så det hjelper ingenting å redigere den filen for å rette en håndtrykksfeil på serversiden.

Inkluderinger er den andre fellen. En config-linje trekker inn en annen fil hvis valg behandles på det punktet, så et senere direktiv med én verdi kan overstyre det hovedfilen tilsynelatende sier. Hvis den synlige filen ser riktig ut og demonen fortsatt oppfører seg annerledes, les den inkluderte filen før du endrer noe.

Knyt loggen til prosessen, ikke til feilen du husker

To loggdestinasjoner er vanlige, og bare én av dem er journalen. Med log-append satt skriver demonen til den filen, og journalen beholder lite utover oppstartslinjer. Uten den er journalctl hendelseskilden.

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

Koble ett tilkoblingsforsøk til ett tidsvindu. Noter endepunktet til klienten, og les deretter serverhendelser fra de samme sekundene. Et TLS-håndtrykk som aldri når sertifikatutvekslingen peker på tilgjengelighet eller protokollavvik, mens en autentiseringsavvisning kommer etter at tunnelparameterne allerede er avtalt.

En gammel loggoppføring beviser ingenting om en profil du lastet ned for fem minutter siden. Generer klientfilen på nytt, koble til én gang, og les bare linjene som dukket opp under det forsøket.

Noter den første konkrete feilen i stedet for den siste generiske. En bind-feil, en ubesvart ytre utveksling, en sertifikatavvisning og en kontoavvisning sender deg hver til et forskjellig lag, og en timeout til slutt skjuler ofte den nyttige hendelsen over.

Å bygge tunnelen på nytt er ikke et diagnostisk trinn

Den fristende snarveien er å reise en annen, enklere tunnel: statisk nøkkel, ingen sertifikater, ingen ekstra autentisering. Den vil ofte koble til, og den beviser bare at to verter kan føre UDP eller TCP mellom seg. Den sier ingenting om hvorfor den sertifikatautentiserte utrullingen feiler, og den erstatter stille sikkerhetsmodellen du ble bedt om å beholde.

Det samme gjelder deaktivering av tls-auth eller tls-crypt, lemping av verify-x509-name, eller å droppe en annen faktor for å få grønn status. En tunnel som kobler til fordi verifiseringen ble fjernet, er et annet system, ikke et reparert ett.

Gjør én avgrenset endring i laget loggen navnga, start den samme enheten på nytt, og gjenta det ene tilkoblingsforsøket. Det holder sammenligningen ærlig, og det etterlater en endring du kan rulle tilbake.

Hva du skal gi videre til neste person

Skriv ned fire fakta mens du fortsatt har dem: OpenVPN-versjonen fra openvpn --version, enheten som er aktiv, konfigurasjonskjeden med inkluderingene og loggvinduet som dekker ett forsøk. De fire gjør en vag klage til en reproduserbar sak.

Sladd før du deler. Private nøkler, auth-user-pass-filer, statisk nøkkelmateriale og komplette klientpakker hører ikke hjemme i en sak; valgnavn og formen på kjeden er vanligvis nok for et ekstra par øyne.

Hvis kjeden er intakt og loggen fortsatt peker på nettverket, er neste trinn veien mellom klient og server i stedet for nok en installasjon. Det er den ene delen av historien hjelperen aldri eide.