OpenVPN ved oppstart på Ubuntu: NetworkManager eller systemd?

Dei fleste rettleiingane presenterer valet som kosmetisk: anten lèt du NetworkManager reisa tunnelen, eller så aktiverer du ein systemd-instans og er ferdig. Dei to vegane skil seg i éin ting som avgjer resultatet på ein maskin utan skjerm, og han har ingenting å gjera med kva verktøy som er nyast. NetworkManager låser opp hemmelegheiter via ein økt; ein systemd-instans har inga økt å låsa opp. Vel den der handsaminga av hemmelegheiter passar til maskina framfor deg.

Alt anna, frå ruteinstallasjon til oppførsel ved gjenoppkopling, følgjer av den første avgjerda.

Nykjelringen er skilnaden ingen nemner

Når NetworkManager eig ein VPN-profil, kan passordet liggja i innloggingsnykjelringen, som blir låst opp når ein brukar loggar på. Det fungerer godt på ein berbar PC: personen er til stades, nykjelringen opnar seg, tunnelen kjem opp. På ein tenar som startar utan tilsyn er det ingen som kan låsa opp noko, så profilen ventar på ei hemmelegheit som aldri kjem. Tilkoplinga ser konfigurert ut og blir aldri aktivert.

systemd-instansen unngår det problemet ved å lesa ei legitimasjonsfil frå disken, noko som gjer fila til det du vernar. chmod 400 pluss eigarskap av root er minimumet, og fila bør haldast utanfor sikkerheitskopiar og biletmalar du ikkje kontrollerer.

Å knyta VPN-et til ei tilkopling er inga oppstartsgaranti

I nm-connection-editor vel du den kabelbundne eller trådlause tilkoplinga i staden for VPN-et, opnar General-fana, hukar av for automatisk tilkopling til eit VPN og namngjev profilen. NetworkManager aktiverer då VPN-et som ei sekundær tilkopling når den primære når ein tilkopla tilstand. Det er ein avhengigheit, ikkje ein brannmurregel. Pakkar kan framleis gå ut i sekunda før tunnelen er oppe, og ei lagra hemmelegheit som ikkje let seg låsa opp, lèt maskina vera på nett utan han.

Viss kravet er at ingenting går ut utan tunnelen, sei det og bygg ein kill switch, for denne innstillinga gjev deg ingen. Test òg dvalemodus og gjenopptaking, sidan den sekundære tilkoplinga blir vurdert på nytt på veg tilbake.

systemd-instansen treng eit filnamn som passar

Legg profilen i klientmappa pakken ventar, til dømes /etc/openvpn/client/office.conf, og vis til legitimasjonsfila innanfrå med auth-user-pass office.cred. Instansnamnet er filnamnet utan endinga, så openvpn-client@office les office.conf. Aktiver han med sudo systemctl enable --now openvpn-client@office og stadfest tilordninga med systemctl cat openvpn-client@office i staden for å stola på eit døme frå ein blogg.

Stigar inne i profilen blir løyste relativt til arbeidsmappa til eininga, ikkje til profilen sjølv, så ei relativ ca- eller auth-user-pass-linje kan feila ved oppstart medan ho verkar når du testar henne manuelt. Bruk absolutte stigar for alt eininga må finna. Les deretter journalctl -u openvpn-client@office -b etter ein ekte oppstart; ei eining som rapporterer aktiv utan tunnel nemner som regel ei manglande fil i den loggen.

Eldre pakkar leverer eit anna malnamn, så systemctl list-unit-files 'openvpn*' avgjer kva som finst på denne verten.

Oppførsel ved gjenoppkopling er ei eiga avgjerd

Ein profil med ping-restart byggjer tunnelen på nytt etter at han fell, og ei eining med eit omstartdirektiv gjer noko liknande på tenestenivå. Det er retningslinjer du vel, ikkje standardverdiar du arvar. Viss tilkoplinga berre skal koma opp ved behov, fjern omstartsåtferda med vilje og skriv ned kvifor. Viss eininga startar før nettverket er brukbart, treng ho ein policy for nye forsøk, fordi eitt mislukka forsøk ved oppstart ikkje gjentek seg sjølv.

Stopping er like bokstaveleg: sudo systemctl disable --now openvpn-client@office stoppar den køyrande instansen og fjernar oppstartskoplinga. Berre å deaktivera lèt tunnelen køyra til neste omstart, noko som overraskar alle som testar ved å deaktivera og ser grensesnittet bli ståande oppe.

Start på nytt, og kontroller deretter fire ting i rekkjefølgje

Å starta tenesta på nytt testar tenesta; å starta maskina på nytt testar oppstartsvegen. Etter omstarten stadfestar du at eininga kom opp, deretter at det finst ei rute for det eksterne subnettet, deretter kva adresse maskina viser internett, og til slutt at namn blir løyste gjennom tunnelen. Dei fire kontrollane feilar i den rekkjefølgja når noko er gale, noko som gjer den første feilen til den nyttige.

Ei eining som er aktiv utan rute tyder vanlegvis at profilen kopla til, men tenaren ikkje dytta noka rute, eller at ruta vart installert på eit grensesnitt som seinare forsvann. Ei rute utan fungerande namneoppslag peikar på DNS-konfigurasjonen og ikkje på sjølve tunnelen.

Avgjer på førehand kva som skal skje når tunnelen ikkje kan koma opp. Å falla tilbake til vanleg tilkopling er ein policy, og han bør skrivast ned i staden for å overlatast til den administratoren som starta først.