OpenConnect su macOS: pacchetto, archivio di versione o clone git

Tre percorsi ti danno un client OpenConnect su un Mac, e lasciano cose diverse sul disco. Una formula Homebrew installa un binario compilato e lo script di rete che configura rotte e DNS. Un archivio di versione ti dà il codice sorgente con un sistema di compilazione generato. Un clone git ti dà il codice sorgente senza. Scegliere quello sbagliato è il motivo per cui le persone incontrano un configure mancante pochi minuti dopo l'inizio di un tutorial.

Due macchine diverse sotto lo stesso nome

Il percorso del pacchetto è un solo comando, ed è il valore predefinito giusto per chi ha il compito di connettersi anziché sviluppare.

brew install openconnect

Ciò che installa conta più del comando. Ottieni il binario del client e ottieni anche uno vpnc-script che il client chiama per programmare l'interfaccia, le rotte e il resolver. I due lavorano in coppia: il binario termina la sessione TLS e consegna l'interfaccia risultante allo script, e lo script è la parte che sa come questo sistema operativo vuole che la sua rete venga modificata.

Questa separazione spiega un'intera classe di resoconti confusi. Un client che si connette, segnala successo e poi invia il traffico sul percorso sbagliato ha di solito un problema di script, non di tunnel, e reinstallare la formula lo corregge solo perché anche lo script viene reinstallato. Controlla il supporto attuale della formula per macOS e per l'architettura della CPU prima di pianificare su di essa; un Mac che esegue perfettamente una shell potrebbe non avere ancora un pacchetto attuale compilato per lui.

Cosa fa davvero il percorso del sorgente

Un archivio di versione arriva con un sistema di compilazione generato, quindi il familiare ./configure esiste fin dall'inizio. Un clone git no, perché i file generati sono prodotti di compilazione e non cose che il progetto conserva. È tutta la ragione per cui ./autogen.sh appare nelle istruzioni per i cloni e non per gli archivi di versione.

./autogen.sh
./configure
make
make install

Ogni riga fa qualcosa di specifico, e sapere quale ha fallito risparmia molte congetture. Il passo autogen esegue gli autotools per produrre configure. Il passo configure verifica il compilatore, le librerie e le intestazioni di cui il client ha bisogno, poi scrive i makefile che riflettono ciò che ha trovato. Il passo make compila. Il passo install copia i risultati da qualche parte nel tuo percorso.

È su quell'ultima riga che i consigli spesso vanno storti. L'installazione non è prova che la compilazione abbia funzionato, ed eseguirla in una cartella di download arbitraria con privilegi elevati è un buon modo per spargere file che poi non ricorderai. Se configure fallisce per una libreria mancante, l'output utile è il primo errore stampato, non le ultime venti righe del registro.

Sessione e configurazione di rete sono separate

Questa distinzione decide se una connessione trasporta davvero traffico. Stabilire la sessione TLS ti dà un'interfaccia sul lato client. Applicare rotte, indirizzi e resolver DNS è un secondo passo eseguito tramite lo script di rete, e una compilazione che ha prodotto un binario senza lo script ha mezzo client.

La stessa separazione spiega perché due macchine con client identici si comportano diversamente: lo script consulta la configurazione di rete del sistema, e quella configurazione include qualunque altra cosa abbia rivendicato una rotta. Quando un tunnel diviso invia il traffico in un posto inatteso, il tunnel fa il suo lavoro ed è la decisione di instradamento che va esaminata.

Quindi quando fai debug, chiedi quale strato ha fallito. Una sessione che non si stabilisce mai è protocollo, certificato o credenziali. Una sessione che si stabilisce e non inoltra nulla è l'interfaccia e lo script. Un client installato che funziona da una rete e non da un'altra è raggiungibilità, e nessuna ricompilazione lo cambia.

Sappi quale binario stai eseguendo

Una compilazione installata a mano e un binario pacchettizzato possono convivere felicemente, e quello che viene eseguito dipende dal tuo percorso e non dalle tue intenzioni. Scoprilo prima di riferire un numero di versione a qualcuno.

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

Il primo comando elenca ogni copia che la tua shell vede, nell'ordine in cui le proverebbe. Il secondo ti dice quale ha risposto. Quando ciò non concorda con le tue aspettative, stai eseguendo una compilazione da un vecchio esperimento, e nessun cambio di configurazione la sposterà.

Installare un client non è un'approvazione del gateway

Un binario funzionante non rende compatibile un'implementazione. Conferma il protocollo del gateway, il suo flusso di autenticazione e qualsiasi requisito di dispositivo gestito con le persone che lo possiedono, perché sono fatti di politica e di livello applicativo che una compilazione non può fornire.

Le istruzioni di compilazione del progetto coprono più in dettaglio la sequenza autotools e il requisito dello script di rete, e sono il riferimento da seguire e non un post di blog più vecchio della tua versione di macOS. Se l'obiettivo è solo connettersi, prendi il pacchetto, conserva lo script e lascia fuori il compilatore.