¿Motor OpenVPN o Tunnelblick: quién es dueño de la sesión VPN del Mac?

Homebrew instala un programa OpenVPN; Tunnelblick instala un gestor que ejecuta uno o varios motores. Son capas distintas, y la pregunta útil no es si le gusta usar una terminal. Es quién es dueño de la configuración, de los cambios de DNS, de la petición de credenciales y de la limpieza al terminar la sesión. Un único propietario para esas capas es lo que hace previsible la instalación.

Recorra las cinco comprobaciones siguientes en orden. La primera que tiene dos propietarios es la que produce los extraños estados semiconectados que la gente achaca al propio OpenVPN. Cada comprobación nombra la evidencia que la resuelve.

Comprobación uno: qué binario de OpenVPN se ejecuta realmente

Ejecute pgrep -fl openvpn mientras está conectado y lea la línea de comandos completa. La primera ruta es el motor que se ejecuta realmente. En Apple Silicon una instalación de Homebrew suele vivir bajo /opt/homebrew, mientras que los Mac Intel usan /usr/local, y Tunnelblick ejecuta un motor desde dentro de su propio paquete de aplicación.

Tunnelblick incluye motores y permite que una configuración elija uno. Actualizar la fórmula de Homebrew cambia el binario independiente, no el motor que lanza un perfil de Tunnelblick. Si compara versiones para explicar una diferencia de comportamiento, compare el motor de la lista de procesos en lugar del del gestor de paquetes. La cadena de versión por sí sola no le dirá qué perfil cargó ese motor.

Un perfil copiado también puede hacer que dos motores parezcan idénticos mientras leen archivos distintos. La ruta del perfil en la línea de comandos le dice qué configuración cargó el proceso en ejecución; un perfil abierto en un editor no es evidencia. Compare esa ruta antes de comparar comportamientos.

Comprobación dos: quién cambia el DNS y las rutas

El motor puede ejecutar las directivas up y down propias de OpenVPN, pero el gestor puede ser dueño del mismo ciclo de vida. Los ajustes de servidor de nombres de Tunnelblick controlan sus scripts estándar de conexión y desconexión, y cuando esa integración está activada, las directivas competidoras del perfil pueden ignorarse.

Eso importa porque el DNS es donde un túnel que funciona parece roto con más frecuencia. Compruebe scutil --dns mientras está conectado, anote qué resolución es la primera y confirme que vuelve tras desconectar. Si el perfil espera establecer el DNS por sí mismo mientras el gestor también lo gestiona, uno de los dos perderá.

Decida qué capa es dueña del DNS antes de la primera conexión y luego elimine la directiva perdedora en lugar de dejar ambas. Los cambios de ruta siguen la misma regla: un propietario, visible en la configuración, con una ruta de restauración documentada.

Comprobación tres: de dónde vienen las credenciales

Una petición interactiva y un proceso sin supervisión tienen requisitos distintos. Una credencial guardada por una aplicación no está disponible automáticamente para otro proceso, y un elemento del llavero limitado al gestor puede ser invisible para un motor independiente iniciado desde un shell.

Enumere la fuente de credenciales del perfil: un certificado y una clave de cliente, una petición de usuario y contraseña, o un token proporcionado por un asistente externo. Después confirme que el propietario elegido puede llegar a esa fuente sin una persona si la conexión debe sobrevivir a un reinicio.

Comprobación cuatro: quién inicia, supervisa y detiene el proceso

Un despliegue independiente necesita un supervisor si debe mantenerse en marcha. Launchd puede iniciar el motor al iniciar sesión o a demanda, reiniciarlo tras un fallo y detenerlo limpiamente, pero alguien tiene que escribir y poseer esa tarea. Ejecutar el comando en una terminal sirve para una prueba y no para un usuario que cierra la ventana.

Si Tunnelblick sigue siendo el propietario, use sus controles compatibles en lugar de iniciar un segundo motor. El binario de Homebrew, dado un perfil copiado, abre una conexión independiente con su propia configuración y contexto de integración en lugar de mandar sobre la sesión existente de Tunnelblick.

Sea cual sea el propietario que elija, defina qué ocurre en reposo, al cambiar de red y al cerrar sesión. Un gestor suele ocuparse de esos eventos; un proceso desnudo normalmente no, y la ruta o el resolutor obsoletos resultantes se malinterpretan fácilmente como un fallo del servidor.

Comprobación cinco: cómo se verifica el traspaso

Pruebe el propietario nuevo con el antiguo desactivado y luego vuelva a probar el antiguo si piensa conservarlo. Un recurso privado que responde en un flujo de trabajo y no en el otro es evidencia de la integración que falta, no del servidor.

Para un traspaso a un motor independiente, anote la ruta del perfil, la ruta del binario, el supervisor, el propietario del DNS y la fuente de credenciales. Luego verifique el recurso privado, la ruta a internet pública y una desconexión limpia en ese orden. Si el DNS o las rutas permanecen tras desconectar, el propietario nuevo no ha terminado.

Para un traspaso a Tunnelblick, seleccione el motor para la configuración, active la integración DNS que pretende y elimine las directivas del perfil que se le oponen. Después repita las mismas tres comprobaciones. Una conexión que funciona pero deja el resolutor cambiado es un traspaso fallido, aunque el túnel haya subido.

El empaquetado no resuelve la compatibilidad con el servidor. Compruebe los requisitos propios de cliente del servicio y elija el motor solo cuando tenga la intención de aportar su gestión.