Newsgroup: it.comp.os.linux.sys
Titolo: routing semplice

Scusate, ma sto affogando in un bichier d'acqua da qualche ora..
Utilizzo una alix come router con linux voyage (current version). Non ho 
istallato nessun firewall, eppure non riesco a fare routing fra eth1 e eth0.
Router e pc appena riavviati: dal pc riesco a connettermi al router lato 
eth1, e da qui riesco a accedere a tutta la rete su eth0.
Purtroppo dal pc lato eth1 non riesco a accedere o pingare nessun ip 
lato eth0
Eppure mi sembrava cosa semplice: impostare a 1 alcuni flag sul router 
sotto /proc e configurare bene le interfacce.
Ecco le configurazioni:
client:~# ip route
10.1.30.0/24
 dev eth0  proto kernel  scope link  src 10.1.30.2
default via 10.1.30.1 dev eth0
client:~# cat /etc/network/interfaces|grep -v "^#"|grep -v "^$"
auto lo
iface lo inet loopback
allow-hotplug eth0
auto eth0
iface eth0 inet static
        address 10.1.30.2
        netmask 255.255.255.0
        gateway 10.1.30.1
Mentre sul router:
router:~# ip route
10.1.30.0/24
 dev eth1  proto kernel  scope link  src 10.1.30.1
192.168.5.0/24
 dev eth0  proto kernel  scope link  src 192.168.5.18
default via 192.168.5.1 dev eth0
router:~# cat /etc/network/interfaces|grep -v "^#"|grep -v "^$"
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
        address 192.168.5.18
        netmask 255.255.255.0
	gateway 192.168.5.1
auto eth1
iface eth1 inet static
        address 10.1.30.1
        netmask 255.255.255.0
router:~# for f in /proc/sys/net/ipv4/conf/*/rp_filter; do  cat $f ; done
1
1
1
1
1
1
Consigli?
Grazie
Alessandro

 lato eth0
Che dice cat /proc/sys/net/ipv4/ip_forward ?
Ciao

 Che dice cat /proc/sys/net/ipv4/ip_forward ?
Oppure iptables -vnL ?
Enrico

 
:~# cat /proc/sys/net/ipv4/ip_forward
1
Ho provato a settarli a mano (riavviando /etc/init.d/networking ) e alla 
fine l'ho impostato in /etc/sysctl.conf
:~# cat /etc/sysctl.conf |grep -v "^#"|grep -v "^$"
net.ipv4.conf.default.rp_filter=1
net.ipv4.tcp_syncookies=1
net.ipv4.conf.default.forwarding=1
net.ipv6.conf.default.forwarding=1
net.ipv4.ip_forward=1
net.ipv4.conf.default.rp_filter=1
net.ipv4.conf.all.rp_filter=1
net.ipv4.tcp_syncookies=0
kernel.panic=30
Ahah.. vedo ora che nella foga ho settato anche ipv6.. e infatto ho un 
messaggio di errore riguardo ipv6 sugli ultimi boot :-)  Non credo 
comunque che tale ipv6 faccia la differenza.
Un fatto strano è che non ho messaggi di risposta; sia il ping che lynx 
(con il quale provo a accedere su un server web sotto 192.168...) 
rimangono in attesa.
E' come se i pacchetti partissero ma si perdessero (arrivano ma non 
torna indietro la risposta? )
Ho tenuto per tutta la mattina shorewall e riuscivo a pingare e a usare 
lynx (avevo nattato alcune porte), ma avevo problemi su alcuni ip e sui 
dns che però non mi risultavano bloccati dal firewall, quindi ho voluto 
provare prima il routing semplice.
Alessandro


Eh, ci avevo gia' pensato..
:~# iptables -vnL
Chain INPUT (policy ACCEPT 10 packets, 2218 bytes)
  pkts bytes target     prot opt in     out     source 
destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
  pkts bytes target     prot opt in     out     source 
destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
  pkts bytes target     prot opt in     out     source 
destination
ma è tutto vuoto spinto!
Alessandro

 
Secondo me la soluzione sta in "iptables -A FORWARD -s 
0.0.0.0/24
 -d 
0.0.0.0/24
 -o eth0 -j ACCEPT"
Mi sembra la stessa casistica per cui su una rete (la mia lan casalinga 
) con router win2k server non si riusciva a fare routing verso il 
gateway e invece ci si riusciva (e ci si riesce) con linux, grazie a 
iptables.
P.s. Seppur non mi ritengo un utente con le conoscenze al pari dei 
frequentatori di questo newsgroup, spero comunque che il mio supporto 
possa esserti di aiuto :-)

 possa esserti di aiuto :-)
