Kva OpenVPN-instans brukar eigenleg PiVPN-profilen din?

PiVPN skriv ein serverkonfigurasjon og ein klientprofil og avsluttar deretter; det vert aldri prosessen som ber trafikken din. Eit mislukka handtrykk, ein klient som ringjer feil endepunkt, eller ei teneste som kjem feil tilbake etter omstart, kan difor ikkje forklarast ut frå menyane til installatøren. Desse symptoma høyrer til den OpenVPN-demonen som køyrer no, konfigurasjonen som den demonen faktisk lasta, og loggen han vart peika på. Fire skriveverna kommandoar avgjer det som regel, og ingen av dei endrar sertifikata eller nøklane dine.

Hjelparen og demonen er ulike objekt

Forvirringa er lett å forklare: éi mappe inneheld fila hjelparen genererte, fila demonen les, og stundom ein utdatert kopi av begge. Ein hjelpar er eit provisjoneringsskript. Det installerer pakkar, skriv einingafiler og skriv ut ein klientprofil, og så er jobben hans over. Det som står att, er ei oppføring i tenestebehandlaren og ei kommandolinje.

På ein systemd-vert startar du ved den aktive eininga i staden for mappelista. Namnet avheng av pakkinga: Debian- og Raspberry Pi OS-bilete viser vanlegvis ein malinstans som openvpn-server@server, medan eldre installasjonar brukar openvpn@server. Spør behandlaren kven som køyrer i staden for å gjette ut frå eit filnamn.

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

Les ExecStart= i den utskrifta. Ho namngir den køyrbare fila og vala behandlaren faktisk startar, inkludert ein kvar --config bane; ei konfigurasjonsfil som ligg ved sida av og som ingen kommando viser til, er ikkje del av den køyrande tunnelen.

Fylg konfigurasjonskjeda demonen løyste opp

OpenVPN skannar ikkje ei mappe etter innstillingar. Det les fila som vert send med --config, fylgjer alle config direktiv i ho og brukar deretter kommandolinjevala. Manualen 2.6 skildrar den rekkjefølgja, og det betyr noko når to filer er usamde om porten, eininga eller chifferet.

Dump først det effektive kallet, og sjå deretter på direktiva som avgjer identitet og tilgjenge. Båe kommandoane er skriveverna og trygge på ein levande server, sjølv om den andre skriv ut baner du kanskje ikkje vil ha i ein offentleg 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

Ei .ovpn-fil i ei heimemappe er eit klientartefakt. Serverdemonen les ho aldri, så det hjelper ingenting å redigere den fila for å rette ein handtrykksfeil på serversida.

Inkluderingar er den andre fella. Ei config-linje dreg inn ei anna fil der vala vert handsama på det punktet, så eit seinare direktiv med éin verdi kan overstyre det hovudfila tilsynelatande seier. Viss den synlege fila ser rett ut og demonen framleis oppfører seg annleis, les den inkluderte fila før du endrar noko.

Knyt loggen til prosessen, ikkje til feilen du hugsar

To loggmål er vanlege, og berre eitt av dei er journalen. Med log-append sett skriv demonen til den fila, og journalen held lite utover oppstartslinjer. Utan det er journalctl hendingskjelda.

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

Kople eitt tilkoplingsforsøk til eitt tidsvindauge. Noter endepunktet til klienten, og les deretter serverhendingar frå dei same sekunda. Eit TLS-handtrykk som aldri når sertifikatutvekslinga peikar på tilgjenge eller protokollavvik, medan ei autentiseringsavvising kjem etter at tunnelparametrane alt er avtalte.

Ei gammal loggoppføring beviser ingenting om ein profil du lasta ned for fem minutt sidan. Generer klientfila på nytt, kople til éin gong, og les berre linjene som dukka opp under det forsøket.

Noter den første konkrete feilen i staden for den siste generiske. Ein bind-feil, ei ubesvara ytre utveksling, ei sertifikatavvising og ei kontoavvising sender deg kvar til eit anna lag, og ein timeout til slutt gøymer ofte den nyttige hendinga over.

Å byggje tunnelen på nytt er ikkje eit diagnostisk steg

Den freistande snarvegen er å reise ein annan, enklare tunnel: statisk nøkkel, ingen sertifikat, inga ekstra autentisering. Han vil ofte kople til, og han beviser berre at to vertar kan føre UDP eller TCP mellom seg. Han seier ingenting om kvifor den sertifikatautentiserte utrullinga feilar, og han erstattar stille tryggleiksmodellen du vart beden om å halde.

Det same gjeld deaktivering av tls-auth eller tls-crypt, lempe på verify-x509-name, eller å droppe ein annan faktor for å få grøn status. Ein tunnel som koplar til fordi verifiseringa vart fjerna, er eit anna system, ikkje eit reparert eitt.

Gjer éi avgrensa endring i laget loggen nemnde, start den same eininga på nytt, og repetér det eine tilkoplingsforsøket. Det held samanlikninga ærleg, og det lèt att ei endring du kan rulle tilbake.

Kva du skal gje vidare til neste person

Skriv ned fire fakta medan du framleis har dei: OpenVPN-versjonen frå openvpn --version, eininga som er aktiv, konfigurasjonskjeda med inkluderingane og loggvindauget som dekkjer eitt forsøk. Dei fire gjer ei vag klage til ei reproduserbar sak.

Sladd før du deler. Private nøklar, auth-user-pass-filer, statisk nøkkelmateriale og komplette klientpakkar høyrer ikkje heime i ei sak; valnamn og forma på kjeda er vanlegvis nok for eit ekstra par augo.

Viss kjeda er intakt og loggen framleis peikar på nettverket, er neste steg vegen mellom klient og server i staden for nok ein installasjon. Det er den eine delen av historia hjelparen aldri åtte.