OpenVPN-motoro aŭ Tunnelblick: kiu posedas la Mac VPN-sesion?
La terminalo ne estas la disdivida linio. Decidu, kiu posedas la sesion: la motoro, kiun vi lanĉas, aŭ la administrilo, kiu prizorgas DNS, akreditaĵojn kaj purigadon.
Homebrew instalas OpenVPN-programon; Tunnelblick instalas administrilon, kiu ruligas unu aŭ plurajn motorojn. Tiuj estas malsamaj tavoloj, kaj la utila demando ne estas, ĉu vi ŝatas uzi terminalon. Ĝi estas, kiu posedas la agordon, la DNS-ŝanĝojn, la peton de akreditaĵoj kaj la purigadon kiam la sesio finiĝas. Unu sola posedanto por tiuj tavoloj estas tio, kio faras la aranĝon antaŭvidebla.
Trairu la kvin kontrolojn sube en ordo. La unua, kiu havas du posedantojn, estas tiu, kiu produktas la strangajn duone-konektitajn statojn, kiujn homoj atribuas al OpenVPN mem. Ĉiu kontrolo nomas la pruvon, kiu ĝin decidas.
Kontrolo unua: kiu OpenVPN-dosiero efektive ruliĝas
Rulu pgrep -fl openvpn dum vi estas konektita kaj legu la plenan komandlinion. La unua vojo estas la motoro, kiu efektive ruliĝas. Sur Apple Silicon Homebrew-instalaĵo kutime loĝas sub /opt/homebrew, dum Intel Mac-oj uzas /usr/local, kaj Tunnelblick ruligas motoron el interne de sia propra aplikaĵa pako.
Tunnelblick kunigas motorojn kaj permesas al agordo elekti unu. Ĝisdatigi la Homebrew-formulon ŝanĝas la sendependan duumdosieron, ne la motoron, kiun lanĉas Tunnelblick-profilo. Se vi komparas versiojn por klarigi kondutan diferencon, komparu la motoron en la proceza listo prefere ol tiun en la pakadministrilo. Nur la versa ĉeno ne diros al vi, kiun profilon tiu motoro ŝargis.
Kopiita profilo ankaŭ povas igi du motorojn aspekti identaj dum ili legas malsamajn dosierojn. La profila vojo en la komandlinio diras al vi, kiun agordon la kuranta procezo ŝargis; profilo malfermita en redaktilo ne estas pruvo. Komparu tiun vojon antaŭ ol kompari konduton.
Kontrolo dua: kiu ŝanĝas DNS kaj vojojn
La motoro povas ruli la proprajn up- kaj down-direktivojn de OpenVPN, sed la administrilo povas posedi la saman vivciklon. La nomservilaj agordoj de Tunnelblick regas ĝiajn normajn konektajn kaj malkonektajn skriptojn, kaj kiam tiu integriĝo estas ŝaltita, konkurantaj direktivoj en la profilo povas esti ignorataj.
Tio gravas ĉar DNS estas la loko, kie funkcianta tunelo plej ofte aspektas rompita. Kontrolu scutil --dns dum vi estas konektita, notu, kiu solvilo estas unua, kaj konfirmu, ke ĝi revenas post malkonekto. Se la profilo atendas agordi DNS mem dum la administrilo ankaŭ administras ĝin, unu el la du perdos.
Decidu, kiu tavolo posedas DNS antaŭ la unua konekto, kaj poste forigu la perdantan direktivon anstataŭ lasi ambaŭ. Vojaj ŝanĝoj sekvas la saman regulon: unu posedanto, videbla en la agordo, kun dokumentita restariga vojo.
Kontrolo tria: de kie venas la akreditaĵoj
Interaga peto kaj procezo sen homa gvatado havas malsamajn postulojn. Akreditaĵo konservita de unu aplikaĵo ne aŭtomate disponeblas al alia procezo, kaj ŝlosiluja ero limigita al la administrilo povas esti nevidebla por sendependa motoro lanĉita el ŝelo.
Listigu la akreditaĵan fonton por la profilo: klienta atestilo kaj ŝlosilo, peto de uzantnomo kaj pasvorto, aŭ ĵetono provizita de ekstera helpanto. Tiam konfirmu, ke la elektita posedanto povas atingi tiun fonton sen homo, se la konekto devas postvivi restarton.
Kontrolo kvara: kiu lanĉas, kontrolas kaj haltigas la procezon
Sendependa starigo bezonas kontrolanton, se ĝi devas resti aktiva. Launchd povas lanĉi la motoron ĉe saluto aŭ laŭpete, restartigi ĝin post kraŝo kaj haltigi ĝin pure, sed iu devas skribi kaj posedi tiun taskon. Ruli la komandon en terminalo taŭgas por testo kaj ne por uzanto, kiu fermas la fenestron.
Se Tunnelblick restas la posedanto, uzu ĝiajn subtenatajn regilojn anstataŭ lanĉi duan motoron. La Homebrew-duumdosiero, ricevinte kopiitan profilon, malfermas sendependan konekton kun sia propra agordo kaj integriĝa kunteksto anstataŭ komandi la ekzistantan Tunnelblick-sesion.
Kiun ajn posedanton vi elektas, difinu, kio okazas ĉe dormo, reta ŝanĝo kaj elsaluto. Administrilo kutime traktas tiujn eventojn; nuda procezo kutime ne, kaj la rezulta kadukiĝinta vojo aŭ solvilo facile mislegiĝas kiel servila paneo.
Kontrolo kvina: kiel la transdono estas kontrolata
Testu la novan posedanton kun la malnova malŝaltita, poste testu la malnovan denove se vi planas reteni ĝin. Privata rimedo, kiu respondas en unu laborfluo kaj ne en la alia, estas pruvo pri la mankanta integriĝo, ne pri la servilo.
Por transdono al sendependa motoro, notu la profilan vojon, la duumdosieran vojon, la kontrolanton, la DNS-posedanton kaj la akreditaĵan fonton. Poste kontrolu la privatan rimedon, la vojon al la publika interreto kaj puran malkonekton en tiu ordo. Se DNS aŭ vojoj restas post malkonekto, la nova posedanto ne finiĝis.
Por transdono al Tunnelblick, elektu la motoron por la agordo, ŝaltu la integriĝon de DNS, kiun vi celas, kaj forigu profilajn direktivojn, kiuj kontraŭas ĝin. Poste ripetu la samajn tri kontrolojn. Konekto, kiu funkcias sed lasas la solvilon ŝanĝita, estas malsukcesa transdono, eĉ se la tunelo leviĝis.
Pakado ne decidas servilan kongruecon. Kontrolu la proprajn klientajn postulojn de la servo, kaj elektu la motoron sola nur kiam vi intencas provizi ĝian administradon.