Verifica delle route VPN su macOS: route get senza cambiare nulla

Un utente raggiunge l'intranet sulla rete dell'ufficio e non attraverso il tunnel, mentre Impostazioni mostra ancora la VPN come connessa. Modificare la tabella delle route in quel momento rischia di interrompere la sessione remota che stai usando per diagnosticare. Chiedi invece al kernel quale percorso sceglierebbe per l'host che fallisce. L'utility route di macOS ha un'operazione get che risponde esattamente a questo, per una destinazione, senza cambiare nulla.

Interroga l'host che fallisce, non la route predefinita

Uno screenshot della route predefinita dice molto poco su un Mac moderno, perché una destinazione più specifica o una policy limitata possono prevalere su ciò che la route predefinita sembra dire. Il tunnel può essere attivo, la route predefinita può sembrare corretta, e l'unico host che ti serve può comunque essere instradato altrove. Interroga l'indirizzo che fallisce e lascia che il kernel nomini il percorso scelto.

La forma è route -n get seguita dall'indirizzo: route -n get 203.0.113.10, dove l'indirizzo di documentazione rappresenta il tuo obiettivo. Usa la destinazione autorizzata e la famiglia di indirizzi corrispondente, perché una risposta IPv4 non dice nulla su una risorsa solo IPv6. La documentazione dell'utility route descrive l'operazione get e i campi che stampa.

Leggi l'interfaccia e il gateway come prova

Esegui la query prima di connettere la VPN e poi di nuovo dopo, e confronta le righe di interfaccia e gateway. La differenza tra queste due risposte è ciò che il tunnel ha realmente cambiato, ed è molto più utile di un dump completo della tabella. Se l'interfaccia è identica in entrambe le esecuzioni, la route non è mai stata il problema e puoi smettere di guardare l'instradamento.

Annota la destinazione, l'interfaccia, il gateway e l'ora della query prima di trarre una conclusione. L'output è una prova, non una diagnosi: la stessa interfaccia può essere corretta per un host e sbagliata per un altro quando è coinvolto uno split tunneling.

Una route corretta non è una richiesta funzionante

Una route ti dice quale interfaccia userebbe il kernel, niente di più. DNS, un firewall dell'host e l'autorizzazione dell'applicazione stanno tutti sopra quella decisione, e la richiesta può fallire dopo che l'instradamento è riuscito. Conserva il sintomo esatto prima di procedere, perché "non riesce a connettersi" e "si connette ma restituisce un errore" sono indagini diverse con passi successivi diversi. La vista del resolver e la vista dell'interfaccia completano la query di destinazione invece di sostituirla.

Un elenco della tabella di routing ha ancora il suo posto: è così che noti una route predefinita inattesa. Una route predefinita ordinaria rimasta non dimostra che la VPN sia inutilizzata, perché le voci più specifiche vincono su di essa.

Tieni separati il punto finale e la risorsa

Sono coinvolte due ricerche e rispondono a domande diverse. Raggiungere il punto finale è un viaggio esterno attraverso la rete fisica. Raggiungere l'applicazione avviene dentro il tunnel, a un indirizzo che esiste solo sul lato privato. Confondere i due produce il classico loop falso, in cui il punto finale sembra instradarsi attraverso il tunnel che termina. Interroga i due indirizzi separatamente, etichetta ogni risultato, e la confusione scompare.

La sovrapposizione dei prefissi è l'altro caso che vale la pena conoscere. Quando gli intervalli locale e remoto si sovrappongono, decide la corrispondenza del prefisso più lungo, quindi una sottorete locale sovrapposta può oscurare l'indirizzo remoto che ti aspettavi. La destinazione privata appare allora identica a una locale, e la correzione appartiene al piano degli indirizzi e non alla tabella delle route. La query get mostra quale interfaccia ha vinto, e questo è il fatto che ti serve prima di cambiare qualcosa.

Prima leggi, poi cambia

Tieni route add e route delete fuori dal primo passaggio. Su un Mac che amministri da remoto, una modifica distratta della tabella può portare via proprio il percorso di ritorno alla macchina, senza lasciare nessuno in grado di completare la diagnosi. Decidi qual è la route corretta, annota come annullare la modifica e solo allora eseguila. L'ispezione non ha una coda del genere.

La stessa cautela vale per svuotare le cache e riavviare i servizi di rete come prima mossa, perché entrambi distruggono la prova che stavi per leggere. I controlli di sola lettura sono economici, ripetibili e sicuri in qualsiasi ordine. Rendili il passo predefinito, e ricorri a una modifica solo quando la prova la indica.