Ho aperto qBittorrent su un Mac mini, impostato Network Interface su utun4, riavviato e poi ho passato un pomeriggio a guardare un torrent fermo sul recupero dei metadati mentre la VPN mostrava ancora una connessione sana. L'impostazione non era sbagliata in linea di principio; il nome era scaduto. macOS assegna i numeri utun all'avvio dei servizi, quindi l'utun4 che era corretto la settimana prima puntava a un tunnel che non esisteva più, e il client associava i suoi socket a un dispositivo senza rotta. La sequenza qui sotto è quella che uso ora: leggere l'interfaccia dal tunnel in esecuzione, selezionarla nel client, riavviare la sessione e poi dimostrare l'associazione con un trasferimento e una disconnessione deliberata.

Aprire Avanzate e trovare il campo dell'interfaccia

Nella finestra di qBittorrent, aprite le Preferenze con Cmd+, e andate alla pagina Avanzate. Network Interface è il campo che conta: elenca i nomi delle interfacce di sistema e per impostazione predefinita è su Any Interface, il che significa che il sistema operativo sceglie una rotta per ogni socket che il client apre. La referenza delle opzioni del progetto documenta il campo e quel valore predefinito, ed è la stessa impostazione su ogni piattaforma anche se i nomi al suo interno non lo sono.

Due dettagli fanno inciampare qui. L'elenco mostra nomi di dispositivi come en0, en1 e utun0 fino a utun9, mai il nome del prodotto del fornitore VPN, quindi serve la corrispondenza prima di poter scegliere qualcosa di sensato. E la selezione viene applicata all'avvio della sessione BitTorrent, non nel momento in cui premete OK, quindi una modifica che sembra salvata può ancora girare sull'associazione vecchia.

Chiudete l'applicazione correttamente con Cmd+Q e confermate che il processo è sparito prima di riaprirla. Chiudere la finestra la nasconde soltanto, e un client nascosto conserva la sessione, la porta in ascolto e la vecchia interfaccia.

pgrep -fl qbittorrent

Trovate l'interfaccia che la vostra VPN possiede davvero

Collegate prima la VPN, tramite il client del fornitore, poi leggete la vista di sistema invece del menu del client. I comandi qui sotto elencano ogni interfaccia con i suoi indirizzi, mostrano quali il sistema considera attive e stampano la tabella di routing; state cercando il dispositivo utun che porta l'intervallo privato assegnato dal fornitore.

ifconfig -a | grep -A4 '^utun'
scutil --nwi
netstat -rn -f inet | head -n 5

Tre letture vi dicono quale dispositivo è il tunnel. La voce utun ha bisogno di un indirizzo inet che appartenga al pool della VPN. scutil --nwi mostra quali interfacce il sistema considera attive e quale è primaria. netstat -rn mostra dove punta la rotta predefinita, e se quella rotta punta ancora a en0 mentre un utun ha un indirizzo, il tunnel non trasporta tutto il traffico, il che cambia ciò che farà l'associazione più avanti.

Quando due tunnel possono esistere contemporaneamente, per esempio un profilo di lavoro e uno personale, entrambi i dispositivi utun sono presenti e solo uno è utile. I contatori di byte risolvono la questione: annotate i contatori, caricate una pagina o avviate un piccolo trasferimento e vedete quale si è mosso.

netstat -ib | grep utun

Non considerate il numero stabile. Una riconnessione può dare allo stesso tunnel un altro nome utun, e un servizio iCloud o Continuity può occupare utun0 molto prima che la vostra VPN si colleghi.

Adattate l'associazione alla portata del tunnel

Il campo associa un dispositivo, e questo è tutto ciò che fa. Se la VPN è un tunnel completo che instrada 0.0.0.0/0 nell'utun, associare a quel dispositivo manda ogni connessione peer e ogni richiesta al tracker attraverso la VPN. Se la VPN è un tunnel diviso che instrada solo alcune sottoreti, associare all'utun manda il traffico dei peer a un dispositivo senza rotta per quei peer, e i trasferimenti si fermano invece di filtrare. Entrambi gli esiti sono più sicuri di Any Interface, ma solo uno mantiene il client funzionante. Nulla fuori dal client cambia: i browser e le altre applicazioni mantengono le proprie rotte, quindi un requisito che copra ogni applicazione deve essere imposto dal lato VPN.

Leggete la situazione prima di selezionare qualcosa:

What you seeWhat it means for the bind
A utun with a provider address and the default route pointing at itFull tunnel; the bind covers peer and tracker traffic
A utun with a provider address but the default route still on en0Split tunnel; the bind will stall transfers unless the provider routes 0.0.0.0/0
No utun carrying a provider addressThe VPN is down or connects on demand; bring it up before selecting
A utun number that changed since the last sessionThe saved name is stale; reselect and restart

Anche la famiglia di indirizzi conta. Un fornitore che assegna solo IPv4 lascia l'interfaccia associata senza indirizzo IPv6, quindi i peer IPv6 falliscono invece di scivolare fuori dal Wi-Fi. Separatamente, associare i socket non fissa la risoluzione dei nomi: i nomi host dei tracker vengono risolti dal resolver di macOS, che segue la configurazione DNS del sistema e non il dispositivo selezionato.

Tre modi in cui una selezione che sembra corretta fallisce

Il primo fallimento è non riavviare. Il campo mostra utun4, le preferenze sembrano configurate, e un trasferimento di prova esce comunque dal Wi-Fi perché la sessione in corso ha mantenuto la vecchia associazione. Chiudete del tutto, confermate con pgrep, riaprite e riavviate il trasferimento.

Il secondo è il nome scaduto dopo una riconnessione. Appena il dispositivo associato sparisce, le connessioni peer falliscono e il client tende a segnalare errori del tracker invece di un messaggio chiaro di interfaccia sparita, che sembra un torrent morto. Rileggete ifconfig, selezionate il nuovo nome e riavviate.

Il terzo è supporre che l'associazione fallisca in modo chiuso. Selezionare un'interfaccia chiede al sistema di collegare i socket a un nome di dispositivo; cosa accada quando quel nome manca o viene riciclato non è garantito dalla schermata delle impostazioni. Il test di disconnessione nella sezione seguente è l'unica prova che conta.

Verificate con un trasferimento reale e una disconnessione

Usate un trasferimento che vi è consentito eseguire, come un'immagine di distribuzione Linux, e avviatelo con la VPN connessa. Osservate i contatori per interfaccia prima e dopo e confrontateli con il contatore dati del client VPN; entrambi dovrebbero salire insieme mentre l'elenco dei peer si riempie.

netstat -ib | grep utun
pgrep -fl qbittorrent

Poi disconnettere la VPN dalla sua stessa interfaccia e osservate il trasferimento. I peer dovrebbero sparire, e le nuove connessioni dovrebbero fallire poco dopo la caduta del tunnel. Se la velocità continua, l'associazione non è in vigore e siete tornati al passo del riavvio, non al firewall.

Riconnettete e controllate di nuovo il nome selezionato, perché il tunnel può tornare con un utun diverso. Una breve nota che registri il tipo di tunnel, il nome dell'interfaccia e il comportamento atteso quando la VPN cade risparmia la sessione successiva: questa impostazione è per macchina e per fornitore, e non sopravvive né a un aggiornamento del client né a un cambio di applicazione VPN.

Articoli correlati