OpenVPN při spouštění v Ubuntu: NetworkManager, nebo systemd?
Přenosný počítač a server bez obrazovky potřebují různé cesty spouštění. Porovnejte sekundární připojení NetworkManager s openvpn-client@ a jeho souborem přihlašovacích údajů.
Většina návodů podává tuto volbu jako kosmetickou: buď nechte NetworkManager zvednout tunel, nebo povolte instanci systemd a hotovo. Obě cesty se liší v jedné věci, která rozhoduje o výsledku na stroji bez obrazovky, a ta nemá nic společného s tím, který nástroj je novější. NetworkManager odemyká tajemství přes relaci; instance systemd nemá žádnou relaci k odemčení. Vyberte tu, jejíž zacházení s tajemstvími odpovídá stroji před vámi.
Všechno ostatní, od instalace tras po chování při opětovném připojení, vyplývá z tohoto prvního rozhodnutí.
Klíčenka je rozdíl, o kterém nikdo nemluví
Když NetworkManager vlastní profil VPN, heslo může žít v přihlašovací klíčence, která se odemkne, když se uživatel přihlásí. Na přenosném počítači to funguje dobře: člověk je přítomen, klíčenka se otevře, tunel se zvedne. Na serveru, který se spouští bez dozoru, není nikdo, kdo by cokoli odemkl, takže profil čeká na tajemství, které nikdy nepřijde. Připojení vypadá nastavené a nikdy se neaktivuje.
Instance systemd se tomuto problému vyhýbá tím, že čte soubor přihlašovacích údajů z disku, což ze souboru dělá věc, kterou chráníte. chmod 400 plus vlastnictví rootem je minimum a soubor by měl zůstat mimo zálohy a šablony obrazů, které nekontrolujete.
Připojení VPN k připojení není zárukou spuštění
V nm-connection-editor vyberte kabelové nebo bezdrátové připojení místo VPN, otevřete kartu General, zaškrtněte volbu automatického připojení k VPN a pojmenujte profil. NetworkManager pak aktivuje VPN jako sekundární připojení, když primární dosáhne stavu připojeno. To je závislost, ne pravidlo firewallu. Pakety mohou stále odcházet během sekund před zvednutím tunelu a uložené tajemství, které se nepodaří odemknout, nechá stroj online bez něj.
Pokud je požadavkem, aby nic neodcházelo bez tunelu, řekněte to a postavte kill switch, protože toto nastavení ho neposkytne. Otestujte také pozastavení a obnovení, protože sekundární připojení se při návratu znovu vyhodnocuje.
Instance systemd potřebuje odpovídající název souboru
Umístěte profil do klientského adresáře, který balíček očekává, například /etc/openvpn/client/office.conf, a zevnitř odkažte na soubor přihlašovacích údajů pomocí auth-user-pass office.cred. Název instance je název souboru bez přípony, takže openvpn-client@office čte office.conf. Povolte ji pomocí sudo systemctl enable --now openvpn-client@office a ověřte mapování pomocí systemctl cat openvpn-client@office, místo abyste věřili příkladu z blogu.
Cesty uvnitř profilu se vyhodnocují relativně k pracovnímu adresáři jednotky, ne k profilu samotnému, takže relativní řádek ca nebo auth-user-pass může při spuštění selhat, i když při ručním testu funguje. Pro vše, co jednotka musí najít, používejte absolutní cesty. Potom po skutečném spuštění přečtěte journalctl -u openvpn-client@office -b; jednotka, která hlásí aktivitu bez tunelu, obvykle v tom protokolu pojmenuje chybějící soubor.
Starší balíčky dodávají jiný název šablony, takže systemctl list-unit-files 'openvpn*' rozhodne, která na tomto hostiteli existuje.
Chování při opětovném připojení je samostatné rozhodnutí
Profil s ping-restart znovu postaví tunel poté, co spadne, a jednotka s direktivou restartu dělá něco podobného na úrovni služby. To jsou zásady, které volíte, ne výchozí hodnoty, které dědíte. Pokud se má připojení zvedat jen na vyžádání, chování restartu záměrně odstraňte a napište proč. Pokud jednotka startuje dřív, než je síť použitelná, potřebuje zásadu opakování, protože jeden neúspěšný pokus při spuštění se sám neopakuje.
Zastavení je stejně doslovné: sudo systemctl disable --now openvpn-client@office zastaví běžící instanci a odstraní odkaz pro spuštění. Pouhé vypnutí nechá tunel běžet do dalšího restartu, což překvapí každého, kdo testuje vypnutím a sleduje, jak rozhraní zůstává nahoře.
Restartujte a potom zkontrolujte čtyři věci v pořadí
Restart služby testuje službu; restart stroje testuje cestu spuštění. Po restartu ověřte, že jednotka naskočila, potom že existuje trasa pro vzdálenou podsíť, potom jakou adresu stroj představuje internetu, a nakonec že se názvy překládají přes tunel. Tyto čtyři kontroly selhávají v tomto pořadí, když je něco špatně, což dělá první selhání tím užitečným.
Aktivní jednotka bez trasy obvykle znamená, že se profil připojil, ale server neposlal žádnou trasu, nebo že trasa byla nainstalována na rozhraní, které později zmizelo. Trasa bez funkčního vyhledávání názvů ukazuje na konfiguraci DNS, ne na samotný tunel.
Předem rozhodněte, co se má stát, když tunel nelze zvednout. Návrat k obyčejnému připojení je zásada a měla by být sepsána, místo aby byla ponechána tomu správci, který nastartoval první.