OpenVPN bij het opstarten op Ubuntu: NetworkManager of systemd?

De meeste handleidingen presenteren de keuze als cosmetisch: laat NetworkManager de tunnel opzetten, of schakel een systemd-instantie in en klaar. De twee paden verschillen in één ding dat de uitkomst op een machine zonder scherm bepaalt, en dat heeft niets te maken met welke tool nieuwer is. NetworkManager ontgrendelt geheimen via een sessie; een systemd-instantie heeft geen sessie om te ontgrendelen. Kies degene wiens omgang met geheimen past bij de machine voor u.

Al het andere, van route-installatie tot herverbindingsgedrag, volgt uit die eerste beslissing.

De sleutelring is het verschil dat niemand noemt

Wanneer NetworkManager een VPN-profiel bezit, kan het wachtwoord in de inlog-sleutelring staan, die wordt ontgrendeld wanneer een gebruiker inlogt. Dat werkt goed op een laptop: de persoon is aanwezig, de sleutelring opent, de tunnel komt op. Op een server die zonder toezicht opstart is er niemand om iets te ontgrendelen, dus wacht het profiel op een geheim dat nooit komt. De verbinding lijkt geconfigureerd en wordt nooit actief.

De systemd-instantie vermijdt dat probleem door een inloggegevensbestand van schijf te lezen, waardoor het bestand het ding is dat u beschermt. chmod 400 plus eigendom door root is het minimum, en het bestand hoort buiten back-ups en imagesjablonen te blijven die u niet beheert.

De VPN aan een verbinding koppelen is geen opstartgarantie

Kies in nm-connection-editor de bedrade of draadloze verbinding in plaats van de VPN, open het tabblad General, vink de optie aan om automatisch verbinding te maken met een VPN en geef het profiel een naam. NetworkManager activeert de VPN dan als secundaire verbinding wanneer de primaire een verbonden status bereikt. Dat is een afhankelijkheid, geen firewallregel. Pakketten kunnen nog steeds naar buiten tijdens de seconden voordat de tunnel actief is, en een opgeslagen geheim dat niet ontgrendelt, laat de machine zonder tunnel online.

Als de eis is dat er niets naar buiten gaat zonder de tunnel, zeg dat dan en bouw een kill switch, want deze instelling levert er geen. Test ook suspenderen en hervatten, omdat de secundaire verbinding bij terugkomst opnieuw wordt beoordeeld.

De systemd-instantie heeft een bestandsnaam nodig die klopt

Plaats het profiel in de clientmap die het pakket verwacht, bijvoorbeeld /etc/openvpn/client/office.conf, en verwijs van binnenuit naar het inloggegevensbestand met auth-user-pass office.cred. De instantienaam is de bestandsnaam zonder de extensie, dus openvpn-client@office leest office.conf. Schakel hem in met sudo systemctl enable --now openvpn-client@office en bevestig de koppeling met systemctl cat openvpn-client@office in plaats van een voorbeeld van een blog te vertrouwen.

Paden in het profiel worden opgelost ten opzichte van de werkmap van de unit, niet ten opzichte van het profiel zelf, dus een relatieve regel ca of auth-user-pass kan bij het opstarten mislukken terwijl hij werkt als u hem handmatig test. Gebruik absolute paden voor alles wat de unit moet vinden. Lees daarna journalctl -u openvpn-client@office -b na een echte opstart; een unit die actief meldt zonder tunnel noemt in dat log meestal een ontbrekend bestand.

Oudere pakketten leveren een andere sjabloonnaam, dus systemctl list-unit-files 'openvpn*' bepaalt welke op deze host bestaat.

Herverbindingsgedrag is een aparte beslissing

Een profiel met ping-restart bouwt de tunnel opnieuw op nadat hij wegvalt, en een unit met een herstartrichtlijn doet iets soortgelijks op dienstniveau. Dat zijn beleidsregels die u kiest, geen standaardwaarden die u erft. Als de verbinding alleen op verzoek omhoog moet komen, verwijder het herstartgedrag dan bewust en schrijf op waarom. Als de unit start voordat het netwerk bruikbaar is, heeft hij een beleid voor nieuwe pogingen nodig, want één mislukte poging bij het opstarten herhaalt zich niet vanzelf.

Stoppen is net zo letterlijk: sudo systemctl disable --now openvpn-client@office stopt de draaiende instantie en verwijdert de opstartkoppeling. Alleen uitschakelen laat de tunnel draaien tot de volgende herstart, wat iedereen verrast die test door uit te schakelen en ziet dat de interface blijft staan.

Herstart, en controleer dan vier dingen in volgorde

De dienst herstarten test de dienst; de machine herstarten test het opstartpad. Bevestig na de herstart dat de unit omhoogkwam, dan dat er een route bestaat voor het externe subnet, dan welk adres de machine aan internet toont, en ten slotte dat namen via de tunnel worden opgelost. Die vier controles falen in die volgorde wanneer er iets mis is, waardoor de eerste fout de nuttige is.

Een actieve unit zonder route betekent meestal dat het profiel verbond maar de server geen route pushte, of dat de route op een interface werd geïnstalleerd die later verdween. Een route zonder werkende naamopzoeking wijst op DNS-configuratie en niet op de tunnel zelf.

Bepaal vooraf wat er moet gebeuren als de tunnel niet omhoog kan komen. Terugvallen op gewone connectiviteit is een beleid, en dat hoort opgeschreven te worden in plaats van overgelaten aan de beheerder die het eerst startte.