Hvilken OpenVPN-instans bruger egentlig din PiVPN-profil?

PiVPN skriver en serverkonfiguration og en klientprofil og afslutter derefter; den bliver aldrig den proces, der bærer din trafik. Et mislykket håndtryk, en klient der ringer til det forkerte endepunkt, eller en tjeneste der kommer forkert tilbage efter en genstart kan derfor ikke forklares ud fra installatørens menuer. De symptomer hører til den OpenVPN-daemon, der kører nu, den konfiguration som den daemon faktisk indlæste, og den log den blev peget på. Fire skrivebeskyttede kommandoer afgør det som regel, og ingen af dem ændrer dine certifikater eller nøgler.

Hjælperen og daemonen er forskellige objekter

Forvirringen er let at forklare: én mappe indeholder den fil, hjælperen genererede, den fil daemonen læser, og nogle gange en forældet kopi af begge. En hjælper er et provisioning-script. Den installerer pakker, skriver unit-filer og udskriver en klientprofil, og så slutter dens arbejde. Det, der er tilbage, er en post i servicemanageren og en kommandolinje.

På en systemd-vært skal du starte ved den aktive unit i stedet for mappelisten. Navnet afhænger af pakningen: Debian- og Raspberry Pi OS-images eksponerer typisk en skabeloninstans som openvpn-server@server, mens ældre installationer bruger openvpn@server. Spørg manager, hvilken der kører, i stedet for at gætte ud fra et filnavn.

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

Læs ExecStart= i det output. Den angiver den eksekverbare fil og de valgmuligheder, som manager faktisk starter, inklusive enhver --config-sti; en konfigurationsfil, der ligger i nærheden, og som ingen kommando henviser til, er ikke en del af den kørende tunnel.

Følg den konfigurationskæde, som daemonen har opløst

OpenVPN skanner ikke en mappe efter indstillinger. Den læser den fil, der sendes med --config, følger alle config direktiver i den og anvender derefter kommandolinjevalgmulighederne. Manualen 2.6 beskriver den rækkefølge, og det betyder noget, når to filer er uenige om porten, enheden eller cipher.

Dump først det effektive kald, og se derefter på de direktiver, der bestemmer identitet og tilgængelighed. Begge kommandoer er skrivebeskyttede og sikre på en live server, selvom den anden udskriver stier, du måske ikke vil have i en offentlig sag.

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 en klientartefakt. Serverdaemonen læser den aldrig, så det hjælper intet at redigere den fil for at rette en håndtryksfejl på serversiden.

Inkluderinger er den anden fælde. En config-linje trækker en anden fil ind, hvis valgmuligheder behandles på det punkt, så et senere direktiv med en enkelt værdi kan tilsidesætte det, hovedfilen tilsyneladende siger. Hvis den synlige fil ser korrekt ud, og daemonen stadig opfører sig anderledes, skal du læse den inkluderede fil, før du ændrer noget.

Knyt loggen til processen, ikke til den fejl du husker

To logdestinationer er almindelige, og kun den ene er journalen. Med log-append sat skriver daemonen til den fil, og journalen bevarer lidt ud over opstartslinjer. Uden den er journalctl begivenhedskilden.

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

Kobl ét forbindelsesforsøg til ét tidsvindue. Notér klientens endepunkt, og læs derefter serverbegivenheder fra de samme sekunder. Et TLS-håndtryk, der aldrig når certifikatudvekslingen, peger på tilgængelighed eller protokol-uoverensstemmelse, mens en afvisning af godkendelse kommer, efter at tunnelparametrene allerede er aftalt.

En gammel logpost beviser intet om en profil, du hentede for fem minutter siden. Genopret klientfilen, forbind én gang, og læs kun de linjer, der dukkede op under det forsøg.

Notér den første specifikke fejl i stedet for den sidste generiske. En bind-fejl, en ubesvaret ydre udveksling, en certifikatafvisning og en kontofvisning sender dig hver til et forskelligt lag, og en timeout til sidst skjuler ofte den nyttige begivenhed ovenover.

Genopbygning af tunnelen er ikke et diagnostisk skridt

Den fristende genvej er at rejse en anden, enklere tunnel: statisk nøgle, ingen certifikater, ingen ekstra godkendelse. Den vil ofte forbinde, og den beviser kun, at to værter kan føre UDP eller TCP mellem sig. Den siger intet om, hvorfor den certifikatgodkendte udrulning fejler, og den erstatter stille den sikkerhedsmodel, du blev bedt om at beholde.

Det samme gælder deaktivering af tls-auth eller tls-crypt, lempelse af verify-x509-name, eller at droppe en anden faktor for at få en grøn status. En tunnel, der forbinder, fordi verifikationen blev fjernet, er et andet system, ikke et repareret et.

Foretag én afgrænset ændring i det lag, loggen udpegede, genstart den samme unit, og gentag det enkelte forbindelsesforsøg. Det holder sammenligningen ærlig, og det efterlader en ændring, du kan rulle tilbage.

Hvad du skal give videre til den næste

Skriv fire fakta ned, mens du stadig har dem: OpenVPN-versionen fra openvpn --version, den unit der er aktiv, konfigurationskæden med dens inkluderinger og logvinduet, der dækker ét forsøg. De fire gør en vag klage til en reproducerbar sag.

Slør følsomme data, før du deler. Private nøgler, auth-user-pass-filer, statisk nøglemateriale og komplette klientbundter hører ikke hjemme i en sag; valgmulighedsnavne og kædens form er normalt nok for et ekstra sæt øjne.

Hvis kæden er intakt, og loggen stadig peger på netværket, er næste skridt vejen mellem klient og server i stedet for endnu en installation. Det er den ene del af historien, som hjælperen aldrig ejede.