OpenVPN engine, nebo Tunnelblick: kdo vlastní VPN relaci na Macu?

Homebrew instaluje program OpenVPN; Tunnelblick instaluje správce, který spouští jeden nebo více enginů. To jsou různé vrstvy a užitečná otázka není, zda rádi používáte terminál. Je to, kdo vlastní konfiguraci, změny DNS, výzvu k zadání přihlašovacích údajů a úklid po skončení relace. Jediný vlastník těchto vrstev je to, co dělá nastavení předvídatelným.

Projděte níže uvedených pět kontrol v pořadí. První, která má dva vlastníky, je ta, která vytváří podivné polopřipojené stavy, které lidé svádějí na samotný OpenVPN. Každá kontrola pojmenuje důkaz, který ji rozhodne.

Kontrola první: který binární soubor OpenVPN skutečně běží

Spusťte pgrep -fl openvpn, dokud jste připojeni, a přečtěte si celý příkazový řádek. První cesta je engine, který skutečně běží. Na Apple Silicon obvykle instalace Homebrew sídlí v /opt/homebrew, zatímco Intel Macy používají /usr/local, a Tunnelblick spouští engine z vlastního balíčku aplikace.

Tunnelblick obsahuje enginy a umožňuje konfiguraci vybrat jeden z nich. Aktualizace formule Homebrew mění samostatný binární soubor, ne engine, který spouští profil Tunnelblick. Pokud porovnáváte verze, abyste vysvětlili rozdíl v chování, porovnávejte engine v seznamu procesů, ne ten ve správci balíčků. Samotný řetězec verze vám neřekne, který profil tento engine načetl.

Kopírovaný profil také může dva enginy vypadat stejně, i když čtou různé soubory. Cesta k profilu v příkazovém řádku říká, kterou konfiguraci běžící proces načetl; profil otevřený v editoru není důkaz. Porovnejte tuto cestu dříve, než porovnáte chování.

Kontrola druhá: kdo mění DNS a trasy

Engine může spouštět vlastní direktivy up a down OpenVPN, ale správce může vlastnit stejný životní cyklus. Nastavení jmenného serveru v Tunnelblicku řídí jeho standardní skripty připojení a odpojení, a když je tato integrace zapnutá, konkurenční direktivy v profilu mohou být ignorovány.

To je důležité, protože DNS je místo, kde funkční tunel nejčastěji vypadá rozbitě. Zkontrolujte scutil --dns, dokud jste připojeni, všimněte si, který resolver je první, a potvrďte, že se po odpojení vrátí. Pokud profil očekává, že DNS nastaví sám, zatímco ho spravuje i správce, jeden z těch dvou prohraje.

Rozhodněte, která vrstva vlastní DNS, ještě před prvním připojením, a poté odstraňte prohrávající direktivu, místo abyste nechali obě. Změny tras se řídí stejným pravidlem: jeden vlastník, viditelný v konfiguraci, se zdokumentovanou cestou obnovení.

Kontrola třetí: odkud přicházejí přihlašovací údaje

Interaktivní výzva a proces bez dozoru mají různé požadavky. Přihlašovací údaj uložený jednou aplikací není automaticky dostupný jinému procesu a položka klíčenky vázaná na správce může být neviditelná pro samostatný engine spuštěný z shellu.

Vyjmenujte zdroj přihlašovacích údajů pro profil: klientský certifikát a klíč, výzvu k zadání uživatelského jména a hesla nebo token poskytnutý externím pomocníkem. Poté potvrďte, že zvolený vlastník se k tomuto zdroji dostane bez člověka, pokud má spojení přežít restart.

Kontrola čtvrtá: kdo proces spouští, dohlíží na něj a zastavuje ho

Samostatné nasazení potřebuje dohlížitele, pokud má zůstat běžet. Launchd může engine spustit při přihlášení nebo na vyžádání, restartovat ho po pádu a čistě ho zastavit, ale někdo musí ten úkol napsat a vlastnit ho. Spuštění příkazu v terminálu funguje pro test a ne pro uživatele, který zavře okno.

Pokud Tunnelblick zůstane vlastníkem, použijte jeho podporované ovládací prvky místo spuštění druhého enginu. Binární soubor Homebrew s kopírovaným profilem otevře nezávislé spojení s vlastní konfigurací a integračním kontextem, místo aby řídil existující relaci Tunnelblick.

Ať už zvolíte jakéhokoli vlastníka, definujte, co se stane při spánku, změně sítě a odhlášení. Správce obvykle tyto události zpracovává; holý proces obvykle ne, a výsledná zastaralá trasa nebo resolver se snadno chybně přečte jako porucha serveru.

Kontrola pátá: jak se předání ověřuje

Otestujte nového vlastníka s vypnutým starým a poté znovu otestujte starého, pokud ho plánujete ponechat. Soukromý zdroj, který odpovídá v jednom postupu a ve druhém ne, je důkazem o chybějící integraci, ne o serveru.

Pro předání samostatnému enginu zaznamenejte cestu k profilu, cestu k binárnímu souboru, dohlížitele, vlastníka DNS a zdroj přihlašovacích údajů. Poté v tomto pořadí ověřte soukromý zdroj, cestu do veřejného internetu a čisté odpojení. Pokud DNS nebo trasy po odpojení zůstanou, nový vlastník není hotový.

Pro předání Tunnelblicku vyberte engine pro konfiguraci, zapněte integraci DNS, kterou zamýšlíte, a odstraňte direktivy profilu, které jí odporují. Poté zopakujte stejné tři kontroly. Spojení, které funguje, ale nechá resolver změněný, je neúspěšné předání, i když se tunel zvedl.

Zabalení neřeší kompatibilitu se serverem. Zkontrolujte vlastní požadavky služby na klienta a zvolte samotný engine jen tehdy, když hodláte zajistit jeho správu.