Grazie lo stesso per il tentativo :-)
Alessandro

 basata su debian, mi sembra molto strano e non ce n'e' traccia sul wiki.
Settaggi del kernel? Come fare accertarsene? Provo a compilare?
Alessandro

 basata su debian, mi sembra molto strano e non ce n'e' traccia sul wiki.
Potresti provare con zeroshell per verificare la cosa.. ;-)

 
Io la uso regolarmente e non ho mai avuto problemi.
Hai provato con delle regole che fanno vedere se il traffico arriva ed,
eventualmente dove si ferma? Tipo in raw prerouting e postrouting.
Tcpdump cosa dice?
Prova, alla sporca, a buttar su shorewall. Magari setta qualche cosa in
/proc che ti sei scordato di mettere ... (anche se non so cosa possa essere)
Michele

 Michele
Grazie
Alessandro

 Potresti provare con zeroshell per verificare la cosa.. ;-)
Beh, che dire: funziona :-) certo che ho mille opzioni che non mi servono.
Ho comunque dovuto attivare il nat fra eth0 e eth1; ho più catene di 
iptables, che quindi mi risulta un po' illeggibile.
Insomma, visto che anche con voyage+shorewall riuscivo a nattare 
qualcosa, per ora ho capito solo che non è possibile fare routing 
flaggando solo qualcosa sotto /proc , al contrario di ciò che viene 
detto in tutte le guide.
Eppure non mi torna; ora inizio a sniffare :-) e guardo cosa trovo
Alessandro

 Eppure non mi torna; ora inizio a sniffare :-) e guardo cosa trovo
Dopo un po' di sniff.. :-) ho capito che i pacchetti passavano da una 
interfaccia all'altra del router ma non tornavano indietro.
Ecco cosa mancava
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Io pensavo erroneamente che fare routing significasse implicitamente 
riscrivere l'ip sorgente; ciň evidentemente non avviene, e il 
destinatario non sa proprio a chi rispondere.
Alessandro

 router:~# for f in /proc/sys/net/ipv4/conf/*/rp_filter; do  cat $f ; done
Ma che c'entra la verifica dell'ěp sorgente? Si puo' sapere che
accidenti di guida hai seguito?
Guarda che tutto quel che si deve fare, senza necessita' di
avere default gateway ne' sul router ne' sui client, e' questo:
- sul client della rete A:
route add -net 192.168.5.0 netmask 255.255.255.0 gw 10.1.30.1
- sul client della rete B:
route add -net 10.1.30.0 netmask 255.255.255.0 gw 192.168.5.18
- sul router:
echo 1 > /proc/sys/net/ipv4/ip_forward
PUNTO. cosi', *DEVE* funzionare.
bye G.L.
-- 
"E' assolutamente evidente che l'arte del cinema si ispira
alla vita, mentre la vita si ispira alla TV" - Woody Allen

 destinatario non sa proprio a chi rispondere.
Ma infatti non avviene, e comunque non e' certamente per questo
che il destinatario "non sa proprio a chi rispondere".
Non avertene a male, leggi la mia risposta: hai trasformato un
problema di "routing semplice" in un bordello tremendo, piazzando
perfino un SOURCE NAT che non cincentra nulla. E suppongo anche che
il tutto ti abbia notevolmente allontanato dal capire concettualmente
cosa hai fatto per ottenere cio' che volevi.


 
Alessandro

 
Alessandro

 reti per farli vedere fra loro?
No, ti basterebbe impostare quella regola sui default gateway delle due
reti, in modo che il PC prova ad inviare il pacchetto che dovrebbe
andare all'altra rete attraverso il default gateway, che sa dove
buttarlo. Viceversa anche le macchine dell'altra rete possono rispondere
usando il default gateway. E se la macchina coincide (i due default
gateway delle due reti) non serve nessuna configurazione del genere,
solo il forwarding del pacchetti.
Enrico

 reti per farli vedere fra loro?
Solo se 10.1.30.1 e 192.168.5.18 non devono essere i default gateway,
come gia' detto da Enrico.


 192, metterebbe in completa comunicazione le due reti
No, diciamo che non sarebbe il "default gateway", che' quello e' la
route di default per tutte le destinazioni in assenza di entry che
specifichino delle route mirate (come le "route add" che ho portato
ad esempio).
