Perché route -interface non raggiunge un host fuori dal collegamento

route accetta il nome dell’interfaccia Wi-Fi, esce senza lamentarsi e l’host resta irraggiungibile. Nulla è corrotto; la relazione nella rotta è semplicemente sbagliata: un flag di interfaccia dice su quale collegamento si trova una destinazione, non quale router deve ricevere il traffico per una destinazione che sta altrove. Il comando riesce perché è sintatticamente valido, non perché descrive un percorso funzionante.

Questa distinzione decide se un’eccezione di rotta accanto a una VPN funzionerà o sembrerà solo plausibile.

L’interfaccia è l’uscita, il prossimo hop è la consegna

Su un Mac con indirizzo 192.168.50.20 e un router a 192.168.50.1, un’altra macchina sullo stesso collegamento è raggiungibile direttamente. La trama è indirizzata a quella macchina e messa sul cavo. Nessun router è coinvolto, e una rotta limitata all’interfaccia esprime esattamente questo. Cambiate l’estremità remota con un host in un altro edificio e lo stesso comando smette di avere senso. Il Mac non ha un indirizzo di secondo livello da mettere sul cavo, quindi il flag di interfaccia non ha nulla da descrivere.

Una destinazione fuori dal collegamento è diversa. Il Mac non può mettere sul cavo una trama indirizzata a un host che non raggiunge al secondo livello; consegna il pacchetto a un router che può farlo. La rotta ha quindi bisogno di un gateway, e il gateway stesso deve essere raggiungibile sul collegamento collegato.

Usare il flag di interfaccia per una destinazione fuori dal collegamento dice a macOS di trattare quella destinazione come se fosse sul cavo. Il kernel allora non riesce a risolvere un indirizzo di secondo livello per essa, e il pacchetto viene scartato senza nulla di utile nell’errore.

Che cosa afferma davvero il flag di interfaccia

Il riferimento alle rotte di Apple definisce la forma con interfaccia per destinazioni raggiungibili direttamente senza intermediari. È un’affermazione sul modello del collegamento, non una preferenza su quale adattatore usare. Raggiungere un host internet via Wi-Fi richiede comunque un router su quel collegamento Wi-Fi, e la rotta deve nominarlo.

L’ambito dell’interfaccia è un attributo separato. Associa una rotta a una particolare interfaccia per decisioni di ambito come quale indirizzo sorgente si applica, ma non crea raggiungibilità per una destinazione che l’interfaccia non può raggiungere da sola. I due attributi rispondono a domande diverse.

Ecco perché un comando può essere accettato, comparire nella tabella e comunque fallire. Il kernel non convalida la vostra intenzione; registra ciò che avete affermato, e l’affermazione era che la destinazione è sul collegamento. Un successo silenzioso seguito da uno scarto silenzioso è il risultato atteso, non un bug. Rileggete l’affermazione prima di dare la colpa alla rete.

La rotta di cui ha bisogno una destinazione fuori dal collegamento

Per un percorso approvato verso un indirizzo di documentazione come 198.51.100.25 attraverso il router LAN, la relazione prevista è una destinazione, un prossimo hop di 192.168.50.1 e l’interfaccia LAN che raggiunge quel prossimo hop. L’interfaccia è implicita dalla ricerca del prossimo hop invece di essere imposta dal comando di rotta.

Su macOS l’ispezione in sola lettura è route -n get 198.51.100.25. Leggete insieme le righe del gateway e dell’interfaccia e verificate che il gateway sia un indirizzo che il Mac può davvero raggiungere. Un gateway su un’altra sottorete, o uno scomparso dall’ultimo cambio di rete, produce una rotta che sembra corretta e non inoltra nulla.

Non codificate en0 in un’istruzione duratura. I nomi delle interfacce cambiano con adattatori, dock e client VPN, e una rotta che nomina quello sbagliato fallisce in un modo facile da fraintendere come guasto di rete più ampio.

Leggete la scelta attuale prima di sostituirla

Prima di aggiungere qualsiasi cosa, ispezionate ciò che il sistema ha già scelto e perché. Quell’output vi dice se il traffico passa dal tunnel, dal router LAN o da nessuna parte, e vi dà una base per confrontare dopo la modifica. Senza di esso, non potete sapere se la nuova rotta ha avuto effetto.

Poi controllate la famiglia di indirizzi. Una rotta aggiunta per IPv4 non fa nulla per una destinazione IPv6, e un servizio che risolve in entrambe le famiglie può sembrare raggiungibile a intermittenza. La tabella delle rotte e il resolver rispondono a domande diverse, ed entrambi devono concordare con il percorso previsto.

Infine, ricordate che una rotta è una selezione, non un permesso. Un profilo VPN gestito o un filtro client possono ancora vietare il percorso diretto anche quando la tabella lo indica, quindi testate con l’applicazione reale invece di presumere che una voce riuscita nella tabella chiuda l’indagine.

I tunnel e le politiche cambiano la forma

Le interfacce punto a punto sono un caso a sé. Un tunnel può portare una rotta senza un indirizzo di gateway in stile Ethernet, e questo non è automaticamente sbagliato. Applicate il modello di collegamento reale dell’interfaccia invece di estendere un esempio Wi-Fi a ogni voce di tabella che vedete.

Per le richieste di modifica, annotate la destinazione, il percorso di rete approvato, il gateway e l’interfaccia attuali, e chi dovrebbe mantenere l’eccezione. Il proprietario conta perché una rotta una tantum digitata al prompt non è una politica, e la prossima riconnessione la cancellerà.

Se il requisito è raggiungere questo host mentre la VPN è attiva, la risposta onesta è di solito una rotta host specifica attraverso il router locale, installata dal gestore di rete che possiede l’interfaccia. Se il requisito è raggiungere qualsiasi cosa direttamente, il requisito stesso ha bisogno di una revisione delle politiche prima di aver bisogno di un comando di rotta.