Motor OpenVPN o Tunnelblick: qui posseeix la sessió VPN del Mac?

Homebrew instal·la un programa OpenVPN; Tunnelblick instal·la un gestor que executa un o més motors. Són capes diferents, i la pregunta útil no és si us agrada fer servir un terminal. És qui posseeix la configuració, els canvis de DNS, la petició de credencials i la neteja quan acaba la sessió. Un sol propietari d’aquestes capes és el que fa que la configuració sigui previsible.

Passeu per les cinc comprovacions següents en ordre. La primera que té dos propietaris és la que produeix els estats estranys de mitja connexió que la gent atribueix al mateix OpenVPN. Cada comprovació anomena l’evidència que la resol.

Comprovació primera: quin binari d’OpenVPN s’executa realment

Executeu pgrep -fl openvpn mentre esteu connectats i llegiu la línia d’ordres completa. El primer camí és el motor que s’executa realment. A Apple Silicon, una instal·lació de Homebrew sol viure sota /opt/homebrew, mentre que els Mac Intel fan servir /usr/local, i Tunnelblick executa un motor des de dins del seu propi paquet d’aplicació.

Tunnelblick inclou motors i permet que una configuració n’esculli un. Actualitzar la fórmula de Homebrew canvia el binari autònom, no el motor que llança un perfil de Tunnelblick. Si compareu versions per explicar una diferència de comportament, compareu el motor de la llista de processos i no el del gestor de paquets. La cadena de versió per si sola no us dirà quin perfil ha carregat aquest motor.

Un perfil copiat també pot fer que dos motors semblin idèntics mentre llegeixen fitxers diferents. El camí del perfil a la línia d’ordres us diu quina configuració ha carregat el procés en execució; un perfil obert en un editor no és cap evidència. Compareu aquest camí abans de comparar comportaments.

Comprovació segona: qui canvia el DNS i les rutes

El motor pot executar les directrius up i down pròpies d’OpenVPN, però el gestor pot posseir el mateix cicle de vida. La configuració de servidor de noms de Tunnelblick controla els seus guions estàndard de connexió i desconnexió, i quan aquesta integració està activada, les directrius competidores del perfil es poden ignorar.

Això importa perquè el DNS és on un túnel que funciona sembla trencat més sovint. Comproveu scutil --dns mentre esteu connectats, fixeu-vos quin resolutor és el primer i confirmeu que torna després de desconnectar. Si el perfil espera establir el DNS ell mateix mentre el gestor també el gestiona, un dels dos perdrà.

Decidiu quina capa posseeix el DNS abans de la primera connexió i després traieu la directriu perdedora en lloc de deixar-les totes dues. Els canvis de ruta segueixen la mateixa regla: un propietari, visible a la configuració, amb un camí de restauració documentat.

Comprovació tercera: d’on vénen les credencials

Una petició interactiva i un procés sense supervisió tenen requisits diferents. Una credencial desada per una aplicació no està automàticament disponible per a un altre procés, i un element de l’esquena de claus limitat al gestor pot ser invisible per a un motor autònom iniciat des d’una shell.

Enumerueu la font de credencials del perfil: un certificat i una clau de client, una petició d’usuari i contrasenya, o un testimoni subministrat per un ajudant extern. Després confirmeu que el propietari triat pot arribar a aquesta font sense cap persona si la connexió ha de sobreviure a un reinici.

Comprovació quarta: qui inicia, supervisa i atura el procés

Un desplegament autònom necessita un supervisor si ha de romandre actiu. Launchd pot iniciar el motor a l’inici de sessió o sota demanda, reiniciar-lo després d’una caiguda i aturar-lo net, però algú ha d’escriure aquesta tasca i posseir-la. Executar l’ordre en un terminal funciona per a una prova i no per a un usuari que tanca la finestra.

Si Tunnelblick continua sent el propietari, feu servir els seus controls compatibles en lloc d’iniciar un segon motor. El binari de Homebrew, amb un perfil copiat, obre una connexió independent amb la seva pròpia configuració i context d’integració en lloc de manar la sessió de Tunnelblick existent.

Sigui quin sigui el propietari que trieu, definiu què passa en repòs, en canvi de xarxa i en tancar la sessió. Un gestor normalment s’ocupa d’aquests esdeveniments; un procés nu normalment no, i la ruta o el resolutor obsolets resultants es poden malinterpretar fàcilment com una fallada del servidor.

Comprovació cinquena: com es verifica el traspàs

Proveu el propietari nou amb l’antic desactivat i després torneu a provar l’antic si teniu previst conservar-lo. Un recurs privat que respon en un flux de treball i no en l’altre és evidència de la integració que falta, no del servidor.

Per a un traspàs a un motor autònom, anoteu el camí del perfil, el camí del binari, el supervisor, el propietari del DNS i la font de credencials. Després verifiqueu el recurs privat, el camí a internet públic i una desconnexió neta en aquest ordre. Si el DNS o les rutes romanen després de desconnectar, el propietari nou no ha acabat.

Per a un traspàs a Tunnelblick, seleccioneu el motor per a la configuració, activeu la integració DNS que vulgueu i traieu les directrius del perfil que hi van en contra. Després repetiu les mateixes tres comprovacions. Una connexió que funciona però deixa el resolutor canviat és un traspàs fallit, encara que el túnel s’hagi aixecat.

L’empaquetament no resol la compatibilitat amb el servidor. Comproveu els requisits propis del client del servei i trieu només el motor només quan tingueu la intenció de proporcionar-ne la gestió.