sudo, &, -b eller --daemon: sådan kører du en OpenVPN-klient i baggrunden

Der skjuler sig to spørgsmål i vendingen »kør det i baggrunden«. Det første er, om denne bruger overhovedet må starte en privilegeret proces; det andet er, om sessionen kan fortsætte, uden at nogen taster i en terminal. Et shell-ampersand besvarer ingen af dem, og et script, der gemmer en sudo-adgangskode i en variabel, besvarer det første dårligt og lader det andet være urørt. Skil dem ad, og mulighederne bliver nemme at sammenligne.

Sammenlign de tre kandidater på ejerskab, ikke på bekvemmelighed.

Tre måder at forlade terminalen, tre forskellige ejere

At sætte et ampersand efter en kommando beder shellen køre den som et baggrundsjob, og jobbet tilhører stadig den shell. sudo kan spørge, før programmet overhovedet starter, og OpenVPN kan bagefter spørge om en nøglefrase eller et login. At lægge en kommando, der forventer input, i baggrunden giver en proces, der venter på en terminal, som ingen kigger på. Terminalen frigøres; interaktionen ikke.

Det er den billigste mulighed og den, der fejler mest forvirrende, fordi prompten dukker op et sted, som operatøren allerede har forladt.

sudo -b er ikke en håndtering af legitimationsoplysninger

sudo -b kører kommandoen i baggrunden fra sudos eget perspektiv, hvilket lyder som den manglende funktion og ikke er det. Ifølge sudo-manualen opfører interaktive kommandoer sig generelt dårligt i den tilstand, og shellens jobkontrol kan ikke styre de processer, den skaber. Den flytter processen uden at give den en måde at svare på spørgsmål. Intet ved den leverer en nøglefrase til en privat nøgle eller et login til en gateway.

Hvis forbindelsen kræver interaktion, er løsningen en understøttet ikke-interaktiv godkendelsesordning, ikke en anden måde at starte den samme prompt på.

--daemon ændrer programmet, ikke login

--daemon beder OpenVPN selv om at koble sig løs efter initialiseringen. 2.6-manualen bemærker, at syslog-omdirigering sker, når indstillingen fortolkes, selvom løskoblingen sker senere, så beskeder kan holde op med at dukke op i terminalen tidligere end forventet. Tavshed efter det punkt beviser intet om tunnelen. Tilføj en eksplicit --log eller --log-append så outputtet lander et sted, du kan læse.

Daemontilstand fjerner også konsollen permanent. En beskyttet privat nøgle kræver askpass i den tilstand, og legitimationsoplysninger indtastet på konsollen kombineret med cacheindstillinger kan efterlade en senere genautentificering uden noget sted at spørge. Kontroller godkendelsesmodellen mod den installerede version, før du antager, at en baggrundsstart overlever sin første nøglerotation.

Hvad sudo-validering køber, og hvad den ikke køber

sudo -v validerer eller fornyer den cachelagrede lokale legitimationsoplysning og autentificerer, hvis politikken kræver det. Den starter ikke OpenVPN, autentificerer ikke over for gatewayen og garanterer ikke, at en senere kommando i scriptet er tilladt. sudo -n betyder det modsatte: spørg ikke, fejl i stedet. Det gør en lokal autorisationsfejl eksplicit, hvilket er nyttigt, og det siger intet om, hvad OpenVPN senere vil spørge om.

Ingen af mulighederne er grund til at give blanket-adgang uden adgangskode eller at pipelinje en administratorkode ind i et script.

Foretræk en ejer, der kan observeres

Til en maskinejet tunnel skal du bruge den tjenesteinstans, som distributionen understøtter. Den ejer giver start, stop, status og logfiler, og den overlever, at din session slutter. At sammensætte shell-baggrundskørsel, daemonisering og en genstartsloop omkring hinanden skaber tre ejere til én tunnel og intet klart svar på, hvilken der kører.

Uanset hvad du vælger, skal du verificere den ressource, tunnelen findes for. En vellykket startanmodning er en proceshændelse, ikke bevis på en fungerende forbindelse.