Motor OpenVPN ou Tunnelblick: quen posúe a sesión VPN do Mac?

Homebrew instala un programa OpenVPN; Tunnelblick instala un xestor que executa un ou varios motores. Son capas distintas, e a pregunta útil non é se lle gusta usar un terminal. É quen posúe a configuración, os cambios de DNS, a petición de credenciais e a limpeza ao rematar a sesión. Un único propietario desas capas é o que fai previsible a configuración.

Percorra as cinco comprobacións seguintes en orde. A primeira que ten dous propietarios é a que produce os estraños estados semiconectados que a xente atribúe ao propio OpenVPN. Cada comprobación nomea a evidencia que a resolve.

Comprobación unha: que binario de OpenVPN se executa realmente

Execute pgrep -fl openvpn mentres está conectado e lea a liña de ordes completa. A primeira ruta é o motor que se executa realmente. En Apple Silicon unha instalación de Homebrew adoita estar baixo /opt/homebrew, mentres que os Mac Intel usan /usr/local, e Tunnelblick executa un motor desde dentro do seu propio paquete de aplicación.

Tunnelblick inclúe motores e permite que unha configuración escolla un. Actualizar a fórmula de Homebrew cambia o binario independente, non o motor que lanza un perfil de Tunnelblick. Se compara versións para explicar unha diferenza de comportamento, compare o motor da lista de procesos en lugar do do xestor de paquetes. A cadea de versión por si soa non lle dirá que perfil cargou ese motor.

Un perfil copiado tamén pode facer que dous motores parezan idénticos mentres len ficheiros distintos. A ruta do perfil na liña de ordes dille que configuración cargou o proceso en execución; un perfil aberto nun editor non é evidencia. Compare esa ruta antes de comparar comportamentos.

Comprobación dúas: quen cambia o DNS e as rutas

O motor pode executar as directivas up e down propias de OpenVPN, pero o xestor pode ser dono do mesmo ciclo de vida. Os axustes de servidor de nomes de Tunnelblick controlan os seus scripts estándar de conexión e desconexión, e cando esa integración está activada, as directivas competidoras do perfil poden ignorarse.

Iso importa porque o DNS é onde un túnel que funciona parece roto con máis frecuencia. Comprobe scutil --dns mentres está conectado, anote que resolución é a primeira e confirme que volve tras desconectar. Se o perfil espera establecer o DNS por si mesmo mentres o xestor tamén o xestiona, un dos dous perderá.

Decida que capa é dona do DNS antes da primeira conexión e logo elimine a directiva perdedora en lugar de deixar ambas. Os cambios de ruta seguen a mesma regra: un propietario, visible na configuración, cunha ruta de restauración documentada.

Comprobación tres: de onde veñen as credenciais

Unha petición interactiva e un proceso sen supervisión teñen requisitos distintos. Unha credencial gardada por unha aplicación non está automaticamente dispoñible para outro proceso, e un elemento do chaveiro limitado ao xestor pode ser invisible para un motor independente iniciado desde un shell.

Enumere a fonte de credenciais do perfil: un certificado e unha chave de cliente, unha petición de usuario e contrasinal, ou un token proporcionado por un axudante externo. Despois confirme que o propietario elixido pode chegar a esa fonte sen unha persoa se a conexión debe sobrevivir a un reinicio.

Comprobación catro: quen inicia, supervisa e detén o proceso

Un despregamento independente necesita un supervisor se debe manterse en marcha. Launchd pode iniciar o motor ao iniciar sesión ou a demanda, reinicialo tras un fallo e detelo limpiamente, pero alguén ten que escribir e posuír esa tarefa. Executar a orde nun terminal serve para unha proba e non para un usuario que pecha a xanela.

Se Tunnelblick segue sendo o propietario, use os seus controis compatibles en lugar de iniciar un segundo motor. O binario de Homebrew, dado un perfil copiado, abre unha conexión independente coa súa propia configuración e contexto de integración en lugar de mandar sobre a sesión existente de Tunnelblick.

Calquera que sexa o propietario que elixa, defina que ocorre en repouso, ao cambiar de rede e ao pechar a sesión. Un xestor adoita ocuparse deses eventos; un proceso espido normalmente non, e a ruta ou o resolutor obsoletos resultantes interprétanse facilmente mal como un fallo do servidor.

Comprobación cinco: como se verifica o traspaso

Probe o propietario novo co antigo desactivado e despois probe o antigo de novo se pensa conservalo. Un recurso privado que responde nun fluxo de traballo e non no outro é evidencia da integración que falta, non do servidor.

Para un traspaso a un motor independente, anote a ruta do perfil, a ruta do binario, o supervisor, o propietario do DNS e a fonte de credenciais. Despois verifique o recurso privado, a ruta a internet pública e unha desconexión limpa nesa orde. Se o DNS ou as rutas permanecen tras desconectar, o propietario novo non rematou.

Para un traspaso a Tunnelblick, seleccione o motor para a configuración, active a integración DNS que pretende e elimine as directivas do perfil que se lle opoñen. Despois repita as mesmas tres comprobacións. Unha conexión que funciona pero deixa o resolutor cambiado é un traspaso fallido, aínda que o túnel subise.

A empaquetadura non resolve a compatibilidade co servidor. Comprobe os requisitos propios de cliente do servizo e escolla o motor só cando teña a intención de fornecer a súa xestión.