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.

Lo scrivo qui così non me lo dimentico.

Mi è capitato un paio di volte che durante l’installazione di un Symantec Mail Security, dopo la prima fase di inserimento del file di licenza e di aggiornamento del software, l’appliance non funzionasse correttamente, non riuscendo ad uscire su internet. Il flusso della posta funziona, ma gli aggiornamenti delle signature non vengono scaricati. Dopo aver escluso problemi di regole sul firewall, si scopre che manca il default gateway.
O meglio: sull’interfaccia di amministrazione è correttamente definito, ma collegandosi via ssh alla console e impartendo un route -n si nota che manca completamente la rotta per uscire su internet. Si può aggiungere a mano con un route add eccetera eccetera, ma non viene salvata al prossimo riavvio. L’utente con i diritti di accesso alla console non è root, quindi non si può neppure entrare in /etc.

La prima volta il problema è stato risolto dal mio collega Giuliano, il quale, evidentemente, è stato allevato da una coppia di pinguini, dato che parla bash madrelingua. Con delle magie applicate a GRUB e manovre sbirciate da sopra la spalla di un sistemista Symantec, è riuscito a modificare il file XML che contiene la configurazione del sistema, ma il procedimento è stato lungo e complicato(*).

Questa volta me la sono dovuta cavare da solo, con il metodo “Annusa E Prova”, che a volte dà i suoi frutti. (Sulla KB Symantec manco l’ombra di una soluzione).

Per farla breve, anche se in fase di configurazione viene data la possibilità di non definire un IP virtuale per la scheda di rete principale, se non viene fatto viene comunque creata un’interfaccia virtuale con IP vuoto. Basta cancellarla e ricrearne un’altra con l’indirizzo compilato e finalmente la route statica si crea automagicamente. L’unico utilizzo per questo indirizzo supplementare è la scansione del traffico IM, che comunque lascio disabilitata.

(*) so che Giuliano ogni tanto mi legge, se ha voglia di raccontare nei commenti come si ottiene l’accesso root a questi aggeggi, magari serve a qualcuno.