Andrea Beggi

If I could, I would, but I can't so I shan't.

ICMP Redirect Message: come convivono due router sulla stessa rete

A T T E N Z I O N E ! Questo post ha piu' di sei mesi. Le informazioni contenute potrebbero non essere aggiornate.

Il caso tipico è quello di una rete che usa un router per uscire su internet ed uno per una connessione VPN verso una sede remota. Ne avevo parlato anche qui. Per semplificare le cose in quel post assumo che sia il default gateway a inoltrare il traffico verso l’altro router, in realtà tutto il meccanismo viene gestito tramite messaggi ICMP.

Come l’acronimo lascia intendere (Internet Control Message Protocol), questo protocollo non viene utilizzato per trasmettere dati, anzi non viene proprio impiegato dalle applicazioni (tranne ping e traceroute, ma sono comunque diagnostiche), bensì per trasmettere errori e segnali di controllo per il traffico TCP.

Tornando al caso in questione, sul router che rappresenta il default gateway c’è una static route che reindirizza il traffico destinato alla rete della sede remota verso il router che gestisce la VPN. In realtà il router invia un messaggio ICMP Redirect che induce gli host ad aggiornare la loro tabella di routing per indirizzare il traffico al gateway corretto.

Come prescrive la RFC 1122(*), i messaggi ICMP Redirect sono di pertinenza dei gateway e non devono mai essere inviati dagli host. Inoltre, tutti gli host sono tenuti a onorare tali messaggi utilizzando a tale scopo una “route cache” dinamica. Il primo pacchetto viene inoltrato direttamente dal default gateway al router “secondario” e nel contempo viene inviato all’host origine un ICMP Redirect, che aggiorna la route cache e fa sì che da quel momento in poi il traffico interessato transiti direttamente per il secondo router.

Tutto molto bello, pratico e funzionante. Tranne che per gli IBM AS/400. Malgrado la RFC sia categorica (“A host receiving a Redirect message MUST update its routing information accordingly.”), lo stack TCP/IP degli AS/400 non obbedisce ai messaggi ICMP Redirect e gli ignora bellamente. Nel caso in oggetto quindi, oltre alla rotta statica sul default gateway, che fa funzionare gli host “obbedienti” senza doverli neppure toccare, è necessario inserire una entry direttamente nella tabella di routing dell”AS, altrimenti i pacchetti di ritorno agli host della sede remota non giungerebbero a destinazione.

(*) …che è interessantissima e spiega un fottìo di cose su come funzionano le comunicazioni tra gli host di una rete.

Tags: , , , , , ,

20 Commenti

Francesco | #

Salve,
articolo interessantissimo, ma alla fine quello che mi ha colpito è stato l’uso di un termine desueto: “fottìo”. Mi riporta indietro nel tempo, mia madre, che comunque non è vecchissima, ha 60 anni, lo usa frequentemente, questa mattina, solo con una parola, mi hai restituito ad una dimensione … familiare.

Un saluto

Cius | #

E ti pareva che gli AS non dovessero distinguersi. Interessante, grazie.

spider | #

Come ho avuto modo di sottolineare nel post che linki, affidarsi all’esistenza degli ICMP redirect è una sciocchezza. Può essere usato in casi particolari e solo temporaneamente. Perché se hai provato a sniffare il traffico che viene generato in una configurazione del genere, ti sarai accorto che col cavolo che la route cache viene creata: ogni pacchetto viene inviato al gateway giusto, questo invia l’icmp redirect, e l’host rispedisce il pacchetto al gateway modificato. Per ogni pacchetto.
Ma anche funzionasse quello che continuo a chiedermi è: perché uno dovrebbe volere una configurazione del genere, se non perché non è stato capace di crearne un’altra più pulita, gestibile, scalabile e soprattutto debuggabile?

Andrea | #

Spider, cosa faresti tu nel caso in questione?

spider | #

Andrea, visto che escluderei anche le rotte statiche sui client (per lo stesso motivo di difficile gestione – a meno che non esista un’infrastruttura Active Directory nel qual caso puoi farlo tramite i profili) puoi usare un protocollo di routing dinamico; il più semplice da configurare e praticamente supportato da tutti è RIP (magari v2). Lo attivi sui due router e sui client, lo configuri una volta e non ci pensi più.

Andrea | #

Mi sembra più semplice la mia soluzione: non tocchi i client. E comunque non hai la garanzia che robe come AS/400 funzionino.
Ma soprattutto, quello che propongo funziona bene, visto che ho parecchie installazioni che vanno avanti così da anni senza il minimo problema.
Le static route esistono apposta.

Fabio | #

le route statiche sono passabili ai client anche come opzioni DHCP

Giuliano | #

L’ICMP redirect è comodissimo, ha lo svantaggio di generare un po’ di traffico ICMP, appunto.
La via del routing dinamico non mi pare praticabile, certamente non sui client.
Secondo me la cosa più “sensata” (ma non a costo zero) sarebbe che almeno lo switch centro-stella avesse funzionalità “Layer 3″. Il default gateway verrebbe spostato dal firewall al centro-stella e solo su quest’ultimo si configurerebbero le route statiche…


Giuliano

spider | #

