OpenVPN ved oppstart på Ubuntu: NetworkManager eller systemd?

De fleste veiledninger presenterer valget som kosmetisk: enten lar du NetworkManager reise tunnelen, eller så aktiverer du en systemd-instans og er ferdig. De to veiene skiller seg i én ting som avgjør resultatet på en maskin uten skjerm, og den har ingenting å gjøre med hvilket verktøy som er nyest. NetworkManager låser opp hemmeligheter via en økt; en systemd-instans har ingen økt å låse opp. Velg den hvis håndtering av hemmeligheter passer til maskinen foran deg.

Alt annet, fra ruteinstallasjon til oppførsel ved gjenoppkobling, følger av den første beslutningen.

Nøkkelringen er forskjellen ingen nevner

Når NetworkManager eier en VPN-profil, kan passordet ligge i innloggingsnøkkelringen, som låses opp når en bruker logger på. Det fungerer godt på en bærbar PC: personen er til stede, nøkkelringen åpnes, tunnelen kommer opp. På en server som starter uten tilsyn er det ingen som kan låse opp noe, så profilen venter på en hemmelighet som aldri kommer. Tilkoblingen ser konfigurert ut og aktiveres aldri.

systemd-instansen unngår det problemet ved å lese en legitimasjonsfil fra disken, noe som gjør filen til det du beskytter. chmod 400 pluss eierskap av root er minimumet, og filen bør holdes utenfor sikkerhetskopier og bildeoppskrifter du ikke kontrollerer.

Å knytte VPN-et til en tilkobling er ingen oppstartsgaranti

I nm-connection-editor velger du den kablede eller trådløse tilkoblingen i stedet for VPN-et, åpner General-fanen, huker av for automatisk tilkobling til et VPN og navngir profilen. NetworkManager aktiverer deretter VPN-et som en sekundær tilkobling når den primære når en tilkoblet tilstand. Det er en avhengighet, ikke en brannmurregel. Pakker kan fortsatt gå ut i sekundene før tunnelen er oppe, og en lagret hemmelighet som ikke lar seg låse opp, lar maskinen være på nett uten den.

Hvis kravet er at ingenting går ut uten tunnelen, si det og bygg en kill switch, for denne innstillingen gir deg ingen. Test også dvalemodus og gjenopptakelse, siden den sekundære tilkoblingen vurderes på nytt på vei tilbake.

systemd-instansen trenger et filnavn som passer

Legg profilen i klientkatalogen pakken forventer, for eksempel /etc/openvpn/client/office.conf, og referer til legitimasjonsfilen innenfra med auth-user-pass office.cred. Instansnavnet er filnavnet uten endelsen, så openvpn-client@office leser office.conf. Aktiver den med sudo systemctl enable --now openvpn-client@office og bekreft tilordningen med systemctl cat openvpn-client@office i stedet for å stole på et eksempel fra en blogg.

Stier inne i profilen løses relativt til enhetens arbeidskatalog, ikke til profilen selv, så en relativ ca- eller auth-user-pass-linje kan feile ved oppstart mens den virker når du tester den manuelt. Bruk absolutte stier for alt enheten må finne. Les deretter journalctl -u openvpn-client@office -b etter en ekte oppstart; en enhet som rapporterer aktiv uten tunnel, nevner som regel en manglende fil i den loggen.

Eldre pakker leverer et annet malnavn, så systemctl list-unit-files 'openvpn*' avgjør hvilket som finnes på denne verten.

Oppførsel ved gjenoppkobling er en egen beslutning

En profil med ping-restart bygger tunnelen på nytt etter at den faller, og en enhet med en omstartdirektiv gjør noe lignende på tjenestenivå. Det er retningslinjer du velger, ikke standardverdier du arver. Hvis tilkoblingen bare skal komme opp ved behov, fjern omstartsadferden bevisst og skriv ned hvorfor. Hvis enheten starter før nettverket er brukbart, trenger den en policy for nye forsøk, fordi ett mislykket forsøk ved oppstart ikke gjentar seg selv.

Stopping er like bokstavelig: sudo systemctl disable --now openvpn-client@office stopper den kjørende instansen og fjerner oppstartskoblingen. Bare å deaktivere lar tunnelen kjøre til neste omstart, noe som overrasker alle som tester ved å deaktivere og ser grensesnittet bli stående oppe.

Start på nytt, og kontroller deretter fire ting i rekkefølge

Å starte tjenesten på nytt tester tjenesten; å starte maskinen på nytt tester oppstartsveien. Etter omstarten bekrefter du at enheten kom opp, deretter at det finnes en rute for det eksterne subnettet, deretter hvilken adresse maskinen viser internett, og til slutt at navn løses gjennom tunnelen. De fire kontrollene feiler i den rekkefølgen når noe er galt, noe som gjør den første feilen til den nyttige.

En enhet som er aktiv uten rute betyr vanligvis at profilen koblet til, men serveren ikke dyttet noen rute, eller at ruten ble installert på et grensesnitt som senere forsvant. En rute uten fungerende navneoppslag peker på DNS-konfigurasjonen og ikke på selve tunnelen.

Bestem på forhånd hva som skal skje når tunnelen ikke kan komme opp. Å falle tilbake til vanlig tilkobling er en retningslinje, og den bør skrives ned i stedet for å overlates til den administratoren som startet først.