La sostituzione di un router in una rete già esistente dovrebbe essere, almeno in teoria, un'operazione abbastanza semplice: si assegna al nuovo apparato lo stesso indirizzo LAN del precedente, si replica la configurazione DHCP e si collegano gli switch.
Con il TIM HUB+ Huawei DN8245X6-8X, tuttavia, ci siamo imbattuti in un comportamento piuttosto poco intuitivo che può creare parecchia confusione in reti dove convivono client DHCP e dispositivi con indirizzo IP statico.
Il problema, una volta individuato, è facile da aggirare. Capire cosa stesse succedendo lo è stato molto meno.
Configurazione di partenza
La rete utilizzava:
- LAN: 192.168.1.0/24
- Gateway: 192.168.1.1
- DHCP: 192.168.1.20 - 192.168.1.90
Alcuni dispositivi, soprattutto server e altre macchine che devono mantenere un indirizzo noto, utilizzavano invece IP statici al di fuori del
pool DHCP, per esempio:
- 192.168.1.99
- 192.168.1.253
È una configurazione del tutto comune. Normalmente ci si aspetta che il
pool DHCP determini semplicemente quali indirizzi il
router può assegnare automaticamente, mentre il NAT verso Internet venga applicato all'intera rete 192.168.1.0/24.
Sul DN8245X6-8X provato, però, le cose non sono andate così.
TIM documenta la possibilità di configurare il
server DHCP e di creare associazioni statiche tra nome, MAC address e indirizzo IP, ma la documentazione pubblica non chiarisce il comportamento della voce Intervallo IP NAT presente nell'interfaccia del
router.
Il sintomo
Dopo aver sostituito il precedente
gateway con il nuovo Huawei, alcuni computer navigavano normalmente, mentre altri no.
La situazione era apparentemente contraddittoria:
- 192.168.1.29 → Internet OK
- 192.168.1.99 → Internet KO
- 192.168.1.253 → Internet KO
Gli
host problematici riuscivano però a raggiungere perfettamente il router:
- ping 192.168.1.1 OK
- ping 8.8.8.8 KO
Quindi:
- Ethernet funzionava;
- ARP funzionava;
- la subnet era corretta;
- il gateway era raggiungibile;
- il problema non era DNS, dato che falliva anche il ping diretto ad un indirizzo IP pubblico.
Il traffico si fermava sostanzialmente al
router.
L'indizio decisivo
C'era una correlazione molto sospetta:- Pool DHCP: 192.168.1.20 - 192.168.1.90
- 192.168.1.29 → dentro il pool → Internet OK
- 192.168.1.99 → fuori dal pool → Internet KO
- 192.168.1.253 → fuori dal pool → Internet KO
L'interfaccia del
router contiene inoltre una sezione denominata
Intervallo IP NAT, i cui limiti risultano vincolati all'intervallo DHCP impostato.
In generale una
policy NAT può certamente essere limitata in funzione dell'indirizzo IP sorgente: Huawei documenta esplicitamente NAT
policy che selezionano o escludono determinati indirizzi e intervalli. Il punto insolito non è quindi la possibilità tecnica di farlo, ma il modo in cui tale comportamento viene esposto e collegato alla configurazione DHCP in questo
firmware.
Per eliminare ogni possibile interferenza della rete aziendale, abbiamo isolato completamente il nuovo
router.
Collegando direttamente un notebook via Ethernet e gli abbiamo assegnato:
- IP: 192.168.1.99
- Mask: 255.255.255.0
- Gateway: 192.168.1.1
- DNS: 8.8.8.8
Risultato:
- ping 192.168.1.1 OK
- ping 8.8.8.8 KO
- navigazione KO
Abbiamo quindi modificato soltanto l'indirizzo IP del
notebook a 192.168.1.89, lasciando invariati
mask,
gateway, DNS, cavo ed ogni altra impostazione.
Risultato:
- ping 192.168.1.1 OK
- ping 8.8.8.8 OK
- navigazione OK
192.168.1.89 apparteneva al
range DHCP .20-.90; .99 no. A quel punto il comportamento era sufficientemente isolato da escludere
switch,
server DHCP esterni, cablaggio, DNS e configurazioni della precedente infrastruttura.
La soluzione
Abbiamo esteso il
range configurato sul router a 192.168.1.2 - 192.168.1.254 ed utilizzato la funzione di IP statico/prenotazione MAC-IP del per gli apparati che devono conservare un indirizzo preciso.
Per esempio:
- SERVER → 192.168.1.250
- altro PC → 192.168.1.99
TIM documenta ufficialmente questa possibilità nella sezione:
Avanzate → LAN → IP statico dove è possibile associare nome, MAC address e IP.
Dopo l'estensione dell'intervallo e la creazione delle relative prenotazioni, anche un host con IP configurato manualmente ha iniziato a navigare normalmente.
La configurazione finale deve quindi essere inequivocabile:
Anche l'opzione
Inoltro DHCP del Huawei va normalmente lasciata disabilitata quando il
router stesso serve direttamente i client della medesima
subnet.
Perché questo comportamento è sorprendente?
DHCP e NAT sono normalmente due funzioni concettualmente indipendenti.
Il DHCP risponde alla domanda "Quali indirizzi IP posso assegnare automaticamente ai client?". Il NAT risponde invece a "Quale traffico proveniente dalla LAN devo tradurre verso l'indirizzo pubblico?"
In una comune LAN 192.168.1.0/24 è perfettamente normale utilizzare:
- 192.168.1.20 - .90 DHCP
- 192.168.1.100 - .254 indirizzi statici
aspettandosi che entrambi i gruppi possano raggiungere Internet.
Le piattaforme Huawei possono tecnicamente applicare NAT in funzione dell'indirizzo sorgente, quindi non c'è nulla di scorretto nel meccanismo in sé.
Ciò che consideriamo poco intuitivo nel firmware TIM provato è piuttosto:
- la relazione tra range DHCP e host ammessi al NAT;
- il vincolo dell'"Intervallo IP NAT" al range DHCP;
- la scarsa spiegazione di questo comportamento nella documentazione pubblica;
- il fatto che un host fuori range continui a raggiungere perfettamente il router, facendo inizialmente pensare a problemi completamente diversi.
Il TIM HUB+ Huawei DN8245X6-8X si è rivelato, una volta configurato correttamente, perfettamente utilizzabile anche in una LAN preesistente con
server e altri dispositivi ad indirizzo fisso.
Con Thunderbird 154 può verificarsi un problema piuttosto curioso nella stampa dei file PDF allegati ai messaggi: il documento viene visualizzato correttamente nel lettore PDF interno di Thunderbird e anche l'anteprima di stampa appare normale. Quando però si invia effettivamente il documento alla stampante, il risultato può essere una pagina completamente bianca.