VPN sul Mac bloccata su «Disconnessione»: cosa sta davvero girando

«Disconnessione» è uno stato che il client segnala mentre smonta un tunnel, non un verdetto che il traffico si sia fermato. Su un Mac quello smontaggio avviene come una breve sequenza, e l'etichetta cambia solo dopo che il componente che possiede la connessione risponde. Quando un passo attende un helper, un plugin o una decisione di policy, l'etichetta può restare lì dopo che l'interfaccia è sparita, oppure il tunnel può continuare a inoltrare mentre il menu lo mostra ancora. Trattate il testo come «smontaggio in corso, esito sconosciuto» e stabilite quale metà è vera.

Due guasti sembrano identici dalla barra dei menu e richiedono risposte opposte. In uno il tunnel trasporta ancora pacchetti e solo la visualizzazione è obsoleta. Nell'altro il tunnel è sparito ma una policy separata tiene il traffico bloccato, cosa spesso deliberata. Rotte e stato DNS li separano più in fretta di qualsiasi interazione con il menu.

Cosa segue l'etichetta

Un client VPN mantiene una piccola macchina a stati, e la barra dei menu ne è una proiezione. Per una connessione gestita da macOS stesso, quella macchina sta nel framework VPN di sistema. Per un tunnel gestito da un'app, sta nell'app e nel suo helper privilegiato. L'ultimo passo di un arresto non è chiudere un socket. È rilasciare ciò che rendeva operativo il tunnel: l'interfaccia utun, le rotte che la puntavano, le voci di resolver iniettate dal client e ogni regola di firewall o policy che bloccava il traffico mentre la connessione era attiva.

Quei passi sono separati, quindi un arresto può bloccarsi su uno qualsiasi di essi. Un helper che smette di rispondere, una rotta rivendicata anche da una seconda interfaccia o una voce di resolver posseduta da un altro profilo possono lasciare il client in attesa. L'etichetta è un resoconto del progresso del client stesso, il che la rende autorevole sull'intenzione e inaffidabile sulla rete.

Trovate il componente che possiede la connessione

Nelle configurazioni native, scutil --nc list stampa i servizi noti al sistema e il loro stato, e scutil --nc status "Work VPN" fornisce dettagli su un servizio. Un tunnel tenuto da un'app di terze parti può non comparire affatto in quell'elenco, quindi un risultato vuoto non è prova che nulla sia connesso.

Quando il profilo appartiene a un'app, affidatevi alla sua vista di stato e al suo controllo «Disconnetti» documentato. Chiudere la finestra non è una richiesta di arresto se un helper in background possiede il tunnel; l'icona sparisce e l'helper tiene viva l'interfaccia. La riferimento alle impostazioni VPN di Apple copre i controlli nativi e da dove arrivano le impostazioni gestite.

Leggete interfacce, rotte e DNS

Tre controlli rispondono alla maggior parte della domanda senza toccare la connessione. È la loro interpretazione congiunta che conta, perché ciascuno da solo inganna.

scutil --nc list
netstat -rn -f inet | head -20
ifconfig | grep -A 3 '^utun'
scutil --dns | head -30

• interfaccia utun presente, rotta predefinita o divisa che la attraversa, resolver che punta al provider: il tunnel è ancora attivo e l'etichetta è obsoleta.
• nessuna utun, rotta predefinita ordinaria, DNS da DHCP, niente internet: una policy che blocca a connessione chiusa sta facendo il suo lavoro.
• nessuna utun, nessuna rotta, resolver ancora puntato al provider: lo smontaggio si è fermato a metà, e il DNS è il residuo da pulire.

Poi inviate una richiesta a un host interno che dovrebbe rispondere solo tramite il tunnel e una a un host pubblico. La raggiungibilità separa la policy dallo stato residuo senza trasformare il controllo in un esercizio di misura. Salvate prima il lavoro remoto se il percorso risponde ancora, e predisponete un secondo accesso prima di cambiare la rete su una macchina che amministrate da remoto.

Perché uccisioni indiscriminate e cancellazione del profilo ingannano

Nomi di processo come pppd, racoon e configd appartengono a implementazioni precise. Ucciderli può influire su altre connessioni, lascia rotte e interfacce utun dietro e non vi dà alcuna traccia del passo che si è bloccato. Anche un vecchio nome di processo non è prova che possieda il profilo attuale.

Cancellare e ricreare il profilo è un cambiamento più grande che ripulire una transizione bloccata. Può scartare impostazioni gestite e materiale di identità locale senza spiegare cosa è fallito, e su un Mac sorvegliato può semplicemente essere ripristinato. Tenete la rimozione per una configurazione davvero obsoleta e diagnosticate invece la transizione.

Una sequenza di arresto che lascia traccia

L'ordine seguente lascia al comando i controlli propri della connessione e produce un registro se il blocco ritorna. Vi evita anche di trasformare un problema di visualizzazione in un cambio di rete.

1. Salvate il lavoro remoto e confermate di poter raggiungere il Mac in un altro modo se è remoto.
2. Annotate nome del client, versione e profilo. Catturate una finestra breve con log show --last 5m --predicate 'subsystem == "com.apple.networkextension"'; le versioni più vecchie conservano meno cronologia, quindi eseguitelo subito dopo il blocco.
3. Usate il controllo «Disconnetti» documentato, attendete, poi ripetete i controlli di interfaccia e rotte.
4. Se l'etichetta è obsoleta ma il tunnel è abbassato, lasciatela e lasciate che il client si aggiorni invece di forzare processi.
5. Se lo smontaggio si è davvero bloccato, riavviate il client, poi pianificate un riavvio del Mac una volta salvato il lavoro. Le macchine gestite richiedono la procedura dell'amministratore.

Dopo il recupero, confermate che la rotta predefinita ordinaria e il resolver DHCP siano tornati, e che il traffico bloccato sia ripristinato o ancora bloccato di proposito. Annotate profilo e versione del client con il sintomo, così la prossima occorrenza parte da prove e non da una supposizione nella barra dei menu.