Předvytvořený tun OpenVPN: srovnejte dva modely vlastnictví

Někdo tun1 vytvořil předem, profil říká dev tun1, a připojení se přesto nenaváže. Jméno existující na hostiteli neříká téměř nic, protože připojení závisí na jmenném prostoru, typu zařízení, tom, kdo vlastní odkaz, a na tom, co démon smí dělat. Opětovné použití zařízení také vynucuje rozhodnutí, které výchozí konfigurace skrývá: která komponenta zapisuje adresy a trasy. Režimy selhání obou uspořádání se liší mnohem více než konfigurační řádky, takže se rozhodněte dřív, než začnete upravovat profil.

Jméno není připojení

dev tun1 žádá OpenVPN o toto pojmenované rozhraní a tradiční sestavení v uživatelském prostoru se ho pokusí otevřít. Pokud jméno nesleduje obvyklý vzor tun nebo tap, profil potřebuje také odpovídající dev-type, protože typ se nikdy neodvozuje z řetězce. Zařízení TAP není zařízení TUN s jiným štítkem: připojení špatného buď rovnou selže, nebo vytvoří odkaz, který přenáší rámce, jež nikdo neočekává. Zkontrolujte typ dřív než cokoli jiného, protože každá další kontrola předpokládá, že se obě strany shodují. Poté ověřte, že proces dokáže zařízení skutečně otevřít, ne ho jen vidět.

dev tun1
dev-type tun

Síťové rozhraní a /dev/net/tun jsou různé objekty: jedno je odkaz uvnitř jmenného prostoru, druhé je znakové zařízení, které program v uživatelském prostoru používá k připojení. Dokumentace TUN/TAP v Linuxu popisuje tuto cestu připojení a pravidla vlastnictví pro trvalá zařízení. Root shell, který umí spustit ip link dokazuje jen to, že shell má oprávnění, ne že je má démon. Vlastnictví uzlu zařízení, sada schopností služby a uživatel, pod kterým běží se musí shodovat, než se otevření podaří.

Zařízení, které existuje a nelze ho otevřít, je problém vlastnictví, ne směrování. Při ladění ho tak berte, jinak odpoledne padne na čtení směrovacích tabulek, které nikdy nebyly příčinou.

Kdo konfiguruje odkaz: dva modely vlastnictví

V prvním modelu OpenVPN konfiguruje adresy a trasy v rámci navazování spojení. To je výchozí chování a nejsnáze pochopitelné, protože stav vytváří a zase odstraňuje jediná komponenta. Ve druhém modelu rozhraní vlastní externí správce a ifconfig-noexec zabrání OpenVPN spouštět příkazy pro konfiguraci adres a předá parametry místo toho skriptům. Správce pak musí sám použít správnou místní a protější konfiguraci, což je víc práce, než název volby naznačuje. Volba mezi oběma je otázkou, kdo smí měnit odkaz, dokud je aktivní.

ifconfig-noexec pokrývá jen adresy: směrovací tabulka zůstává nedotčená a konfigurace tras patří route-noexec. Berte obě direktivy jako samostatné ovládací prvky s oddělenými vlastníky, protože nastavit jednu a předpokládat druhou je častý zdroj napůl nakonfigurovaných odkazů. Zvolte přesně jednoho vlastníka na vrstvu, adresy na jednom místě a trasy na jednom místě. Síťový správce a pomocník VPN, kteří oba zapisují adresy, jsou důvodem, proč odpojení smaže stav, na kterém druhá strana stále závisí.

Prozkoumejte zařízení ze jmenného prostoru, na kterém záleží

Prozkoumejte zařízení ze jmenného prostoru, ve kterém běží proces VPN, ne z toho, ve kterém náhodou je váš shell. Následující dva příkazy odpovídají na různé otázky a rozdíl se projeví, když hostitel vidí rozhraní, které kontejner nevidí. Spusťte je v uvedeném pořadí, protože druhý má smysl jen tehdy, když víte, zda odkaz vůbec existuje.

ip -details link show dev tun1
ip tuntap show

První příkaz vypíše odkaz tak, jak ho vidí jádro, včetně příznaků a typu rozhraní, a tak potvrdíte, že jde o zamýšlené zařízení. Druhý vypisuje trvalé položky tun/tap, které existují, aniž by je držel nějaký proces. Rozhraní čekající na svého zamýšleného vlastníka je jiná situace než živý tunel připojený k jiné VPN a jen druhá vysvětluje, proč vaše připojení selhává. Než cokoli změníte, najděte proces, který zařízení drží, protože trvalá položka a obsazené rozhraní mají různá řešení.

Podpora multiqueue je specifické uspořádání ovladače s vlastními požadavky, ne povolení pro nesouvisející procesy sdílet jedno rozhraní. Živá relace jiného vlastníka je problém koordinace a žádná úprava profilu ho neřeší.

Dva různé druhy trvalosti

Trvalost jádra a persist-tun popisují životnosti, které se snadno slévají a draze pletou. Trvalé zařízení existuje nezávisle na jakémkoli procesu, takže přežije zastavení a lze ho znovu použít při příštím startu. persist-tun udržuje prostředky přes podporované měkké restartování uvnitř jednoho procesu OpenVPN, což je mnohem kratší horizont. Ani jedno neslibuje, že zastavení služby ponechá trasy a adresy na místě, a rozhraní, které zůstane viditelné, není důkazem funkční šifrované relace.

Ověřte také backend, protože předvytvořené rozhraní nic neříká o tom, která implementace ho otevře. Komunitní sestavení s přímou datovou cestou ho zkusí použít, pokud design neříká jinak. Kde verze přepínač podporuje, disable-dco zvolí cestu uživatelského prostoru; starší jádra a jiní klienti takovou direktivu nemají, takže ponechte podmínku verze u volby, místo abyste předpokládali, že platí.

Co se rozbije, když se testuje jen start

Dohoda o vlastnictví může projít prvním testem a selhat v posledním, což dělá ze startu špatnou samostatnou kontrolu. Sledujte místo toho dva přechody: měkké restartování a úplné zastavení následované startem.

systemctl status openvpn-client@lab
ip -details link show dev tun1

Start je snadný případ: jednotka naběhne, odkaz se objeví a výstup stavu pojmenuje načtený profil. Připojení je okamžik, kdy démon otevře zařízení, takže kontrolu odkazu spouštějte poté, co jednotka hlásí aktivitu, ne předtím. Pokud odkaz existuje, zatímco stav se ještě aktivuje, díváte se na trvalé zařízení, ke kterému se ještě nikdo nepřipojil, ne na funkční tunel. Než půjdete dál, prožeňte odkazem skutečný provoz, protože připojené rozhraní bez použitelné trasy je pořád selhání.

kill -SIGHUP $(pidof openvpn)
journalctl -u openvpn-client@lab -n 40
systemctl stop openvpn-client@lab
ip -details link show dev tun1

Restartování by mělo ponechat relaci použitelnou a prostředky nedotčené, což je práce, kterou persist-tun dělá. Úplné zastavení je místo, kde se externí správce projeví: pokud odkaz nebo jeho adresy zastavení přežijí, vlastní je někdo jiný, a to je buď stav, který jste zdokumentovali, nebo chyba, kterou jste právě našli. Zaznamenejte obě pozorování vedle profilu, aby příští změna vycházela z důkazů, ne z diagramu.