Un flusso che dovrebbe attraversare il tunnel prende un next hop diverso, e qualcuno trova un reindirizzamento ICMP in una cattura. È un'ipotesi, non una diagnosi. Un reindirizzamento è un suggerimento del router su un next hop migliore, e se l'host agisca di conseguenza dipende da impostazioni che variano per piattaforma, interfaccia e famiglia di indirizzi.

Un reindirizzamento è un suggerimento del router

I reindirizzamenti ICMP di IPv4 hanno un proprio tipo di messaggio e un insieme ristretto di condizioni: il router inoltra un pacchetto dall'interfaccia da cui è arrivato, e conosce un next hop su quel stesso collegamento più vicino alla destinazione. Poi dice al mittente di usare quel next hop direttamente. Il messaggio nomina il nuovo gateway e include parte del pacchetto originale perché il mittente possa abbinarlo a un flusso. È un messaggio di cortesia sulla topologia locale, e presuppone che il mittente condivida un collegamento con il gateway suggerito.

Il mittente è libero di ignorarlo. Nulla nel protocollo obbliga un host a cambiare la propria tabella, e un reindirizzamento catturato dimostra solo che un router ne ha inviato uno.

È proprio su questa distinzione che la maggior parte delle indagini sui reindirizzamenti sbaglia.

IPv4 e IPv6 lo consegnano diversamente

IPv6 ha un meccanismo analogo dentro la scoperta dei vicini anziché in ICMPv4, con formati di messaggio e regole di validazione diversi. I concetti fanno rima e i pacchetti no. Un filtro di cattura scritto per ICMP tipo 5 non mostrerà nulla su una rete IPv6, cosa che talvolta viene letta come prova che non si sia verificato alcun reindirizzamento.

Anche le impostazioni di politica sono separate, quindi un host può accettare i reindirizzamenti IPv4 e ignorare quelli IPv6, o il contrario.

Controlla entrambe le famiglie se il flusso in questione potrebbe usare l'una o l'altra.

L'accettazione è una politica dell'host, non un fatto della rete

Su Linux l'accettazione dei reindirizzamenti è controllata per interfaccia e globalmente, e i valori predefiniti differiscono tra i ruoli di host e di router. Un'interfaccia di tunnel che accetta reindirizzamenti è un progetto strano, perché dentro un tunnel punto-punto non esiste un next hop alternativo significativo sullo stesso collegamento. Questo rende l'impostazione degna di essere letta invece che presunta.

Le impostazioni di reindirizzamento sicuro limitano ulteriormente quali gateway si possono credere.

Se stai indurendo un host, quelle sono le manopole da rivedere, e sono anche il motivo per cui due macchine sulla stessa rete possono comportarsi diversamente. Cambiale come politica, non come scorciatoia di debug.

Cosa un reindirizzamento non può spiegare

Rotte specifiche, regole di routing basato su politica e interfacce locali spiegano la maggior parte dei percorsi inattesi senza alcun reindirizzamento. Un prefisso più specifico, una regola che corrisponde all'indirizzo sorgente, o un secondo default in un'altra tabella ciascuno di essi supererà la rotta che ti aspettavi. Controllali per primi, perché sono deterministici e visibili.

Le catture obsolete sono l'altra trappola, perché un client che ha cambiato rete ha un gateway locale diverso.

Un vecchio reindirizzamento dall'attacco precedente non spiega nulla del percorso attuale, quindi annota quale interfaccia riceve ora il traffico di controllo.

Controlla la rotta prima di dare la colpa al tunnel

Chiedi al kernel quale rotta userebbe per la destinazione, poi confrontala con la tabella che intendevi. Se la risposta corrisponde alla tabella, nessun reindirizzamento ha cambiato nulla e l'indagine appartiene altrove. Se non corrisponde, cerca un reindirizzamento in cache, una regola di politica o una seconda tabella prima di supporre che il tunnel sia la causa. La ricerca è la verità di base, e tutto il resto è una storia su come ci sia arrivato.

Un reindirizzamento non dovrebbe mai essere la ragione per cui un percorso protetto diventa silenziosamente non protetto, ed è per questo che la politica di accettazione rientra nella revisione di progetto. La definizione nell'RFC 792 resta il riferimento per ciò che il messaggio IPv4 può dire.

Scrivi insieme la ricerca della rotta e il timestamp della cattura, e la persona successiva potrà riprodurre la tua conclusione.

Articoli correlati