Sì certo, tutto funziona.
Solo che quando tu vincerai la lotteria e te ne andrai a goderti la vita alle Bahamas perché ti piace stare in un posto caldo, quello che prenderà il tuo posto impazzirà a capire come funziona quella rete. Non quando funziona, ma quando ci sarà un problema di routing.
Secondo me la differenza tra uno smanettone e un professionista è che il promo fa funzionare le cose, il secondo le fa bene. Con questo non ti sto dando dello smanettone, magari quella rete ha tre client e allora rompersi le balle con RIP o DHCP o Active Directory può non valere la pena. Ma il fatto è che lo proponi come “soluzione” una cosa che non lo è, al massimo è una toppa.
Lo schema che suggerisci va bene per utilizzi temporanei: sto migrando da un provider a un altro, con un periodo di convivenza. Sul vecchio metto una rotta statica in modo che tutto il traffico sia reindirizzato sul nuovo, e con calma cambio le configurazioni dei client. Oppure, seguendo il tuo caso specifico, installo la VPN, per farla funzionare metto quella rotta statica sul gateway, configuro la mia rete per non doverne avere bisogno, e alla fine la tolgo.
Poi, ovviamente, fai come ti pare. Mi dispiacerebbe però che mentre sei alle Bahamas ti arrivassero le maledizioni del tuo successore :-D

Andrea | #

Spider, grazie per l’augurio. Per il resto mi sembra che tu abbia un atteggiamento inutilmente aggressivo in questioni tecniche che dovrebbero esulare dalle convinzioni “religiose”.
Delle reti più grandi esiste una documentazione, spesso corredata da schemi.
Non mi sento uno smanettone perché applico una RFC.
Non ho capito cosa vuol dire concretamente “configuro la mia rete per non doverne avere bisogno, e alla fine la tolgo.”, lasciando stare il RIP, che non è il caso. I router devono rimanere due, se ne aggiungo un’altro, le rotte statiche ce le devo comunque mettere, anche se mi risparmio l’ICMP. E si tratta comunque di una altro router da gestire, cioè un ulteriore point of failure.

spider | #

Andrea, se la rete è grande (>50 host), non ci sono scuse per usare quella configurazione.
Se la rete è piccola (molto piccola), amen.
E a proposito di single point of failure, che succede adesso se si rompe il default gateway? ;) Succede che non vai più manco sulla VPN, che invece funzionerebbe.
Sono aggressivo? Bah, può darsi. Sono uno di quelli che quando entra in una rete del genere, magari per inserire un firewall, e si trova in quel casino (perché *è* un casino), le maledizioni a chi ha fatto quella configurazione le manda, e non manca di far presente al cliente, che di solito capisce, il motivo di cotanto imprecare.

Andrea | #

Ok, sono opinioni. Mi spieghi la tua soluzione al problema senza usare il RIP?.

spider | #

Daje. Te l’ho belle detto e altri suggerimenti sono arrivati.
Comunque: uso dei profili di Active Directory, push delle rotte tramite DHCP (come è stato suggerito da altri), utilizzo di un layer 3 su uno switch di core (se supportato), mettere il VPN concentrator su un’altra interfaccia del router internet, oppure se il VPN concentrator è anche firewall con più interfacce ethernet (tipo i SofaWare o i Netscreen) fare il contrario (il router internet su un segmento del VPN, che diventa quindi anche un firewall).
Non è questione di fare una guerra di religione contro gli ICMP Redirect perché mi stanno antipatici. E’ questione di tenere il tutto il più pulito e semplice possibile. Meno “eccezioni” ci sono, meno dovrai sbatterti in caso di problema.

Giuliano | #

Spider: secondo me i “profili di Active Directory” e “push delle rotte tramite DHCP” hanno molte meno probabilità di funzionare dell’ICMP redirect. E di certo non semplificano le cose! ;) Oltretutto, sempre secondo me, la configurazione della rete deve stare, appunto, sugli apparati di rete. Quindi è bene che “quando entri in una rete del genere” tu non debba guardare A/D o cosa c’è sui client per capire come sono state concepite le cose…


Giuliano

Fabio | #

Le ho usate in 4-5 situazioni e sono su (nella implementazione più datata) da circa due anni e non mi hanno mai dai dato noie. In effetti passando da dhcp sono comode e veloci da settare (e modificare) e come dicevo fino ad ora hanno funzionato egregiamente.

RedHansock | #

Ma perche litigate su sta cosa? Mettete giu un proxy ed avete risolto la questione.

E se non volete proprio toccare i client fate scaricare il file di config dal proxy quando uno si vuole connettere.

e cmq nessuno di voi ha risolto la questione dei dns uffa…

oscarivan | #

Ciao Andrea,
ho un problema come quello da te segnalato sopra, ho una rete con due firewall per due connessioni internet diverse.
192.168.0.1 –> internet teleunit [ASA5505]
192.168.0.2 –> internet telecom [MonoWall]

Il mio problema è che il 192.168.0.1 è un asa5505 con una vpn attiva che va sul 192.172.0.0/16, i client che hanno come gateway quello, non hanno problemi ad andarci.
Il problema nasce quando i client hanno il gateway 192.168.0.2, ho impostato una rotta statica su questo, che manda tutte le richieste verso 192.172.0.0/16 verso il gw 192.168.0.1 ma ho il problema che facevi notare tu, quando faccio un ping verso il client vpn funziona, ma come cerco di fare una connessione ssh dopo la password rimango bloccato.
Quale sarebbe la entry che dovrei mettere sul ASA?

Impostando la rotta statica su un client con gw 192.168.0.2 funziona tutto, ma vorrei fare qualcosa di pulito senza dover toccare nessun client.[La rete non supera i 20 client]

Grazie, ciao.

oscarivan | #

RISOLTO: sul MonoWall bisognava attivare questo flag:

Bypass firewall rules for traffic on the same interface

Grazie in ogni caso.
Ciao.