tun precreato in OpenVPN: confronto tra i due modelli di proprietà

Qualcuno ha precreato tun1, il profilo dice dev tun1 e la connessione continua a non agganciarsi. L’esistenza del nome sull’host non dice quasi nulla, perché l’aggancio dipende dallo spazio dei nomi, dal tipo di dispositivo, da chi possiede il collegamento e da ciò che al demone è consentito fare. Riusare un dispositivo impone anche una decisione che la configurazione predefinita nasconde: quale componente scrive gli indirizzi e le rotte. Le modalità di guasto dei due assetti differiscono molto più delle righe di configurazione, quindi decidete prima di modificare un profilo.

Un nome non è un aggancio

dev tun1 chiede a OpenVPN quell’interfaccia con nome, e le build tradizionali nello spazio utente tenteranno di aprirla. Se il nome non segue lo schema abituale tun o tap, il profilo necessita anche di un dev-type corrispondente, perché il tipo non viene mai dedotto da una stringa. Un dispositivo TAP non è un dispositivo TUN con un’etichetta diversa: agganciare quello sbagliato o fallisce subito o produce un collegamento che trasporta frame che nessuno si aspetta. Verificate il tipo prima di ogni altra cosa, poiché ogni controllo successivo presuppone che le due parti siano d’accordo su di esso. Da lì, confermate che il processo possa davvero aprire il dispositivo, e non solo vederlo.

dev tun1
dev-type tun

L’interfaccia di rete e /dev/net/tun sono oggetti diversi: una è un collegamento dentro uno spazio dei nomi, l’altro è il dispositivo a caratteri che un programma nello spazio utente usa per agganciarsi. La documentazione Linux TUN/TAP descrive quel percorso di aggancio e le regole di proprietà per i dispositivi persistenti. Una shell root che può eseguire ip link dimostra solo che la shell ha privilegi, non che li abbia il demone. La proprietà del nodo del dispositivo, l’insieme di capacità del servizio e l’utente con cui viene eseguito devono allinearsi tutti prima che l’apertura riesca.

Un dispositivo che esiste e non si apre è un problema di proprietà, non di instradamento. Trattatelo come tale durante il debug, altrimenti il pomeriggio se ne va leggendo tabelle di routing che non sono mai state il problema.

Chi configura il collegamento: due modelli di proprietà

Nel primo modello OpenVPN configura indirizzi e rotte come parte dell’attivazione della connessione. È il comportamento predefinito e il più facile da ragionare, perché un solo componente crea lo stato e poi lo rimuove. Nel secondo modello un gestore esterno possiede l’interfaccia, e ifconfig-noexec impedisce a OpenVPN di eseguire i propri comandi di configurazione degli indirizzi e consegna i parametri a degli script. Il gestore deve quindi applicare da sé la corretta configurazione locale e del peer, che è più lavoro di quanto il nome dell’opzione suggerisca. Scegliere tra i due è una questione di chi può modificare il collegamento mentre è attivo.

ifconfig-noexec copre solo gli indirizzi: la tabella di routing resta intatta, e la configurazione delle rotte spetta a route-noexec. Trattate le due direttive come controlli distinti con proprietari distinti, perché impostarne una e presumere l’altra è una fonte comune di collegamenti a metà configurazione. Scegliete esattamente un proprietario per livello, gli indirizzi in un posto e le rotte in un posto. Un gestore di rete e un assistente VPN che scrivono entrambi indirizzi è il modo in cui una disconnessione cancella uno stato da cui l’altra parte dipende ancora.

Ispezionate il dispositivo dallo spazio dei nomi che conta

Ispezionate il dispositivo dallo spazio dei nomi in cui gira il processo VPN, non da quello in cui si trova per caso la vostra shell. I due comandi seguenti rispondono a domande diverse, e la differenza emerge quando un host vede un’interfaccia che un container non vede. Eseguiteli nell’ordine indicato, perché il secondo ha senso solo dopo che sapete se il collegamento esiste.

ip -details link show dev tun1
ip tuntap show

Il primo comando stampa il collegamento come lo vede il kernel, inclusi flag e tipo di interfaccia, ed è così che confermate che questo è il dispositivo che intendevate. Il secondo elenca le voci tun/tap persistenti, che esistono senza che alcun processo le trattenga. Un’interfaccia in attesa del proprietario previsto è una situazione diversa da un tunnel attivo agganciato a un’altra VPN, e solo il secondo spiega perché il vostro aggancio fallisce. Trovate il processo che trattiene il dispositivo prima di cambiare qualcosa, perché una voce persistente e un’interfaccia occupata hanno correzioni diverse.

Il supporto multiqueue è una disposizione specifica del driver con requisiti propri, non un permesso per processi non correlati di condividere un’interfaccia. Una sessione attiva di un altro proprietario è un problema di coordinamento, e nessuna modifica al profilo lo risolve.

Due tipi di persistenza

La persistenza del kernel e persist-tun descrivono durate facili da confondere e costose da mescolare. Un dispositivo persistente esiste indipendentemente da qualsiasi processo, quindi sopravvive a un arresto e può essere riutilizzato dall’avvio successivo. persist-tun conserva le risorse attraverso i riavvii morbidi supportati all’interno di un singolo processo OpenVPN, un orizzonte molto più breve. Nessuno dei due promette che fermare il servizio lasci rotte e indirizzi al loro posto, e un’interfaccia che resta visibile non è prova di una sessione cifrata funzionante.

Verificate anche il backend, perché un’interfaccia precreata non dice nulla su quale implementazione la aprirà. Le build della comunità che portano il percorso dati diretto tenteranno di usarla, a meno che il progetto non dica altro. Dove la versione supporta l’interruttore, disable-dco seleziona invece il percorso nello spazio utente; i motori più vecchi e gli altri client non hanno tale direttiva, quindi tenete la condizione di versione accanto all’opzione invece di presumere che si applichi.

Cosa si rompe quando si prova solo l’avvio

Un accordo di proprietà può superare il primo test e fallire l’ultimo, il che rende l’avvio un controllo debole da solo. Osservate invece due transizioni: un riavvio morbido e un arresto completo seguito da un avvio.

systemctl status openvpn-client@lab
ip -details link show dev tun1

L’avvio è il caso facile: l’unità sale, il collegamento appare e l’output di stato nomina il profilo caricato. L’aggancio è il momento in cui il demone apre il dispositivo, quindi eseguite il controllo del collegamento dopo che l’unità segnala di essere attiva, non prima. Se il collegamento esiste mentre lo stato è ancora in attivazione, state guardando un dispositivo persistente a cui nessuno si è ancora agganciato, non un tunnel funzionante. Fate passare traffico reale attraverso il collegamento prima di proseguire, perché un’interfaccia agganciata senza rotta utilizzabile resta un guasto.

kill -SIGHUP $(pidof openvpn)
journalctl -u openvpn-client@lab -n 40
systemctl stop openvpn-client@lab
ip -details link show dev tun1

Un riavvio morbido dovrebbe lasciare la sessione utilizzabile e le risorse intatte, ed è il lavoro che fa persist-tun. L’arresto completo è il punto in cui un gestore esterno si rivela: se il collegamento o i suoi indirizzi sopravvivono all’arresto, qualcun altro li possiede, e quello è o lo stato che avete documentato o il bug che avete appena trovato. Annotate entrambe le osservazioni accanto al profilo, così che la modifica successiva parta da prove e non da uno schema.