OpenConnect vpnc-script: quale file viene eseguito?

OpenConnect può completare la stretta di mano del tunnel e lasciarvi comunque senza rotta verso la sottorete privata, perché il client e l’helper che modifica lo stato della rete locale sono due programmi diversi. L’autenticazione dimostra che il gateway ha accettato la sessione; non dimostra nulla su quale interfaccia, quali rotte o quali impostazioni del resolver siano state installate dopo. La maggior parte dei resoconti confusi nasce dal sostituire l’helper con una copia presa da una vecchia risposta, cosa che cambia il comportamento di ogni connessione sulla macchina. Individuate l’helper che il client in esecuzione chiama davvero prima di modificarne qualsiasi parte.

Due programmi, due responsabilità

Il client possiede il trasporto, l’autenticazione e il dispositivo del tunnel. Un helper separato possiede ciò che accade nel sistema locale una volta che il tunnel esiste: l’indirizzamento sull’interfaccia, le rotte verso le sottoreti annunciate dal gateway e la configurazione del resolver. La documentazione dell’helper di OpenConnect descrive questa separazione e l’ambiente che l’helper riceve. La distinzione conta durante un guasto, perché una password rifiutata e una rotta mancante non sono lo stesso incidente anche quando il desktop mostra un’unica finestra per entrambi.

Tenere presente questa separazione spiega anche perché una connessione può riportare successo mentre i nomi privati ancora non si risolvono. Il tunnel è attivo in entrambi i casi e cambia solo la fase di integrazione locale.

Individuate l’helper usato dal client in esecuzione

Il percorso viene fissato quando il pacchetto è compilato e può essere sovrascritto a ogni invocazione, quindi il file che ricordate da un’altra distribuzione potrebbe non avere nulla a che fare con questa connessione. Chiedete al processo in esecuzione, non alla documentazione che avete aperta per caso.

openconnect --version
ps -o args= -C openconnect
dpkg -L openconnect | grep -i script
ls -l /etc/vpnc/ 2>/dev/null

Se la riga di processo porta un --script argomento, quel file vince sul valore predefinito compilato. Percorsi più vecchi come /etc/vpnc/vpnc-script possono esistere e restare inutilizzati, ed è per questo che cancellarli o modificarli non cambia nulla su una build recente. Controllate anche la data di modifica, perché un helper che nessuno ha toccato per anni è un segno forte che il valore predefinito del pacchetto sta facendo il lavoro.

L’integrazione con NetworkManager è un terzo proprietario, con il proprio helper e le proprie impostazioni del profilo. Impilare un secondo script di rotte o del resolver su quell’integrazione duplica le rotte e lascia un resolver che due programmi affermano di gestire. Scegliete un solo proprietario per connessione e disattivate l’altro prima di provare.

Leggete la prima operazione fallita, non l’ultimo avviso

La configurazione dell’interfaccia, l’installazione delle rotte, la scelta del resolver e la pulizia dello stato obsoleto sono passaggi separati, e l’avviso stampato per ultimo è spesso una lamentela di pulizia e non il guasto che ha rotto la connessione. Leggete verso l’alto fino alla prima operazione precisa che ha fallito. Un errore dell’helper che nomina un file o un indirizzo vale più di dieci righe di rumore di smontaggio.

Confrontate il risultato locale previsto con quello osservato: il dispositivo del tunnel esiste, una rotta verso un indirizzo privato noto ci passa attraverso e il resolver risponde per un nome privato. Un helper che riesce nei primi due e fallisce nel terzo indica la politica del resolver e non l’instradamento. Un helper che non configura affatto il dispositivo probabilmente non è mai stato eseguito, e questa è una questione di permessi e non di rete. Confermate il bit eseguibile e l’account di servizio prima di riscrivere qualsiasi logica.

Verificate connessione, riconnessione e disconnessione

La configurazione è solo metà del contratto, perché lo stesso helper deve ripristinare o rimuovere lo stato che possiede quando il tunnel si chiude. Un helper che aggiunge rotte e non le rimuove mai lascia la macchina con un percorso obsoleto che sopravvive alla sessione.

ip -brief address show tun0
ip route get 10.24.8.15
resolvectl status tun0
journalctl -u NetworkManager -b --no-pager | grep -i -E 'vpnc|script'

Eseguite le prime tre mentre siete connessi, disconnettete e poi eseguitele di nuovo e confermate che la rotta e la voce del resolver siano sparite. La quarta riga mostra se l’helper è stato invocato del tutto e quale percorso eseguibile ha usato il servizio. Conservate quella coppia di output nel ticket, perché è il prima-e-dopo che rende evidente un bug di pulizia.

Mantenete l’helper impacchettato ed eseguibile dall’account di servizio, perché uno script che gira nella vostra shell può comunque essere negato sotto una politica di servizio limitata. Quando una personalizzazione è davvero necessaria, documentatene lo scopo e il proprietario e confrontatela con la versione impacchettata a ogni aggiornamento. Un fork inspiegato di un helper è una delle poche cose che possono far fallire una connessione funzionante un anno dopo.