openvpn3 session-start ignoruje váš soubor s přihlašovacími údaji

Klient 3.x přebírá přihlašovací údaje při zahájení relace a uložený soubor nečte. Použijte výzvu nebo cestu automatického načtení a přijměte, co každá z nich ukládá.

Připojte se klientem 2.x a profil funguje; předejte stejný soubor klientovi 3.x a zastaví se na výzvě k zadání hesla. Předejte --auth-user-pass creds.txt příkazu openvpn3 session-start a výsledek je stejný, protože novější klient nemá fázi, která by soubor četla. Odmítnutí je záměrné: přihlašovací údaje patří k relaci a relaci vytváří služba, nikoli proces ve vašem terminálu. Vyberte si mezi interaktivní výzvou a pomocníkem pro automatické načtení a vězte, co každý z nich ukládá.

Proč uložený soubor nemá kam jít

V novějším návrhu jsou správa konfigurace a správa relací oddělené služby, které spolu komunikují po systémové sběrnici. Právě toto oddělení umožňuje běžnému uživateli spustit relaci, aniž by privilegovaný démon četl jeho jménem chráněný soubor s hesly. Přihlašovací údaje založené na souboru v tomto modelu nemají místo, protože neexistuje spouštění na straně démona, které by je četlo. Odmítnutí je důsledek architektury, ne chybějící funkce.

Starý vzor stojí za pojmenování, aby se snáze odvykl: profil odkazuje na soubor s přihlašovacími údaji a démon jej přečte při spuštění tunelu. V novém modelu patří přihlašovací údaje k relaci a dodávají se při jejím zahájení. openvpn3 session-start --config work.ovpn se na ně ptá a --auth-user-pass creds.txt je odmítnut, protože nic na této cestě by soubor neotevřelo. Každý recept pro 2.x, který najdete, předpokládá fázi, která už neexistuje.

Konfigurace a místní nastavení webu jsou také oddělené, což vysvětluje druhé překvapení. Profil může vypadat úplně, zatímco spojení, které vytvoří, postrádá konfiguraci směrování a překladače. Tyto části se uplatňují jako místní nastavení webu, odděleně od importovaného souboru.

Cesta přes výzvu a relace, kterou zanechává

Zadání hesla při zahájení relace je zamýšlený postup. Klient se zeptá jednou, předá údaje backendu relace a pokračuje:

openvpn3 session-start --config work.ovpn
openvpn3 sessions-list

Touto cestou se na disk nic nezapisuje. Relace běží dál i po zavření terminálu, což překvapuje lidi, kteří čekají, že proces zemře s jejich shellem. Přesně to je smyslem přesunu správy relací do služby. Relace přežívá terminál, který o ni požádal, a musí se zastavit výslovně.

Pro pracovní stanici s člověkem před ní je to také nejbezpečnější volba, protože neexistuje uložené tajemství, které by se muselo chránit nebo zapomenout. Nevhodná je jen tam, kde není nikdo, kdo by psal.

Automatizace bez člověka u klávesnice

Tam, kde se stroj musí připojit bez člověka, projekt dodává openvpn3-autoload. Čte adresář profilů a odpovídající deskriptor pro každý profil a deskriptor dodává přihlašovací údaje jako čistý text. Pomocník je samostatný binární soubor, obvykle v /usr/sbin/openvpn3-autoload, ne přepínač příkazu session-start. Nastavení znamená vytvoření adresáře, zkopírování profilu pod jménem, které deskriptor očekává, a napsání deskriptoru.

Nastavení pro jednoho uživatele vypadá takto a spouští se pod účtem, který bude relaci vlastnit. Režim adresáře drží ostatní místní uživatele venku:

mkdir -m700 -p ~/.openvpn3/autoload
cp work.ovpn ~/.openvpn3/autoload/client.conf
$EDITOR ~/.openvpn3/autoload/client.autoload

Deskriptor pojmenovává přihlašovací údaje a žádá automatické spuštění. Udržujte hodnotu hesla mimo verzovací systém:

{
  "autostart": true,
  "user-auth": {
    "autologin": true,
    "username": "svc-vpn",
    "password": "change-this-value"
  }
}

Potom jednou zavolejte pomocníka a potvrďte, že se relace objeví. Druhý příkaz je kontrola, ne další krok nastavení:

/usr/sbin/openvpn3-autoload --directory ~/.openvpn3/autoload
openvpn3 sessions-list

Při zavádění systém používá zabalenou jednotku jménem openvpn3-autoload.service se systémovým adresářem /etc/openvpn3/autoload, ne tím pro jednotlivého uživatele. To místo vyžaduje vlastnictví roota a přísnější režim a deskriptor stále drží heslo v čistém textu. Kompromis je jasný: heslo teď leží na disku, takže k tomuto adresáři přistupujte jako k tajemství, vyřaďte ho ze záloh mimo hostitele a kdykoli je přítomen člověk, zvolte interaktivní cestu.

Selhání sběrnice, která vypadají jako selhání hesla

Některá selhání připisovaná přihlašovacím údajům taková vůbec nejsou. Chyba oprávnění, která uvádí cestu aktivace služby, znamená jedno ze dvou: backend neběží, nebo volající nemá oprávnění ji aktivovat. Žádná úprava profilu to nezmění. Před zásahem do konfigurace zkontrolujte stav služby a dodanou politiku sběrnice.

Následující příkazy obojí oddělují. První hlásí, zda backend běží; druhý ukazuje nedávné chyby sběrnice:

systemctl status openvpn3-service-client
journalctl -b -u openvpn3-service-client --no-pager | tail -20

Další časté chybné čtení je relace, která se objeví a hned zmizí. Tento vzor obvykle znamená, že místní nastavení webu nebyla nikdy použita, takže tunel vstal bez změn směrování a překladače, které ho dělají užitečným. Čtěte posloupnost, ne poslední řádek: zda relace vznikla, zda dosáhla připojeného stavu a zda přežila, jsou tři samostatná fakta.

Když se starší klient stále používá

Klient 2.x stále přijímá soubor s přihlašovacími údaji a klíčenka může odpovědět na jeho výzvu, aniž by se tajemství kdy dostalo na disk. Obal rozřeší záznam, takže soubor pojmenovává vyhledání, ne heslo. Toto uspořádání závisí na odemčené klíčence, což kontejner bez přihlašovací relace nebo jednotka spouštěná dřív, než se kdokoli přihlásí, nemohou zajistit. Nástroj pro vyhledání pak hlásí kolekci, do které nemůže zapisovat, takže chyba vypadá jako závada přihlašovacích údajů, když je závadou klíčenky.

Než cokoli z toho postavíte, ověřte, zda nastavení keepalive v profilu neodstraňuje potřebu restartu úplně. Relace, která zůstane nahoru, se nikdy nedostane k výzvě, kterou se snažíte automatizovat.

Související články