Pacchetti VPN offline: chiedete alla destinazione di cosa ha bisogno

Serve il client VPN per raggiungere la rete che normalmente fornirebbe i suoi pacchetti, e questo è un piccolo cerchio ben ordinato. Scaricare un solo DEB di OpenVPN su un’altra macchina di solito finisce con una seconda dipendenza mancante, poi una terza, e poi una serata passata a inseguire versioni di librerie. L’alternativa è lasciare che la macchina disconnessa dichiari, nei propri termini, di cosa ha bisogno il suo gestore di pacchetti. Tutto quanto segue deriva da questa inversione di chi pone la domanda.

Sui sistemi della famiglia Debian quella conversazione avviene tramite apt-offline, un flusso di richiesta e ritorno. Il suo ambiente di esecuzione deve essere presente prima sulla destinazione, installato da supporti approvati o da un altro bootstrap gestito dall’amministratore, perché nessuno strumento può avviarsi da solo dal nulla.

Partite dallo stato dei pacchetti della destinazione, non da quello dell’assistente

Annotate la versione della distribuzione della destinazione, l’architettura dello spazio utente e le sorgenti dei pacchetti configurate prima di ogni altra cosa. Questi tre fatti decidono quale implementazione VPN e quale integrazione desktop siano appropriate, e sono i fatti che un assistente connesso non può fornire.

L’assistente scarica file; non diventa la linea di base delle dipendenze. Un portatile più recente che ha già OpenVPN installato ha uno stato dei pacchetti del tutto diverso da quello della destinazione, quindi il suo successo non dimostra nulla su ciò che la destinazione può accettare.

Decidete anche che cosa volete davvero. Il motore VPN, un plugin di servizio di NetworkManager e un editor grafico sono pacchetti separati, e la scelta corretta dipende dalla versione e da come l’utente gestirà la connessione. Un server senza schermo ha bisogno del motore e di un file di configurazione; un desktop ha bisogno del plugin che consente alle sue impostazioni di rete di possedere il tunnel. Richiedere l’insieme sbagliato produce un’installazione che riesce e una connessione che nessuno può avviare.

Due viaggi, in questo ordine

Il manuale separa tre operazioni: generare una richiesta sul sistema disconnesso, scaricarla su un assistente connesso e importarla di nuovo sulla destinazione. Aggiornate i metadati del repository della destinazione prima di richiedere pacchetti, perché la richiesta di pacchetti si costruisce su quei metadati e gli indici obsoleti producono richieste che l’assistente non può soddisfare.

Sulla destinazione, un comando amministrativo nella forma apt-offline set vpn-meta.sig --update scrive la richiesta di aggiornamento. Portate quel file sulla macchina connessa e scaricate un pacchetto con apt-offline get vpn-meta.sig --bundle vpn-meta.zip. Riportate il pacchetto e importatelo sulla destinazione con apt-offline install vpn-meta.zip, di nuovo come amministratore.

Ora generate la richiesta di pacchetti dai metadati aggiornati, per esempio apt-offline set vpn-deps.sig --install-packages openvpn, e ripetete il viaggio con un nuovo nome di pacchetto. Tenete ogni richiesta in coppia con il pacchetto che ha prodotto; un pacchetto generato su metadati più vecchi non è la stessa richiesta, anche quando i nomi dei file sembrano intercambiabili.

Aggiungete i pacchetti di integrazione solo quando il progetto li richiede

Se il desktop deve gestire il tunnel tramite le sue impostazioni di rete, la richiesta ha bisogno del plugin corrispondente oltre al motore. Includete i nomi di pacchetto specifici forniti dalla vostra versione invece di un elenco ricordato da un’altra distribuzione, e generate una nuova richiesta ogni volta che l’elenco cambia. Anche il blocco delle versioni merita riflessione: un pacchetto costruito per una versione più recente può soddisfare il nome e fallire comunque in fase di esecuzione. È qui che un insieme fisso di quattro pacchetti diventa un peso, perché l’elenco corretto è una proprietà della destinazione e solo la destinazione può calcolarlo.

È anche qui che un insieme fisso di quattro pacchetti diventa un peso. L’elenco corretto è una proprietà della destinazione, e la destinazione è l’unica macchina in grado di calcolarlo correttamente.

Importare un pacchetto non è installare il VPN

Nonostante il nome, l’operazione di installazione deposita dati APT nell’ambiente di gestione dei pacchetti. Non esegue la transazione dei pacchetti. Completate e riesaminate l’installazione APT reale della destinazione dai dati forniti localmente, e leggete l’output invece di supporre che il successo dello ZIP significhi che il software è presente.

Se quella transazione chiede ancora file non disponibili, conservate la dipendenza mancante o l’errore di repository specifico e generate la richiesta successiva da esso. Non sostituite con un DEB di un’altra versione e non disattivate i controlli di somma di verifica o di autenticazione del repository per forzarla. Il manuale avverte esplicitamente contro il salto della verifica dei file scaricati, e a ragione: un pacchetto non verificato è un esito peggiore di un’installazione fallita.

I pacchetti sono solo la prima metà

Installare software è distinto dall’ottenere l’endpoint approvato, il profilo, il materiale di fiducia e le credenziali, e ciascuno di questi può avere una propria consegna controllata. Un insieme di pacchetti funzionante senza un profilo valido non si connette a nulla.

Poi mantenete vivo il percorso di trasferimento offline per gli aggiornamenti futuri. Trattare la prima connessione riuscita come la fine della manutenzione significa che il successivo aggiornamento di sicurezza aspetta che qualcuno con un’auto possa passare, ed è così che una rete offline resta silenziosamente indietro di anni.