Interfaccia utun della VPN sul Mac attiva ma traffico bloccato? Controlla ifconfig

Hai connesso la VPN, hai eseguito ifconfig, e hai trovato una voce utun4 con un indirizzo sopra. Il sito che ti serviva va ancora in timeout. Quel vuoto è normale: l’elenco dimostra che esiste un’interfaccia virtuale, non che sia il tuo client a possederla, che la rotta che ti interessa la scelga o che i pacchetti la stiano attraversando. Ho smesso di fidarmi del nome dell’interfaccia dopo un pomeriggio passato a dare la colpa al tunnel sbagliato su un portatile che aveva già tre voci utun prima che installassi qualsiasi cosa.

Che cosa contiene davvero una riga utun

Esegui ifconfig -a quando vuoi il quadro completo. Chiamato senza argomenti, ifconfig stampa solo le interfacce attualmente attive, ed è per questo che un tunnel che non è partito può mancare dall’output che le persone incollano nei ticket. ifconfig -l restituisce solo i nomi, ed è il modo più rapido per capire se è comparso un nuovo utun dopo la connessione.

È leggendo una singola interfaccia che si trovano i dettagli utili. Un tunnel connesso di solito si presenta così:

utun4: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
    inet 10.8.0.6 --> 10.8.0.5 netmask 0xffffffff
    inet6 fe80::ce81:b1c:bd2c:69e%utun4 prefixlen 64 scopeid 0x15

Tre campi contengono la risposta. UP e RUNNING dicono che il kernel è disposto a usare l’interfaccia. POINTOPOINT insieme all’indirizzo --> del peer sono la firma di un tunnel e non di un collegamento fisico. Il mtu valore spiega un’intera categoria di segnalazioni «si connette, poi si blocca», perché le interfacce utun di solito salgono con un MTU ridotto, 1380 in diverse build di macOS, e il client può imporne un altro. L’elenco dei campi è abbastanza breve da scorrere una volta nel manuale di ifconfig distribuito da Apple.

Trovare il processo dietro l’interfaccia

ifconfig non ha il concetto di applicazione proprietaria. Due client VPN, un servizio di sistema e un tunnel residuo della settimana scorsa producono voci identiche a questo livello. Sul mio Mac, utun0 fino a utun3 esistevano prima che configurassi qualunque cosa; anche Continuity e iCloud Private Relay usano tunnel, e nessuno di loro è la connessione che stai diagnosticando.

Per i tunnel che registrano una configurazione nel sistema, scutil --nc list è la correlazione più rapida. Stampa ogni configurazione con il suo stato e il suo ID di servizio, e una connessione attiva è contrassegnata come tale:

scutil --nc list
* (Connected)   5F2A9C10-...   VPN  Work IKEv2

I client che gestiscono un proprio processo di tunnel invece di registrare una configurazione non compaiono mai lì. Tunnelblick e un’istanza openvpn da riga di comando rientrano in quel gruppo, quindi controlla anche la tabella dei processi: ps -Ao pid,comm | grep -i openvpn. Una volta che un processo possiede il tunnel, il numero utun appartiene a quel processo e a nient’altro.

Verifica l’indirizzo prima della rotta

Un’interfaccia può essere attiva senza un indirizzo utilizzabile. Un profilo solo IPv6 mostra una voce fe80:: link-local e nulla nella riga inet, e un client che non è riuscito ad applicare un indirizzo assegnato lascia esattamente la stessa forma. Se la destinazione è IPv4 e il tunnel non ha un indirizzo IPv4, la questione di routing è già risolta.

L’MTU merita un controllo a parte, perché il guasto non sembra un problema di dimensione. Sembra una connessione che si autentica e poi tace appena parte un trasferimento grande. Invia una sonda che non deve essere frammentata, dimensionata in modo che il pacchetto corrisponda all’MTU dell’interfaccia; per un MTU di 1400 il payload è di 1372 byte:

ping -D -s 1372 10.8.0.5

Una risposta significa che pacchetti di quella dimensione attraversano il tunnel. Il silenzio mentre i ping piccoli funzionano punta all’MTU o a qualcosa che scarta ICMP lungo il percorso, non all’autenticazione, che era già completata prima ancora che ottenessi un’interfaccia.

Dimostra che la destinazione sceglie il tunnel

La domanda che conta non è se utun4 esista, ma se il traffico verso un indirizzo specifico esce da lì. route -n get risponde a questo per una singola destinazione e stampa il gateway e l’interfaccia che userebbe:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

Se lo stesso comando riporta en0, la tua configurazione split tunneling sta facendo ciò che le è stato detto e nessuna ispezione dell’interfaccia lo cambierà. Usa netstat -rn -f inet quando ti servono la rotta predefinita e l’intera tabella in un’unica vista.

I contatori stabiliscono se i pacchetti si muovono davvero. netstat -ib riporta i totali di pacchetti e byte per interfaccia, voci utun comprese; i numeri sono cumulativi, quindi leggili due volte a distanza e confronta:

netstat -ib | grep utun4

Contatori fermi mentre l’applicazione continua a ritentare significano che il kernel non ha mai consegnato un pacchetto all’interfaccia. Contatori che salgono in entrambe le direzioni mentre l’applicazione continua a fallire spostano l’indagine all’estremità opposta del tunnel.

Quando non compare alcun utun

Un elenco di interfacce vuoto dopo un accesso che sembrava riuscito di solito significa che il tunnel non è mai partito, non che ifconfig lo stia nascondendo. Controlla lo stato del client, poi quello del sistema: una Network Extension che non è mai stata approvata, o che macOS ha disattivato dopo un aggiornamento, non lascia alcuna interfaccia. L’approvazione si trova nelle Impostazioni di Sistema, in Elementi login ed estensioni, e una voce obsoleta lì vale un nuovo interruttore prima di reinstallare qualsiasi cosa.

La numerazione utun non è stabile tra le riconnessioni. Puoi ottenere utun5 dove utun4 esisteva dieci minuti fa, perché la vecchia interfaccia viene smontata e il kernel assegna il successivo indice libero. Gli script che codificano un nome in modo fisso si rompono in silenzio in quel momento; confronta invece l’indirizzo o la rotta.

Mantieni il lato di lettura in sola lettura. sudo ifconfig utun4 down interrompe il tunnel e, su un profilo a tunnel completo, porta via anche la sessione remota, che è un cattivo affare quando stavi solo cercando di raccogliere prove. Niente di ciò che ti serve qui richiede root: leggere flag, indirizzi e contatori funziona con il tuo utente normale.

La prossima volta che un tunnel su Mac si comporta male, esegui i controlli in ordine: conferma che sia comparso un utun con ifconfig -l, leggi i suoi flag, indirizzi e MTU, attribuiscilo a un processo, chiedi a route -n get quale interfaccia usa la destinazione, poi osserva netstat -ib muoversi. Ogni passo esclude uno strato diverso, e il primo che risulta sbagliato è dove va la correzione.