OpenVPN vid uppstart på Ubuntu: NetworkManager eller systemd?

De flesta guider presenterar valet som kosmetiskt: antingen låter du NetworkManager resa tunneln, eller så aktiverar du en systemd-instans och är klar. De två vägarna skiljer sig i en sak som avgör resultatet på en maskin utan skärm, och den har ingenting att göra med vilket verktyg som är nyast. NetworkManager låser upp hemligheter via en session; en systemd-instans har ingen session att låsa upp. Välj den vars hantering av hemligheter passar maskinen framför dig.

Allt annat, från ruteinstallation till beteende vid återanslutning, följer av det första beslutet.

Nyckelringen är skillnaden ingen nämner

När NetworkManager äger en VPN-profil kan lösenordet ligga i inloggningsnyckelringen, som låses upp när en användare loggar in. Det fungerar bra på en bärbar dator: personen är närvarande, nyckelringen öppnas, tunneln kommer upp. På en server som startar utan tillsyn finns ingen som kan låsa upp något, så profilen väntar på en hemlighet som aldrig kommer. Anslutningen ser konfigurerad ut och aktiveras aldrig.

systemd-instansen undviker det problemet genom att läsa en autentiseringsfil från disken, vilket gör filen till det du skyddar. chmod 400 plus ägande av root är minimumet, och filen bör hållas utanför säkerhetskopior och bildmallar som du inte kontrollerar.

Att knyta VPN:et till en anslutning är ingen uppstartsgaranti

I nm-connection-editor väljer du den trådbundna eller trådlösa anslutningen i stället för VPN:et, öppnar fliken General, kryssar i alternativet att automatiskt ansluta till ett VPN och namnger profilen. NetworkManager aktiverar då VPN:et som en sekundär anslutning när den primära når ett anslutet tillstånd. Det är ett beroende, inte en brandväggsregel. Paket kan fortfarande gå ut under sekunderna innan tunneln är uppe, och en sparad hemlighet som inte låses upp lämnar maskinen online utan den.

Om kravet är att ingenting går ut utan tunneln, säg det och bygg en kill switch, för den här inställningen ger ingen. Testa också viloläge och återupptagning, eftersom den sekundära anslutningen omvärderas på vägen tillbaka.

systemd-instansen behöver ett filnamn som stämmer

Lägg profilen i klientkatalogen som paketet förväntar sig, till exempel /etc/openvpn/client/office.conf, och referera till autentiseringsfilen inifrån med auth-user-pass office.cred. Instansnamnet är filnamnet utan ändelsen, så openvpn-client@office läser office.conf. Aktivera den med sudo systemctl enable --now openvpn-client@office och bekräfta mappningen med systemctl cat openvpn-client@office i stället för att lita på ett exempel från en blogg.

Sökvägar inuti profilen löses relativt enhetens arbetskatalog, inte profilen själv, så en relativ ca- eller auth-user-pass-rad kan misslyckas vid uppstart medan den fungerar när du testar den manuellt. Använd absoluta sökvägar för allt enheten måste hitta. Läs sedan journalctl -u openvpn-client@office -b efter en riktig uppstart; en enhet som rapporterar aktiv utan tunnel nämner oftast en saknad fil i den loggen.

Äldre paket levererar ett annat mallnamn, så systemctl list-unit-files 'openvpn*' avgör vilket som finns på den här värden.

Beteendet vid återanslutning är ett eget beslut

En profil med ping-restart bygger upp tunneln igen efter att den faller, och en enhet med ett omstartsdirektiv gör något liknande på tjänstenivå. Det är policyer du väljer, inte standardvärden du ärver. Om anslutningen bara ska komma upp på begäran, ta bort omstartsbeteendet medvetet och skriv ned varför. Om enheten startar innan nätverket är användbart behöver den en policy för nya försök, eftersom ett misslyckat försök vid uppstart inte upprepas av sig självt.

Stopp är lika bokstavligt: sudo systemctl disable --now openvpn-client@office stoppar den körande instansen och tar bort uppstartslänken. Bara att inaktivera låter tunneln köra till nästa omstart, vilket förvånar alla som testar genom att inaktivera och ser gränssnittet stanna uppe.

Starta om och kontrollera sedan fyra saker i ordning

Att starta om tjänsten testar tjänsten; att starta om maskinen testar uppstartsvägen. Efter omstarten bekräftar du att enheten kom upp, sedan att det finns en rutt för det avlägsna subnätet, sedan vilken adress maskinen visar mot internet, och till sist att namn löses genom tunneln. De fyra kontrollerna misslyckas i den ordningen när något är fel, vilket gör det första felet till det användbara.

En enhet som är aktiv utan rutt betyder oftast att profilen anslöt men servern inte skickade någon rutt, eller att rutten installerades på ett gränssnitt som senare försvann. En rutt utan fungerande namnsökning pekar på DNS-konfigurationen och inte på själva tunneln.

Bestäm i förväg vad som ska hända när tunneln inte kan komma upp. Att falla tillbaka på vanlig anslutning är en policy, och den bör skrivas ned i stället för att lämnas till den administratör som startade först.