sudo, &, -b nebo --daemon: jak dostat klienta OpenVPN na pozadí
Ampersand uvolní terminál, ne přihlášení. Porovnejte sudo -b, --daemon a službu podle toho, kdo vlastní proces a kdo odpovídá na výzvy.
Ve frázi „spusť to na pozadí“ se skrývají dvě otázky. První je, zda tento uživatel vůbec smí spustit privilegovaný proces; druhá, zda relace může pokračovat, aniž by někdo psal do terminálu. Ampersand v shellu neodpovídá ani na jednu a skript, který ukládá heslo sudo do proměnné, odpovídá špatně na první a druhou nechává nedotčenou. Oddělte je a možnosti se snadno porovnají.
Porovnejte tři kandidáty podle vlastnictví, ne podle pohodlí.
Tři způsoby, jak opustit terminál, tři různí vlastníci
Připojení ampersandu k příkazu požádá shell, aby jej spustil jako úlohu na pozadí, a úloha stále patří tomu shellu. sudo se může zeptat ještě před spuštěním programu a OpenVPN se může zeptat potom na heslo ke klíči nebo přihlášení. Spuštění příkazu, který očekává vstup, na pozadí vytvoří proces čekající na terminál, který nikdo nesleduje. Terminál se uvolní; interakce ne.
To je nejlevnější možnost a ta, která selhává nejmatoucněji, protože výzva se objeví na místě, které operátor už opustil.
sudo -b není správce přihlašovacích údajů
sudo -b spouští příkaz na pozadí z pohledu samotného sudo, což zní jako chybějící funkce, ale není. Podle manuálu sudo se interaktivní příkazy v tomto režimu obecně chovají špatně a ovládání úloh shellu nedokáže spravovat procesy, které vytváří. Přesouvá proces, aniž by mu dal způsob, jak odpovídat na otázky. Nic z toho neposkytuje heslo k soukromému klíči ani přihlášení k bráně.
Pokud připojení vyžaduje interakci, řešením je podporované neinteraktivní uspořádání autentizace, ne jiný způsob spuštění stejné výzvy.
--daemon mění program, ne přihlášení
--daemon žádá samotný OpenVPN, aby se po inicializaci odpojil. Manuál k verzi 2.6 poznamenává, že přesměrování syslogu probíhá při parsování volby, i když k odpojení dochází později, takže zprávy mohou v terminálu přestat docházet dříve, než se očekává. Ticho po tomto bodu nic o tunelu nedokazuje. Přidejte výslovnou --log nebo --log-append aby výstup skončil někde, kde si ho můžete přečíst.
Daemonový režim také trvale odstraňuje konzoli. Chráněný soukromý klíč v tomto režimu potřebuje askpass a údaje zadané z konzole v kombinaci s volbami ukládání do mezipaměti mohou nechat pozdější opětovnou autentizaci bez místa, kde se zeptat. Zkontrolujte model autentizace proti nainstalované verzi, než budete předpokládat, že spuštění na pozadí přežije první obnovu klíče.
Co validace sudo přináší a co ne
sudo -v ověřuje nebo obnovuje uložené místní přihlašovací údaje a autentizuje se, pokud to politika vyžaduje. Nespouští OpenVPN, neautentizuje se vůči bráně a nezaručuje, že pozdější příkaz ve skriptu bude povolen. sudo -n znamená opak: neptej se, selži. Tím je místní selhání autorizace explicitní, což je užitečné, a nic to neříká o tom, co bude OpenVPN později žádat.
Ani jedna z možností není důvodem udělit plošné příkazy bez hesla nebo předat heslo správce do skriptu.
Upřednostněte vlastníka, kterého lze pozorovat
Pro tunel vlastněný strojem použijte instanci služby, kterou distribuce podporuje. Takový vlastník poskytuje start, stop, stav a protokoly a přežije konec vaší relace. Skládání shellového běhu na pozadí, daemonizace a smyčky restartu kolem sebe vytváří tři vlastníky pro jeden tunel a žádnou jasnou odpověď, který z nich běží.
Ať zvolíte cokoli, ověřte prostředek, kvůli kterému tunel existuje. Úspěšný požadavek na spuštění je událost procesu, ne důkaz fungujícího připojení.