OpenVPN ved opstart på Ubuntu: NetworkManager eller systemd?

De fleste guides præsenterer valget som kosmetisk: enten lader du NetworkManager rejse tunnelen, eller også aktiverer du en systemd-instans og er færdig. De to veje adskiller sig i én ting, som afgør udfaldet på en maskine uden skærm, og den har intet at gøre med, hvilket værktøj der er nyest. NetworkManager låser hemmeligheder op via en session; en systemd-instans har ingen session at låse op. Vælg den, hvis håndtering af hemmeligheder passer til maskinen foran dig.

Alt andet, fra ruteinstallation til genopkoblingsadfærd, følger af den første beslutning.

Nøgleringen er forskellen, som ingen nævner

Når NetworkManager ejer en VPN-profil, kan adgangskoden ligge i login-nøgleringen, som låses op, når en bruger logger ind. Det fungerer godt på en bærbar computer: personen er til stede, nøgleringen åbnes, tunnelen kommer op. På en server, der starter uden opsyn, er der ingen til at låse noget op, så profilen venter på en hemmelighed, der aldrig kommer. Forbindelsen ser konfigureret ud og aktiveres aldrig.

systemd-instansen undgår det problem ved at læse en legitimationsfil fra disken, hvilket gør filen til det, du beskytter. chmod 400 plus ejerskab af root er minimum, og filen bør holdes ude af sikkerhedskopier og billedskabeloner, du ikke kontrollerer.

At knytte VPN'et til en forbindelse er ikke en opstartsgaranti

I nm-connection-editor skal du vælge den kablede eller trådløse forbindelse i stedet for VPN'et, åbne fanen General, sætte flueben ved valget om automatisk at oprette forbindelse til et VPN og navngive profilen. NetworkManager aktiverer derefter VPN'et som sekundær forbindelse, når den primære når en tilsluttet tilstand. Det er en afhængighed, ikke en firewall-regel. Pakker kan stadig forlade maskinen i de sekunder, før tunnelen er oppe, og en gemt hemmelighed, der ikke kan låses op, efterlader maskinen online uden den.

Hvis kravet er, at intet forlader maskinen uden tunnelen, så sig det og byg en kill switch, for denne indstilling giver dig ikke en. Test også dvale og genoptagelse, da den sekundære forbindelse vurderes igen på vej tilbage.

systemd-instansen kræver et filnavn, der passer

Læg profilen i den klientmappe, pakken forventer, såsom /etc/openvpn/client/office.conf, og henvis inde fra den til legitimationsfilen med auth-user-pass office.cred. Instansnavnet er filnavnet uden suffikset, så openvpn-client@office læser office.conf. Aktivér den med sudo systemctl enable --now openvpn-client@office og bekræft koblingen med systemctl cat openvpn-client@office i stedet for at stole på et eksempel fra en blog.

Stier inde i profilen opløses i forhold til unitens arbejdsmappe, ikke til profilen selv, så en relativ ca eller auth-user-pass-linje kan fejle ved opstart, mens den virker, når du tester den manuelt. Brug absolutte stier til alt, som uniten skal finde. Læs derefter journalctl -u openvpn-client@office -b efter en rigtig opstart; en unit, der rapporterer aktiv uden tunnel, nævner som regel en manglende fil i den log.

Ældre pakker leverer et andet skabelonnavn, så systemctl list-unit-files 'openvpn*' afgør, hvilken der findes på denne vært.

Genopkoblingsadfærd er en separat beslutning

En profil med ping-restart genopbygger tunnelen, efter den falder, og en unit med en genstartsdirektiv gør noget lignende på tjenesteniveau. Det er politikker, du vælger, ikke standarder, du arver. Hvis forbindelsen kun skal komme op efter behov, skal du fjerne genstartsadfærden bevidst og skrive ned hvorfor. Hvis uniten starter, før netværket er brugbart, har den brug for en politik for nye forsøg, fordi et mislykket forsøg ved opstart ikke gentager sig selv.

Stop er lige så bogstaveligt: sudo systemctl disable --now openvpn-client@office stopper den kørende instans og fjerner opstartslinket. Kun at deaktivere lader tunnelen køre indtil næste genstart, hvilket overrasker enhver, der tester ved at deaktivere og se grænsefladen blive oppe.

Genstart, og kontrollér derefter fire ting i rækkefølge

Genstart af tjenesten tester tjenesten; genstart af maskinen tester opstartsvejen. Efter genstarten skal du bekræfte, at uniten kom op, derefter at der findes en rute til det fjerne subnet, derefter hvilken adresse maskinen viser internettet, og til sidst at navne opløses gennem tunnelen. De fire kontroller fejler i den rækkefølge, når noget er galt, hvilket gør den første fejl til den nyttige.

En unit, der er aktiv uden rute, betyder normalt, at profilen blev forbundet, men serveren ikke sendte nogen rute, eller at ruten blev installeret på en grænseflade, der senere forsvandt. En rute uden fungerende navneopslag peger på DNS-konfigurationen snarere end på tunnelen selv.

Beslut på forhånd, hvad der skal ske, når tunnelen ikke kan komme op. At falde tilbage til almindelig forbindelse er en politik, og den bør skrives ned i stedet for at blive overladt til den manager, der startede først.