OpenConnect en macOS: paquete, archivo de versión o clon de git

Tres caminos le dan un cliente OpenConnect en un Mac, y dejan cosas distintas en el disco. Una fórmula de Homebrew instala un binario compilado y el script de red que configura las rutas y el DNS. Un archivo de versión le da código fuente con un sistema de compilación generado. Un clon de git le da código fuente sin él. Elegir el camino equivocado es la razón por la que la gente encuentra un configure ausente pocos minutos después de empezar un tutorial.

Dos máquinas distintas bajo el mismo nombre

El camino del paquete es un solo comando, y es la opción predeterminada correcta para quien su trabajo es conectarse y no desarrollar.

brew install openconnect

Lo que instala importa más que el comando. Obtiene el binario del cliente y también un vpnc-script que el cliente llama para programar la interfaz, las rutas y el resolutor. Los dos trabajan en pareja: el binario termina la sesión TLS y entrega la interfaz resultante al script, que es la parte que sabe cómo este sistema operativo quiere que cambie su red.

Esa separación explica toda una clase de informes confusos. Un cliente que se conecta, informa de éxito y luego envía el tráfico por el camino equivocado suele tener un problema de script, no de túnel, y reinstalar la fórmula lo arregla solo porque el script también se reinstala. Compruebe el soporte actual de la fórmula para macOS y la arquitectura de CPU antes de planificar en torno a ella; un Mac que ejecuta un shell perfectamente puede seguir sin tener un paquete actual compilado para él.

Qué hace realmente el camino del código fuente

Un archivo de versión llega con un sistema de compilación generado, así que el conocido ./configure existe desde el principio. Un clon de git no, porque los archivos generados son productos de compilación y no cosas que el proyecto guarde. Esa es toda la razón por la que ./autogen.sh aparece en las instrucciones para clones y no para archivos de versión.

./autogen.sh
./configure
make
make install

Cada línea hace algo concreto, y saber cuál falló ahorra muchas conjeturas. El paso autogen ejecuta las autotools para producir configure. El paso configure prueba el compilador, las bibliotecas y las cabeceras que necesita el cliente, y luego escribe los makefile que reflejan lo que encontró. El paso make compila. El paso install copia los resultados en algún lugar de su ruta.

Es en esa última línea donde el consejo suele ir mal. La instalación no es prueba de que la compilación funcionara, y ejecutarla en una carpeta de descargas arbitraria con privilegios elevados es una buena manera de esparcir archivos que luego no recordará. Si configure falla por una biblioteca ausente, la salida útil es el primer error que imprimió, no las últimas veinte líneas del registro.

La sesión y la configuración de red están separadas

Esta distinción decide si una conexión transporta tráfico de verdad. Establecer la sesión TLS le da una interfaz en el lado del cliente. Aplicar rutas, direcciones y resolutores DNS es un segundo paso realizado a través del script de red, y una compilación que produjo un binario sin el script tiene medio cliente.

La misma separación explica por qué dos máquinas con clientes idénticos se comportan distinto: el script consulta la configuración de red del sistema, y esa configuración incluye todo lo demás que haya reclamado una ruta. Cuando un túnel dividido envía el tráfico a un lugar inesperado, el túnel hace su trabajo y la decisión de enrutamiento es lo que hay que examinar.

Así que cuando depure, pregunte qué capa falló. Una sesión que nunca se establece es protocolo, certificado o credenciales. Una sesión que se establece y no reenvía nada es la interfaz y el script. Un cliente instalado que funciona desde una red y no desde otra es accesibilidad, y ninguna cantidad de recompilación lo cambia.

Sepa qué binario está ejecutando

Una compilación instalada a mano y un binario empaquetado pueden convivir felizmente, y el que se ejecuta depende de su ruta y no de sus intenciones. Averígüelo antes de informar a alguien de un número de versión.

which -a openconnect
openconnect --version
brew list --versions openconnect

El primer comando lista cada copia que su shell puede ver, en el orden en que las probaría. El segundo le dice cuál respondió. Cuando eso no concuerda con lo que espera, está ejecutando una compilación de un experimento antiguo, y ningún cambio de configuración lo moverá.

Instalar un cliente no es aprobar una pasarela

Un binario que funciona no hace compatible un despliegue. Confirme el protocolo de la pasarela, su flujo de autenticación y cualquier requisito de dispositivo gestionado con las personas que la poseen, porque son hechos de política y de capa de aplicación que una compilación no puede aportar.

Las instrucciones de compilación del proyecto cubren con más detalle la secuencia de autotools y el requisito del script de red, y son la referencia que hay que seguir y no una entrada de blog anterior a su versión de macOS. Si el objetivo es simplemente conectarse, tome el paquete, conserve el script y deje el compilador fuera.