sudo, &, -b of --daemon: hoe je een OpenVPN-client op de achtergrond zet

In de uitdrukking ‘zet het op de achtergrond’ schuilen twee vragen. De eerste is of deze gebruiker überhaupt een bevoorrecht proces mag starten; de tweede is of de sessie kan doorgaan zonder dat iemand iets in een terminal typt. Een shell-ampersand beantwoordt geen van beide, en een script dat een sudo-wachtwoord in een variabele opslaat, beantwoordt de eerste slecht en laat de tweede ongemoeid. Scheid ze en de opties worden eenvoudig te vergelijken.

Vergelijk de drie kandidaten op eigendom, niet op gemak.

Drie manieren om de terminal te verlaten, drie verschillende eigenaren

Een ampersand achter een opdracht vragen de shell hem als achtergrondtaak uit te voeren, en de taak blijft eigendom van die shell. sudo kan vragen voordat het programma zelfs maar begint, en OpenVPN kan daarna om een sleutelwachtwoord of een aanmelding vragen. Een opdracht die invoer verwacht op de achtergrond zetten, levert een proces op dat wacht op een terminal waar niemand naar kijkt. De terminal wordt vrijgemaakt; de interactie niet.

Dat is de goedkoopste optie en degene die het verwarrendst mislukt, omdat de prompt verschijnt op een plek die de operator al heeft verlaten.

sudo -b is geen beheerder van inloggegevens

sudo -b voert de opdracht op de achtergrond uit vanuit het perspectief van sudo zelf, wat klinkt als de ontbrekende functie en dat niet is. Volgens de sudo-handleiding gedragen interactieve opdrachten zich in die modus doorgaans slecht, en de taakbeheersing van de shell kan de processen die het maakt niet beheren. Het verplaatst het proces zonder het een manier te geven om vragen te beantwoorden. Niets eraan levert een wachtwoordzin voor een privésleutel of een gateway-aanmelding.

Als de verbinding interactie nodig heeft, is de oplossing een ondersteunde niet-interactieve authenticatieopzet, niet een andere manier om dezelfde prompt te starten.

--daemon verandert het programma, niet de aanmelding

--daemon vraagt OpenVPN zelf om zich na de initialisatie los te koppelen. De handleiding van 2.6 merkt op dat syslog-omleiding gebeurt wanneer de optie wordt geparseerd, hoewel het loskoppelen later gebeurt, zodat berichten eerder dan verwacht uit de terminal kunnen verdwijnen. Stilte daarna bewijst niets over de tunnel. Voeg een expliciete --log of --log-append toe zodat de uitvoer terechtkomt waar je die kunt lezen.

De daemonmodus verwijdert ook de console permanent. Een beschermde privésleutel heeft in die modus askpass nodig, en inloggegevens die op de console zijn ingevoerd, gecombineerd met cache-opties, kunnen een latere herauthenticatie zonder plek om te vragen achterlaten. Controleer het authenticatiemodel tegen de geïnstalleerde versie voordat je aanneemt dat een achtergrondstart zijn eerste sleutelrotatie overleeft.

Wat sudo-validatie oplevert en wat niet

sudo -v valideert of vernieuwt de gecachte lokale inloggegevens en authenticeert als het beleid dat vereist. Het start OpenVPN niet, authenticeert niet bij de gateway en garandeert niet dat een latere opdracht in het script is toegestaan. sudo -n betekent het tegenovergestelde: vraag niet, misluk in plaats daarvan. Dat maakt een lokale autorisatiefout expliciet, wat nuttig is, en het zegt niets over wat OpenVPN later zal vragen.

Geen van beide opties is een reden om iedereen wachtwoordloze opdrachten te geven of een beheerderswachtwoord in een script te leiden.

Geef de voorkeur aan een eigenaar die waarneembaar is

Voor een tunnel die eigendom is van de machine, gebruik de service-instantie die de distributie ondersteunt. Zo'n eigenaar biedt start, stop, status en logboeken, en overleeft het einde van je sessie. Shell-achtergronduitvoering, daemonisering en een herstartlus om elkaar heen bouwen creëert drie eigenaren voor één tunnel en geen duidelijk antwoord over welke draait.

Wat je ook kiest, verifieer de resource waarvoor de tunnel bestaat. Een geslaagd startverzoek is een procesgebeurtenis, geen bewijs van een werkende verbinding.