OpenVPN engine o Tunnelblick: sino ang nagmamay-ari ng VPN session ng Mac?
Ang terminal ay hindi ang linya ng paghahati. Magpasya kung sino ang nagmamay-ari ng session: ang engine na sinisimulan mo o ang manager na humahawak ng DNS, mga kredensyal at paglilinis.
Nag-i-install ang Homebrew ng programang OpenVPN; nag-i-install ang Tunnelblick ng manager na nagpapatakbo ng isa o higit pang engine. Iba't ibang layer ang mga ito, at ang kapaki-pakinabang na tanong ay hindi kung gusto mong gumamit ng terminal. Ito ay kung sino ang nagmamay-ari ng configuration, ng mga pagbabago sa DNS, ng hiling ng kredensyal at ng paglilinis kapag natapos ang session. Ang isang may-ari para sa mga layer na ito ang gumagawa sa setup na mahulaan.
Daanan ang limang pagsusuri sa ibaba nang sunod-sunod. Ang una na may dalawang may-ari ang siyang gumagawa ng kakaibang kalahating-konektadong estado na ipinapako ng mga tao sa OpenVPN mismo. Pinapangalanan ng bawat pagsusuri ang ebidensyang nagpapasya nito.
Pagsusuri isa: aling binary ng OpenVPN ang talagang tumatakbo
Patakbuhin ang pgrep -fl openvpn habang konektado at basahin ang buong command line. Ang unang path ay ang engine na talagang tumatakbo. Sa Apple Silicon, ang install ng Homebrew ay karaniwang nasa ilalim ng /opt/homebrew, samantalang ang Intel Mac ay gumagamit ng /usr/local, at ang Tunnelblick ay nagpapatakbo ng engine mula sa loob ng sarili nitong application bundle.
Binubuo ng Tunnelblick ang mga engine at hinahayaang pumili ang configuration ng isa. Ang pag-update ng Homebrew formula ay nagbabago ng standalone binary, hindi ang engine na sinisimulan ng profil ng Tunnelblick. Kung naghahambing ka ng mga bersyon upang ipaliwanag ang pagkakaiba sa pag-uugali, ihambing ang engine sa listahan ng proseso at hindi ang nasa package manager. Ang string ng bersyon lamang ay hindi magsasabi kung aling profile ang niload ng engine na iyon.
Ang kinopyang profile ay maaari ring magpamukhang magkapareho ang dalawang engine habang nagbabasa sila ng magkaibang file. Sinasabi ng path ng profile sa command line kung aling configuration ang niload ng tumatakbong proseso; ang profile na nakabukas sa editor ay hindi ebidensya. Ihambing ang path na iyon bago ihambing ang pag-uugali.
Pagsusuri dalawa: sino ang nagbabago ng DNS at mga ruta
Maaaring patakbuhin ng engine ang sariling up at down na direktiba ng OpenVPN, ngunit maaaring pagmamay-ari ng manager ang parehong lifecycle. Kinokontrol ng mga setting ng nameserver ng Tunnelblick ang mga karaniwang script nito sa pagkonekta at pagdiskonekta, at kapag naka-enable ang integrasyong iyon, maaaring balewalain ang mga nakikipagkumpitensyang direktiba sa profile.
Mahalaga ito dahil ang DNS ang lugar kung saan pinakamadalas magmukhang sira ang isang gumaganang tunnel. Suriin ang scutil --dns habang konektado, tandaan kung aling resolver ang una, at kumpirmahin na bumabalik ito pagkatapos ng diskoneksyon. Kung inaasahan ng profile na siya mismo ang magtatakda ng DNS habang pinamamahalaan din ito ng manager, isa sa dalawa ang matatalo.
Magpasya kung aling layer ang may-ari ng DNS bago ang unang koneksyon, pagkatapos alisin ang natatalong direktiba sa halip na iwan ang dalawa. Ang mga pagbabago sa ruta ay sumusunod sa parehong tuntunin: isang may-ari, nakikita sa configuration, may dokumentadong landas ng pagpapanumbalik.
Pagsusuri tatlo: saan nagmumula ang mga kredensyal
Ang interactive na hiling at ang prosesong walang pagmamatyag ay may magkaibang pangangailangan. Ang kredensyal na itinago ng isang aplikasyon ay hindi awtomatikong magagamit ng ibang proseso, at ang item sa keychain na limitado sa manager ay maaaring hindi makita ng standalone engine na sinimulan mula sa shell.
Ilahad ang pinagmulan ng kredensyal para sa profile: sertipiko at susi ng kliyente, hiling ng username at password, o token na ibinibigay ng panlabas na katulong. Pagkatapos kumpirmahin na maabot ng napiling may-ari ang pinagmulang iyon nang walang tao kung ang koneksyon ay kailangang mabuhay sa isang reboot.
Pagsusuri apat: sino ang nag-uumpisa, nagmamatyag at naghihinto ng proseso
Ang standalone na deployment ay kailangan ng supervisor kung ito ay dapat manatiling tumatakbo. Maaaring simulan ng Launchd ang engine sa pag-login o kapag hiniling, i-restart ito pagkatapos ng crash at ihinto nang maayos, ngunit kailangang may magsulat at magmay-ari ng gawaing iyon. Ang pagpapatakbo ng command sa terminal ay gumagana para sa pagsubok at hindi para sa user na nagsasara ng bintana.
Kung mananatiling may-ari ang Tunnelblick, gamitin ang mga sinusuportahang kontrol nito sa halip na magsimula ng pangalawang engine. Ang binary ng Homebrew, kapag binigyan ng kinopyang profile, ay nagbubukas ng independiyenteng koneksyon gamit ang sarili nitong configuration at konteksto ng integrasyon sa halip na mag-utos sa umiiral na session ng Tunnelblick.
Anuman ang piliing may-ari, tukuyin kung ano ang nangyayari sa pagtulog, pagbabago ng network at pag-logout. Karaniwang hinahawakan ng manager ang mga kaganapang iyon; ang hubad na proseso ay karaniwang hindi, at ang nagresultang lumang ruta o resolver ay madaling mabasa nang mali bilang sira ng server.
Pagsusuri lima: paano beripikahin ang paglilipat
Subukan ang bagong may-ari habang naka-disable ang luma, pagkatapos subukan muli ang luma kung balak mong panatilihin ito. Ang pribadong resource na tumutugon sa isang workflow at hindi sa isa pa ay ebidensya tungkol sa kulang na integrasyon, hindi tungkol sa server.
Para sa paglilipat sa standalone engine, itala ang path ng profile, path ng binary, supervisor, may-ari ng DNS at pinagmulan ng kredensyal. Pagkatapos beripikahin ang pribadong resource, ang landas patungo sa pampublikong internet at ang malinis na diskoneksyon sa ganitong pagkakasunod-sunod. Kung may natira pang DNS o ruta pagkatapos ng diskoneksyon, hindi pa tapos ang bagong may-ari.
Para sa paglilipat sa Tunnelblick, piliin ang engine para sa configuration, i-enable ang nilalayong integrasyon ng DNS at alisin ang mga direktiba sa profile na sumasalungat dito. Pagkatapos ulitin ang parehong tatlong pagsusuri. Ang koneksyong gumagana ngunit iniiwan ang resolver na nabago ay bigong paglilipat, kahit tumaas ang tunnel.
Hindi tinutukoy ng packaging ang kompatibilidad sa server. Suriin ang sariling pangangailangan ng kliyente ng serbisyo, at piliin lamang ang engine kapag balak mong magbigay ng pamamahala nito.