IlPuntoTecnico
Hardware e Software => Networking => Topic aperto da: jack.mauro - 30 Aprile 2018, 01:06
-
Ciao a tutti,
Io ho una configurazione di rete semplificabile come rappresentato nella seguente immagine:
(https://jack.logicalsystems.it/homepage/immagini/20180430-SchemaReteSemplificato.png)
Il router A è un DGA4132 Tim con root e gui sbloccata.
Sul router A ho aggiunto le seguenti route statiche, utilizzando la GUI:
route add -net 192.168.12.0 netmask 255.255.255.0 gw 192.168.11.53
Il "Router" B è una VM con un VPN server, ma ai fini del problema è assimilabile ad un rotuer fisico.
Se dal client windows C provo a pingare un host sulla rete D, ottengo risposta come atteso,
Anche eseguendo un traceroute ottengo la risposta attesa
Tracing route to 192.168.12.20 over a maximum of 30 hops
1 14 ms 5 ms 2 ms 192.168.11.254
2 11 ms 4 ms 2 ms 192.168.11.53
3 53 ms 42 ms 43 ms 192.168.12.99
4 52 ms 43 ms 43 ms 192.168.12.20
Trace complete.
Tuttavia se cerco di accedere a qualsiasi risorsa, la connessione non va a buon fine: la connessione TCP sembra aprirsi ma poi non avviene lo scambio dati e il tutto cade per timeout.
Se inserisco sul client C una route statica come la seguente:
ROUTE ADD 192.168.12.0 MASK 255.255.255.0 192.168.11.53
allora tutto funziona, ma vorrei evitare di dover aggiungere rotte su ogni device...
Se sostituisco il router A con un Linksys WRT610N (DD-WRT) con pari configurazione, tutto funziona.
Ho provato a disabilitare il firewall del router A DGA4132 tramite la GUI ma non ho notato cambiamenti. (anche perché l'impostazione controlla giusto qualche regoletta minore).
Secondo voi quale può essere il problema? Io ho pensato a:
- MTU (il ping piccolo passa, gli altri pacchetti grandi no)
- Firewall (Potrebbe in qualche modo essere bloccato il routing asimmetrico)
- Firewall bis (Potrebbe essere bloccato tutto intra-zone LAN to LAN)
Qualcuno ha avuto problemi simili o qualche idea da suggerirmi?
-
1) - MTU (il ping piccolo passa, gli altri pacchetti grandi no) NO!! altrimenti non ti funzionerebbe con le rotte statiche
2) - Firewall (Potrebbe in qualche modo essere bloccato il routing asimmetrico) Non capisco perche parli di routing asimmetrico : tutto entra ed esce dalla vpn dunque è simmetrico
Ho una mia piccola idea ma non so se è giusta: ma se da rete d accedi a c funziona ?
se funziona è perche da qualche parte stai nattando la 10 e la 172 !!!
Perche il pacchetto che arriva da d ha come campo sorgente 192.168.12.x oppure 10.x.x.x oppure 172.x.x.x. adesso il problema è che queste altre due rotte che sono le risorse che ti interessano al 4132 sono sconosciute . l'unica rotta conosciuta è la 192.168.12.x
percui il ping verso 192.168.12.20 va... ma le risorse se sono 10.x.x.x o se sono 172.x.x.x sono sconosciute
prova ad aggiungere nel 4132 anche le rotte 10 e 172 sempre con gateway 192.168.11.53
-
Ciao, riguardo le rotte 172.x.x.x e 10.x.x.x sono presenti, le avevo tralasciate per semplificare l'esempio.
Il tuo post mi ha convinto ad installare wireshark sia su C che su un web server in D, e vedo succedere questo:
1) C invia a D un pacchetto TCP SYN per aprire la connessione. (il pacchetto transita attraverso A che lo redirige a B).
2) D invia a C un pacchetto TCP SYN,ACK. (il pacchetto arriva da D, attraversa B ed arriva a C senza attraversare A).
3) C invia a D un pacchetto TCP ACK, ma D non lo riceve. Poiché C invia il paccheto ad A e questo non sa che la connessione è stata stabilita dato che il pacchetto 2 non è transitato attraverso di lui, quindi lo droppa.
Ho provato ad esaminare le regole di iptables del router e le sue configurazioni.
in /etc/config/firewall trovo:
config defaults
option syn_flood '1'
option drop_invalid '1'
che inseriscono, tra il resto, anche le seguenti regole:
-A dosprotect ! -s 0.0.0.0/32 -m rpfilter --invert -j rpfilter_DROP
-A FORWARD -m conntrack --ctstate INVALID -m comment --comment "!fw3" -j DROP
Entrambe le opzioni mi droppano i pacchetti, la prima perché controlla il reverse path del pacchetto (routing asimmetrico) e la seconda perché controlla lo stato della connessione TCP (non valida perché il router non ha mai visto il SYN ACK).
Mettendo le opzioni a 0 tutto funziona, ma perdo le protezioni sulla WAN.
La mia soluzione definitiva è quindi stata di aggiungere queste righe al file /etc/firewall.user:
iptables -t raw -I dosprotect -s 192.168.11.0/24 -d 192.168.0.0/16 -i br-lan -m comment --comment "!fw3: static routes" -j ACCEPT
iptables -t filter -I FORWARD -s 192.168.11.0/24 -d 192.168.0.0/16 -i br-lan -m comment --comment "!fw3: static routes" -j ACCEPT
iptables -t raw -I dosprotect -s 192.168.11.0/24 -d 172.16.0.0/12 -i br-lan -m comment --comment "!fw3: static routes" -j ACCEPT
iptables -t filter -I FORWARD -s 192.168.11.0/24 -d 172.16.0.0/12 -i br-lan -m comment --comment "!fw3: static routes" -j ACCEPT
iptables -t raw -I dosprotect -s 192.168.11.0/24 -d 10.0.0.0/8 -i br-lan -m comment --comment "!fw3: static routes" -j ACCEPT
iptables -t filter -I FORWARD -s 192.168.11.0/24 -d 10.0.0.0/8 -i br-lan -m comment --comment "!fw3: static routes" -j ACCEPT
Così facendo i pacchetti vengono accettati prima dei test di reverse path e stateful inspection e tutto funziona correttamente. Spero queste info possano essere utili anche ad altri possessori del DGA4130/DGA4132
Ciao e grazie!
-
@jack.mauro
Bene, anche se partita da una considerazione iniziale sbagliata, ti ha dato l'input per analizzare piu a fondo la questione.
Lieto tu abbia risolto