Co persist-tun a persist-key v OpenVPN skutečně přežijí

Zastavení služby odstraní rozhraní i s nastaveným persist-tun. To je volba pracující podle dokumentace, ne selhání. Volba popisuje jednu cestu restartu uvnitř běžícího procesu a systemctl stop není tou cestou.

Přečtěte obě jména společně a návrh je jasný. Jedno drží deskriptor, druhé drží klíčový materiál a obě existují kvůli tomu, co se děje po odhození oprávnění.

Dva prostředky a reset, ke kterému patří

OpenVPN signalizuje vlastní restart ve dvou běžných situacích. Explicitní SIGUSR1 to udělá a ping-restart vyvolaný mrtvým protějškem udělá totéž. Oba nechávají proces živý a znovu spouštějí nastavení spojení, a právě tam si volby zaslouží své místo.

Pouze řádek měkkého resetu je to, co tyto dvě volby mění, a práce, kterou přeskakují, je drahá část na vytíženém spoji. Znovuotevření zařízení strhne adresy a trasy, které jsou k němu připojené, a jejich opětovné sestavení může zahodit pakety, které byly na cestě, když reset začal. Zastavení zničí stejné objekty bez jakékoli volby je zachovat.

Proč tyto volby vůbec existují

Ztužený server OpenVPN obvykle startuje jako root, otevře své klíče a své zařízení a poté přejde na neprivilegovaného uživatele. Po tomto přechodu některé operace prostě zmizí. Čtení klíčového souboru s režimem 0600, vytvoření síťového rozhraní nebo změna tras mohou být odmítnuty.

Bez voleb persist by protějšek, který ztichne dost dlouho na vyvolání ping-restart, vynutil právě tyto operace. Opětovné připojení by selhalo, i když se v konfiguraci nic nezměnilo. Proces by vypadal, že umírá bez důvodu, a protokol by ukázal chybu oprávnění místo síťové chyby.

S nimi měkký reset znovu použije to, co privilegovaná fáze už získala. Žádná magie v tom není a proces nic nepřežívá. Získávání prostředků je prostě odloženo.

Čtěte první chybu, ne poslední

Když reset selže, čtěte první chybu místo poslední. Chráněný klíč, soubor auth, ioctl rozhraní a externí hook jsou čtyři různé prostředky. Ponechání jednoho nic neříká o přístupu k ostatním. Hook, který volá nástroj firewallu, stále potřebuje oprávnění, která tento nástroj vyžaduje.

Hooky mají vlastní přepínač. Příručka OpenVPN páruje volby persist s up-restart, který rozhoduje, zda se skripty up a down po restartu spustí znovu. Rozhraní, které zůstalo nahoru, vám tedy nic neříká o tom, zda se vaše integrace resolveru obnovila.

# which restart path just happened?
journalctl -u openvpn-client@office --since '10 min ago' | grep -E 'SIGUSR1|ping-restart|Restart pause|NOTE:'

# did the interface survive, and do its routes still exist?
ip -brief link show tun0
ip route show dev tun0

Tato dvojice příkazů oddělí dva režimy selhání během sekund. Rozhraní, které existuje, ale chybí mu trasy, je problém hooku nebo trasy. Rozhraní, které zmizelo, znamená, že proces skutečně skončil.

Zachované rozhraní není kill switch

Pokud je požadavkem, aby provoz nikdy neopustil tunel, zachované zařízení to nedodá. Trasy pro druhou rodinu adres, druhá výchozí trasa i případ, kdy proces úplně skončí, zůstávají mimo rozsah volby.

Řešte oba požadavky odděleně. Zachování objektu tunelu přes opětovná připojení je pro démona pohodlí. Blokování odchodu, když tunel neběží, je politika firewallu s vlastními pravidly a vlastním testem. Jejich směšování dává konfiguraci, která vypadá obranně a chová se jako opětovné připojení s nejlepší snahou.

Pojmenujte událost, než ji začnete diagnostikovat. Měkký reset, neúspěšný pokus o připojení a zastavení služby jsou tři události se třemi chováními a jen první je to, co tyto volby popisují.