Pi jako VPN klient: jeden správce, nebo vlastní skript?

Raspberry Pi, které má chránit jen svůj vlastní odchozí provoz, má dvě realistické konstrukce: nechte tunel vlastnit síťového správce, nebo si ponechte skript, který ho vlastní. Obojí dokáže přenášet provoz. Selhávají na různých místech a porucha, kterou dokážete diagnostikovat na dálku ve dvě ráno, je ta, kterou se vyplatí zvolit. Porovnejte je podle vlastnictví, podle toho, co plný tunel znamená, když do hry vstoupí IPv6 a DNS, a podle toho, co se stane ve chvíli, kdy tunel spadne.

Dva vlastníci jednoho tunelu

Konstrukce A je profil uvnitř systémového síťového správce: importovaný profil OpenVPN nebo nativní připojení WireGuard, aktivované při startu stejnou službou, která zvedá Ethernet a Wi-Fi. Konstrukce B je vaše vlastní jednotka, která spouští klienta přímo, upravuje konfiguraci resolveru a instaluje vlastní trasy a pravidla firewallu. Obě jsou legitimní; liší se v tom, kdo smí měnit směrovací tabulku.

Poruchy se liší, protože se liší vlastníci. U A profil, který se neaktivuje, nechá rozhraní zvednuté a tunel spadlý a logy správce řeknou proč. U B skript, který uspěje napůl, zanechá trasy, které přežijí proces, jenž je vytvořil. Provozovat obojí je nejhorší výsledek: dva procesy zapisují výchozí trasu, dvě úpravy resolveru závodí při startu a dvě sady tajemství k rotaci.

Zvolte jednoho vlastníka na tunel a druhého před jakýmkoli testem vypněte. Dva vlastníci také znamenají dvě místa, kam se dívat, když je tunel zvednutý a nic se neresolvuje. Tohle jediné pravidlo zabrání většině matoucích stavů popsaných ve vláknech o Pi VPN.

Co import vytvoří a co ne

V Raspberry Pi OS Bookworm a novějším je výchozím nástrojem síťové konfigurace NetworkManager, takže profil je přirozeným domovem klientského tunelu. Import vyžaduje nainstalovaný odpovídající plugin; bez něj import selže se zprávou o nepodporovaném typu připojení, což je poctivý signál zastavit se a plugin nainstalovat.

nmcli connection import type openvpn file ./provider.ovpn
nmcli connection show
nmcli --ask connection up id provider-name

Import uloží profil. Nedokazuje, že protistrana je dosažitelná, a nezaručuje, že každá direktiva v souboru přežila převod. Přečtěte si výsledné připojení a zkontrolujte části, které nesou identitu a důvěru: certifikát, vzdálený hostitel a port a zda se heslo ptá, nebo ukládá.

Aktivace s --ask udrží přístupovou frázi mimo historii shellu na sdíleném stroji. U Pi bez dohledu nakonec budete chtít, aby se profil zvedl při startu, což je samostatné rozhodnutí od ručního zvednutí jednou.

Plný tunel ve srovnání obou konstrukcí

Plný tunel je tvrzení o trasách, ne o úmyslu, a obě konstrukce ho vyjadřují různě. Přístup s profilem žádá správce, aby nainstaloval výchozí trasu a svá nastavení resolveru; přístup se skriptem dělá, co skript řekne, včetně ničeho. Ani jedna konstrukce nepokrývá IPv6, pokud se jí to neřekne, a nedotčená výchozí trasa IPv6 ochotně ponese provoz mimo tunel, zatímco IPv4 vypadá bezchybně.

ip -4 route get 198.51.100.23
ip -6 route show default
resolvectl query example.org

Pro zjištění trasy použijte dokumentační adresu a nahraďte ji hostitelem, který smíte testovat. První příkaz ukáže, které rozhraní by Pi použilo pro běžné cíle; druhý ukáže, zda výchozí trasa IPv6 stále existuje; třetí dokáže, který resolver odpověděl. Přečtěte si všechny tři, než uvěříte jakémukoli tvrzení o plném tunelu.

Pokud pokyny poskytovatele slibují plný tunel, ale výchozí trasa IPv6 přežije, Pi prosakuje. Vypněte IPv6 na vzestupném spoji nebo požádejte profil, aby si ho nárokoval, a rozhodněte se vědomě, místo abyste to zjistili později.

Otevřené selhání proti zavřenému

Když tunel spadne, směrovací tabulka, která ztratí výchozí trasu, se prostě vrátí k fyzickému vzestupnému spoji a provoz pokračuje otevřeně. To je otevřené selhání a je to výchozí chování obou konstrukcí, pokud mu něco nezabrání. Většina lidí to zjistí až po týdnech čtením logu firewallu.

Zavřené selhání vás při spadlém tunelu stojí vzdálený přístup, takže potřebuje vědomou výjimku pro cestu správy. Jedním způsobem je pravidlo, které povolí jen adresu VPN protějšku mimo tunel:

sudo nft add table inet vpnkill
sudo nft 'add chain inet vpnkill out { type filter hook output priority 0; policy accept; }'
sudo nft add rule inet vpnkill out oifname != "tun0" ip daddr != 203.0.113.24 reject

Porovnejte provozní náklady poctivě. Profil obvykle toto pravidlo vyjádřit nedokáže, takže zavřené selhání vás tlačí ke konstrukci se skriptem nebo k malé jednotce, která pravidlo nainstaluje nezávisle na tunelu. V každém případě týden logujte odmítnutí: tiché odmítnutí vypadá stejně jako rozbitá služba a počítadlo se vám bude hodit, když uživatel nahlásí, že se jedna stránka přestala načítat.

Volba pro Pi bez obrazovky

Pokud image už provozuje NetworkManager, tunel nepotřebuje nic exotického a chcete, aby automaticky následoval vzestupný spoj, vezměte profil. Pokud potřebujete politické směrování, několik tunelů vybíraných podle cíle, nebo pravidlo zavřeného selhání, které musí existovat dřív než tunel, vezměte skript a vlastněte každou jeho část, včetně pořadí startu a úklidu. Míchání obou konstrukcí stojí víc než kterákoli z nich samotná.

Migrace mezi nimi je hlavně otázka pořadí: vypněte starého vlastníka, potvrďte, že nepřežila žádná zastaralá trasa ani záznam resolveru, pak zapněte nového a dvakrát restartujte. Jediný restart může skrýt závod, který druhý odhalí. Skončete testováním Pi, ne tunelu: vyřešte jméno, stáhněte něco přes IPv4, stáhněte přes IPv6, pokud jste ho ponechali, pak shodte tunel a potvrďte, že zvolené chování skutečně nastane. Rozhraní v ip link je začátek testu, ne konec.