Scenario: un firewall con due interfacce WAN collegate a due router ADSL e configurate in failover. Cade la linea principale e la rete perde connettività: cosa è successo?

Ad una prima indagine mi accorgo che tutti gli host accedono regolarmente ad internet via linea di backup ma non funziona la risoluzione dei nomi, quindi è praticamente tutto fermo. La rete è servita da un Windows 2003 server che, tra gli altri, ha i ruoli di DNS server, mail server e webmail server.

La causa della risoluzione  non funzionante è il server che, scopro, non ha connessione ad internet. Come è possibile che tutta la rete acceda ad internet tranne il server? Verificato che il firewall non abbia policy restrittive e spulciati i log relativi, mi concentro sulla sua tabella di NAT.

Dato che il server è pubblicato per i servizi SMPT e HTTP, esiste una regola esplicita che natta l’IP privato sull’IP pubblico della WAN primaria, e fin qui tutto bene. Dopo una telefonata chiarificatrice con un collega, mi rendo conto che manca completamente la regola che NATti il server anche sull IP pubblico della linea di backup. Modifico la regola principale esplicitando l’interfaccia di outbound, che prima era ANY, e creo un’altra regola per il NAT sull’IP di backup, sulla relativa interfaccia. Come per magilla, la connettività riappare e il server DNS ricomincia a fare il suo mestiere.

Le VPN verso le sedi remote vengono riattivate facendo modificare alle filiali l’IP del peer da cui la connessione viene accettata, e specificando nel “local ID peer” l’IP pubblico della connessione di backup perché il router relativo, in comodato d’uso, fa a sua volta un NAT. Al momento del ripristino della linea principale, si effettuerà un rollback delle modifiche.

Per scongiurare problemi in futuro, rimangono da fare i seguenti passi:

  • configurare un record backup MX nel DNS del dominio di posta, in modo che i messaggi possano essere anche ricevuti, oltre che inviati, quando è attivo il failover;
  • aggiungere una regola di NAT sulle interfacce opportune per pubblicare l’IP privato del server anche sull’indirizzo pubblico della linea di backup.

Perché tutto ciò non è stato testato prima della messa in produzione? Per i soliti motivi: uno dei due provider tardava a fornire la connettività di backup e l’altro ha sbagliato il contratto modificando in corso d’opera la classe degli IP pubblici assegnati; Il cliente aveva bisogno di lavorare da subito e non c’è mai stato modo di fare un collaudo vero e proprio.

Tags: , , , ,

Related posts