Trattare tun0 e un protocollo VPN come un’unica cosa manda le persone nel registro sbagliato. L’interfaccia è un confine locale dove un programma nello spazio utente scambia pacchetti IP con il kernel. Il protocollo è ciò che quel programma fa con i pacchetti una volta che li ha: trasporto, autenticazione, cifratura e un pari. Creare il dispositivo non sceglie nulla di tutto ciò.

Due componenti, un solo percorso dei pacchetti

Il kernel scrive un pacchetto IP nel dispositivo e il programma lo legge da un descrittore di file. Nella direzione opposta il programma riscrive un pacchetto e il kernel lo instrada come se fosse arrivato su un’interfaccia reale. TUN trasporta IP, mentre TAP trasporta frame Ethernet. Leggere un pacchetto su quel confine mostra l’incapsulamento, ed è esattamente a questo che serve il dispositivo.

Tutto ciò che sta oltre quel confine è affare del programma. Due programmi possono usare lo stesso concetto di interfaccia e fare cose completamente diverse con i pacchetti. Il dispositivo in sé non ha opinioni su ciò che accade dopo. Il descrittore di file è l’unica presa che il programma ha dal lato del kernel.

Create il dispositivo, poi osservate il confine

Create un dispositivo di proposito quando provate il confine. Un dispositivo persistente sopravvive al processo che lo ha creato, il che è utile per gli esperimenti e una fonte comune di confusione in seguito. Controllate i flag e il proprietario prima di dare la colpa alla VPN.

sudo ip tuntap add dev tun9 mode tun user alice
ip -d link show tun9

I dettagli del collegamento mostrano il tipo di dispositivo e il proprietario associato. Se nessun processo lo tiene aperto, i pacchetti scritti al suo interno non vanno da nessuna parte. Un dispositivo senza processo associato può sembrare sano in un elenco di collegamenti pur non facendo passare nulla.

Ciò che il nome dell’interfaccia non può promettere

Il nome dell’interfaccia non dice nulla sulla cifratura né sull’autenticazione. Un programma può avvolgere i pacchetti in TLS, in un protocollo proprio, in IPsec o in niente. Scegliere TUN invece di TAP cambia l’incapsulamento al confine, non il progetto di sicurezza. La scelta dell’incapsulamento è reale, ed è molto più piccola della questione di sicurezza.

Il rilevamento funziona allo stesso modo: un osservatore vede il protocollo esterno sul filo, non un’etichetta che dica quale dispositivo locale lo ha prodotto. Un tunnel che sembra qualcos’altro lo fa a causa del suo protocollo esterno, non del nome della sua interfaccia. Un osservatore non può vedere quale dispositivo locale ha prodotto un pacchetto, solo come appare il pacchetto. Tenete separate queste due domande quando confrontate prodotti, perché una risposta non implica mai l’altra.

Adattate la correzione allo stadio che fallisce

Separate gli stadi di guasto quando qualcosa si rompe. Un dispositivo mancante, un errore di permessi e un accesso rifiutato producono prove e correzioni diverse. Leggete prima lo stato locale, poi il registro del programma, poi il punto di vista del pari. Leggete tutti e tre prima di cambiare qualcosa.

ip -d link show tun0
journalctl -u openvpn-client@corp --since '10 min ago'

Se il dispositivo esiste e un processo lo tiene, il confine locale funziona e il problema è più in là. Se il dispositivo manca, nessuna verifica delle credenziali aiuterà. Uno stadio che potete nominare è uno stadio che potete provare. La documentazione TUN/TAP descrive il confine e il modello del dispositivo.

Articoli correlati