OpenVPN by die opstart op Ubuntu: NetworkManager of systemd?

Die meeste gidse bied die keuse as iets kosmeties aan: laat NetworkManager die tonnel opbring, of aktiveer ’n systemd-instansie en klaar. Die twee paaie verskil in een ding wat die uitkoms op ’n masjien sonder skerm bepaal, en dit het niks te doen met watter gereedskap nuwer is nie. NetworkManager ontsluit geheime deur ’n sessie; ’n systemd-instansie het geen sessie om te ontsluit nie. Kies die een wie se geheimehantering by die masjien voor jou pas.

Alles anders, van roete-installasie tot herverbindingsgedrag, volg uit daardie eerste besluit.

Die sleutelring is die verskil wat niemand noem nie

Wanneer NetworkManager ’n VPN-profiel besit, kan die wagwoord in die aanmeld-sleutelring woon, wat ontsluit word wanneer ’n gebruiker aanmeld. Dit werk goed op ’n skootrekenaar: die persoon is daar, die sleutelring maak oop, die tonnel kom op. Op ’n bediener wat sonder toesig begin, is daar niemand om enigiets te ontsluit nie, so die profiel wag vir ’n geheim wat nooit kom nie. Die verbinding lyk gekonfigureer en aktiveer nooit nie.

Die systemd-instansie vermy daardie probleem deur ’n geloofsbriewe-lêer van die skyf te lees, wat die lêer die ding maak wat jy beskerm. chmod 400 plus eienaarskap deur root is die minimum, en die lêer moet buite rugsteunings en beeldtemplated bly wat jy nie beheer nie.

Om die VPN aan ’n verbinding te koppel is nie ’n waarborg vir opstart nie

In nm-connection-editor, kies die bedrade of draadlose verbinding eerder as die VPN, maak die Algemeen-oortjie oop, merk die opsie om outomaties aan ’n VPN te koppel en noem die profiel. NetworkManager aktiveer dan die VPN as ’n sekondêre verbinding wanneer die primêre een ’n gekoppelde toestand bereik. Dit is ’n afhanklikheid, nie ’n firewall-reël nie. Pakkette kan steeds uitgaan gedurende die sekondes voordat die tonnel op is, en ’n gestoorde geheim wat nie ontsluit nie, laat die masjien aanlyn sonder dit.

As die vereiste is dat niks sonder die tonnel uitgaan nie, sê so en bou ’n doodskakelaar, want hierdie instelling sal nie een voorsien nie. Toets ook skorsing en hervatting, want die sekondêre verbinding word heroorweeg op pad terug op.

Die systemd-instansie het ’n lêernaam nodig wat pas

Plaas die profiel in die kliëntgids wat die pakket verwag, soos /etc/openvpn/client/office.conf, en verwys van binne daarna na die geloofsbriewe-lêer met auth-user-pass office.cred. Die instansienaam is die lêernaam sonder die agtervoegsel, so openvpn-client@office lees office.conf. Aktiveer dit met sudo systemctl enable --now openvpn-client@office en bevestig die koppeling met systemctl cat openvpn-client@office eerder as om ’n voorbeeld uit ’n blog te vertrou.

Paadjies binne die profiel word relatief tot die eenheid se werkende gids opgelos, nie tot die profiel self nie, so ’n relatiewe ca of auth-user-pass-lyn kan by opstart misluk terwyl dit werk wanneer jy dit met die hand toets. Gebruik absolute paadjies vir alles wat die eenheid moet vind. Lees dan journalctl -u openvpn-client@office -b ná ’n werklike opstart; ’n eenheid wat aktief rapporteer sonder ’n tonnel noem gewoonlik ’n ontbrekende lêer in daardie log.

Ouer pakkette lewer ’n ander sjabloonnaam, so systemctl list-unit-files 'openvpn*' beslis watter een op hierdie gasheer bestaan.

Herverbindingsgedrag is ’n aparte besluit

’n Profiel met ping-restart herbou die tonnel nadat dit val, en ’n eenheid met ’n herbegin-richtlijn doen iets soortgelyks op diensvlak. Dit is beleide wat jy kies, nie verstekke wat jy erf nie. As die verbinding net op aanvraag moet opkom, verwyder die herbegin-gedrag doelbewus en skryf neer waarom. As die eenheid begin voordat die netwerk bruikbaar is, het dit ’n herprobeer-beleid nodig, want een mislukte poging by opstart herhaal nie vanself nie.

Stop is ewe letterlik: sudo systemctl disable --now openvpn-client@office stop die lopende instansie en verwyder die opstartskakel. Om net te deaktiveer laat die tonnel loop tot die volgende herbegin, wat enigiemand verras wat toets deur te deaktiveer en te sien hoe die koppelvlak op bly.

Herbegin, en kontroleer dan vier dinge in volgorde

Om die diens te herbegin toets die diens; om te herbegin toets die opstartpad. Bevestig ná die herbegin dat die eenheid opgekom het, dan dat daar ’n roete vir die afgeleë subnet bestaan, dan watter adres die masjien aan die internet voorhou, en uiteindelik dat name deur die tonnel opgelos word. Daardie vier kontroles misluk in daardie volgorde wanneer iets verkeerd is, wat die eerste mislukking die nuttige een maak.

’n Eenheid wat aktief is sonder ’n roete beteken gewoonlik die profiel het gekoppel maar die bediener het geen roete gestuur nie, of die roete is op ’n koppelvlak geïnstalleer wat later verdwyn het. ’n Roete sonder werkende naamsoeking wys na DNS-konfigurasie eerder as na die tonnel self.

Besluit vooraf wat moet gebeur wanneer die tonnel nie kan opkom nie. Om terug te val op gewone konnektiwiteit is ’n beleid, en dit moet neergeskryf word eerder as om dit oor te laat aan watter bestuurder eerste begin het.