Perché una rotta VPN non mostra alcun gateway nell'uscita di ip route

Le tabelle di routing vengono lette come rotte ogni volta che la colonna del gateway resta vuota, quando la riga di solito è completa di per sé. Il campo via appare solo quando il kernel consegna il pacchetto a un indirizzo di next hop; una rotta collegata a un'interfaccia raggiunge le sue destinazioni tramite risoluzione a livello di collegamento o tramite un peer punto a punto. Leggere le colonne da sinistra a destra ti dice in quale caso ti trovi, e quella lettura dovrebbe avvenire prima che qualcuno modifichi una rotta predefinita. La maggior parte dei ticket su un gateway mancante finisce su questa distinzione.

Leggi una riga di rotta colonna per colonna

Ogni voce inizia con la destinazione e la lunghezza del suo prefisso, poi aggiunge modificatori in un vocabolario fisso: via, dev, proto, scope, src e metric. Una riga come 198.51.100.0/24 dev tun0 proto kernel scope link src 198.51.100.2 è densa ma completamente specificata. Non le manca nulla e non si implica alcun indirizzo di router.

L'assenza di via è la parte interessante. Senza un next hop, il kernel risolve la destinazione direttamente sull'interfaccia indicata, il che per un tunnel significa consegnare il frame al dispositivo di tunnel e lasciare che l'incapsulamento se ne occupi da lì. proto kernel registra che la voce è stata installata automaticamente quando è stato assegnato un indirizzo, non digitata da un amministratore. scope link dice che la destinazione è raggiungibile su quel collegamento senza passare da un router, e src nomina l'indirizzo che il kernel preferirà come origine per il traffico corrispondente.

Ora leggi una rotta predefinita allo stesso modo: default via 192.0.2.254 dev eth0 proto static metric 100. Qui via è presente perché il pacchetto ha davvero bisogno di un next hop, e quel next hop deve essere a sua volta raggiungibile su eth0. Le due righe non sono varianti l'una dell'altra; rispondono a domande diverse su dove va il traffico.

Due forme di rotta che si confondono tra loro

Una rotta di sottorete del tunnel e una rotta predefinita sembrano simili in uno screenshot e si comportano in modo del tutto diverso. Usa la tabella qui sotto come aiuto alla lettura dei campi, poi conferma i numeri reali sulla macchina che stai correggendo invece di fidarti di un esempio preso da una guida.

Ciò che la tabella non può dirti è l'intenzione. Una rotta diretta verso un intervallo privato attraverso un tunnel è un progetto deliberato di tunnel diviso; la stessa forma su un host che dovrebbe inviare tutto tramite la VPN è un sintomo. L'intenzione vive nella configurazione che ha prodotto la voce, quindi guarda lo strumento che l'ha installata prima di concludere che il kernel abbia sbagliato qualcosa.

Allo stesso modo, un gateway mancante non è il permesso di inventarne uno. Se una rotta ha davvero bisogno di un next hop, quel next hop deve essere raggiungibile sull'interfaccia che lo trasporta, e per un tunnel punto a punto l'indirizzo del peer non è lo stesso oggetto dell'indirizzo locale. Trattare l'indirizzo locale del tunnel come un router Ethernet è un modo comune di produrre una rotta che sembra corretta e non inoltra nulla.

Chiedi al kernel quale riga userà davvero

Leggere la tabella non è lo stesso che eseguire la ricerca, perché il kernel consulta regole di policy, diverse tabelle e voci in cache prima di rispondere. Il verbo che esegue la vera ricerca è ip route get, e stampa la rotta che un pacchetto con quelle proprietà prenderebbe.

ip route get 203.0.113.37 from 198.51.100.2 iif tun0

Sostituisci la destinazione che ti interessa davvero, poi aggiungi from o iif quando il traffico è selezionato per origine o inoltrato, perché una ricerca locale ordinaria può scegliere un percorso diverso da un client inoltrato. La risposta nomina l'interfaccia, l'indirizzo di origine scelto e qualsiasi next hop, che sono le stesse informazioni con cui un pacchetto sarebbe instradato in quel momento.

Se la risposta ti sorprende, stampa le regole prima di cambiare qualsiasi cosa: ip -4 rule show le elenca in ordine di priorità, e un client VPN che installa la propria tabella o una regola per pacchetti marcati non comparirà affatto nella tabella principale. Elencare tutte le tabelle chiude questa lacuna.

ip -4 route show table all | grep -E 'tun|default'

Controlla il sottolivello prima di sostituire la rotta predefinita

I pacchetti del tunnel stesso devono raggiungere l'endpoint remoto, e lo fanno attraverso l'interfaccia fisica usando la rotta che esisteva prima che la VPN salisse. Sostituire l'intera rotta predefinita senza fissare quell'endpoint invia i pacchetti incapsulati nel tunnel che dovrebbero costruire, e la connessione crolla. Conferma prima il percorso verso l'endpoint con una ricerca solo del suo indirizzo.

Tieni separate tre cose quando fai il cambiamento: la rotta verso l'endpoint che deve restare sull'interfaccia fisica, gli intervalli privati che dovrebbero entrare nel tunnel e la rotta predefinita che decide tutto il resto. Separale in quest'ordine, applicane una alla volta e riesegui la ricerca dopo ogni passo. Un ping fallito in seguito dimostra molto poco da solo, dato che permessi, routing delle risposte, DNS e il servizio stesso stanno tutti a valle di una rotta corretta.

Annota i quattro valori che la riga ti ha dato prima della modifica: destinazione, next hop o la sua assenza, dispositivo e origine scelta. Se un cambiamento successivo ne sposta uno, sai quale decisione è stata davvero modificata, e puoi ripristinare una voce invece di indovinare l'intera tabella.