Tabella di routing contro ricerca reale: dove va il traffico VPN

Un dump della tabella di routing è la diagnostica meno utile nella risoluzione dei problemi VPN e quella più spesso incollata. Quaranta righe di prefissi vi dicono cosa la macchina potrebbe fare, non cosa ha fatto per la richiesta fallita. Il meccanismo che volete davvero è la ricerca: dati questa origine e questa destinazione, quale regola ha corrisposto, quale tabella è stata consultata e quale interfaccia e next hop sono usciti. Partite da una destinazione e un'origine, poi leggete la tabella con quella domanda in mano, e lo stesso output diventa una prova invece di rumore.

Una tabella è un insieme di candidati, non una decisione

Ogni voce descrive un prefisso e cosa fare con il traffico che vi corrisponde: inviarlo a un'interfaccia, passarlo a un next hop o scartarlo. Nulla in quell'elenco è ordinato per intenzione, e la voce che a un umano sembra più specifica non è sempre quella che il kernel seleziona, perché la selezione segue la corrispondenza di prefisso più lunga e, tra prefissi uguali, la metrica.

Quindi il primo passo è chiedere al kernel invece di leggere l'elenco. Il comando di ricerca risponde per una destinazione, e con un argomento di origine risponde per la coppia esatta che userebbe una connessione inoltrata o vincolata:

ip route get 198.51.100.10
ip route get 198.51.100.10 from 10.80.0.25
ip -6 route get 2001:db8:10::40

Ogni indirizzo sopra è un esempio di documentazione. Il punto è la forma della risposta: interfaccia, indirizzo di origine scelto, gateway e la tabella da cui proviene la voce. Se quell'output non corrisponde all'interfaccia attesa, avete localizzato il problema con un solo comando, e nessuna lettura della tabella completa vi avrebbe detto quale candidato ha vinto.

La ricerca attraversa prima le regole, poi le tabelle

Su Linux la decisione è in due fasi. Le regole di policy vengono valutate in ordine di priorità, e la prima regola che corrisponde nomina una tabella da consultare; quella tabella esegue poi la corrispondenza di prefisso più lunga. Una regola può corrispondere su origine, destinazione, marcatura del firewall, interfaccia o una combinazione, ed è per questo che un dump della tabella principale può essere perfettamente accurato e del tutto irrilevante per il pacchetto che state indagando.

ip rule show
ip route show table all | head -40
ip route show table 100

Se una regola invia il traffico del vostro pool VPN alla tabella 100, allora è la tabella 100 che conta, e la tabella principale è un'esca. Questo è anche il meccanismo dietro il routing basato sull'origine su un router: la stessa destinazione può avere due risposte diverse a seconda di dove arriva il pacchetto, e solo la ricerca con un argomento di origine rivela quale si applica.

IPv6 ha le proprie regole e tabelle. Un progetto che esegue entrambe le famiglie ha bisogno di entrambe le ricerche, e una risposta IPv4 funzionante non dice nulla sul percorso v6 che un client dual-stack potrebbe preferire.

Cosa installa il client VPN

I client di solito non sostituiscono la route predefinita, perché ciò romperebbe il percorso esterno del tunnel stesso. Installano qualcosa di più specifico che vince per lunghezza del prefisso: una coppia di semi-route predefinite che coprono 0.0.0.0/1 e 128.0.0.0/1 è il trucco classico, poiché entrambe sono prefissi più lunghi di 0.0.0.0/0 e insieme coprono tutto lo spazio. Altri installano prefissi privati specifici più una regola di policy, e alcuni aggiungono una marcatura così che venga catturato solo il traffico selezionato.

Ecco perché "la VPN non ha cambiato la mia route predefinita" non è prova di guasto. Controllate cosa ha effettivamente aggiunto e se la destinazione in questione cade dentro quei prefissi:

ip route show | grep -E 'tun|wg|ppp|ipsec'
ip route get 10.20.30.40 from 10.80.0.25

Due semi-route sono facili da perdere in un dump perché non sembrano una predefinita. Una configurazione split-tunnel che ha dimenticato di includere un prefisso produce esattamente il sintomo che state inseguendo: l'applicazione che dovrebbe usare il tunnel risolve e si connette localmente invece. Confrontate i prefissi installati con le destinazioni di cui l'utente ha davvero bisogno, non con gli indirizzi che avete provato per caso. Un elenco split-tunnel che copre il file server ma non il suo resolver produce una connessione che risolve a un indirizzo pubblico e poi fallisce l'autenticazione, il che sembra un problema di password ed è un problema di route.

Anche la route esterna deve sopravvivere

Il tunnel è esso stesso traffico. I pacchetti che trasportano il carico incapsulato vanno all'indirizzo del peer attraverso l'interfaccia fisica, e quel percorso non deve essere instradato di nuovo nel tunnel. Quando lo è, si ottiene il guasto caratteristico in cui il tunnel si stabilisce e poi smette di far passare traffico, perché il trasporto del tunnel è ora dentro il tunnel.

Controllate l'indirizzo del peer come avete controllato la destinazione interna, e confermate che risolve sull'interfaccia fisica anziché sul tunnel:

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

Una route ricorsiva, una regola di policy che cattura il peer o una route predefinita sostituita da un client full-tunnel sono le tre cause abituali. Tutte e tre sono visibili nella ricerca esterna, e nessuna è visibile in un dump della tabella principale preso a posteriori.

Cosa non può dirvi l'output di routing

Una ricerca corretta significa che il kernel invierebbe il pacchetto in un posto sensato. Non significa che il firewall lo permetta, la policy IPsec lo copra, la regola NAT lo traduca o il lato remoto abbia una route di ritorno. Ognuno di questi è uno stadio successivo, e le note di inoltro di strongSwan descrivono la catena che un pacchetto deve attraversare a entrambe le estremità.

Non tiene conto nemmeno del binding a livello applicativo. Un processo può legarsi a un'interfaccia, impostare una marcatura o usare il proprio resolver e connettersi con un nome che risolve diversamente da quanto avete testato. Quando la ricerca è corretta e la connessione fallisce ancora, la domanda successiva è quale processo la effettua e se quel processo vede la stessa tabella che vedete voi.

Tenete quindi la diagnosi ordinata: nominate la destinazione e l'origine, eseguite la ricerca, leggete solo la tabella e la regola nominate dalla ricerca, poi testate lo stadio successivo. Questa sequenza mantiene un'indagine di routing in pochi minuti e lascia un verbale che qualcun altro può seguire, cosa che una tabella incollata non fa mai.