Newsgroup: it.comp.os.linux.sys
Titolo: cruccio iptables

Ho il seguente problema, tutti i pacchetti che arrivano a tun0 (o
un'interfaccia tun qualsiasi) devono essere rediretti a eth0
(l'interfaccia di rete esterna) e nattati.
Ora qui sotto ho le regole per il natting:
--8<---------------cut here---------------start------------->8---
$IPT -t nat -A POSTROUTING -o $ETH -j MASQUERADE
# accept stuff from the network which is connected
$IPT -A FORWARD -i $ETH -o $TUN -m state --state RELATED,ESTABLISHED -j ACCEPT
# accept everything from tap to external network
$IPT -A FORWARD -i $TUN -o $ETH -j ACCEPT
--8<---------------cut here---------------end--------------->8---
Ma pare che nulla venga in realtà rediretto, possibile che forse manchi
qualcosa??
Grazie..


Definisci "rediretto".
-- 
Paranoia is a disease unto itself. And may I add: the person standing
next to you may not be who they appear to be, so take precaution.
-----------------------------------------------------------------------------
http://bofhskull.wordpress.com/

 Definisci "rediretto".
Voglio che tun0 venga nattata sostanzialmente, che tutti i pacchetti
diretti a tun0 vengano sparati su eth0...


Un po' criptica comunque, poichè non sappiamo se questo implichi solo
traffico diretto alla tua macchina o implichi anche traffico che
*transita* attraverso di essa attraverso routing.
Nè, cosa ben più rilevante, cosa ti aspetti di ottenere con ciò...
Comqunque:
iptables -A PREROUTING -t nat -i tun0 -j DNAT --to-destination <IP_di_eth0>
Questo fa sì che qualsiasi pacchetto proveniente dal tunnel
(indipendentemente dall'IP di destinazione) subisca una riscrittura
della destinazione e venga pertanto "rediretto" alla macchina stessa,
sull'IP indicato.
Ovviamente assumendo che questo abbia un senso :-)


 qualcosa??
ip_forwarding abilitato ?
-- 
yhrfrryrtrt

 -- yhrfrryrtrt
Uh?


 writes:

Si abilitato, lo script totale era così
--8<---------------cut here---------------start------------->8---
#!/bin/bash
# setup the gateway to act as a nat machine
# see 
http://www.revsys.com/writings/quicktips/nat.html
 to understand it
set -x
echo 1 > /proc/sys/net/ipv4/ip_forward
IPT="iptables"
if [ $# -lt 2 ]
then
    echo "./gateway.sh <tun> <external>"
    exit 1
fi
TUN=$1
ETH=$2
ifconfig $TUN up
$IPT -F
$IPT -Z
$IPT -t nat -A POSTROUTING -o $ETH -j MASQUERADE
# accept stuff from the network which is connected
$IPT -A FORWARD -i $ETH -o $TUN -m state --state RELATED,ESTABLISHED -j ACCEPT
# accept everything from tap to external network
$IPT -A FORWARD -i $TUN -o $ETH -j ACCEPT
--8<---------------cut here---------------end--------------->8---
Comunque grazie al DNAT di skull pare funzionare, ci siamo quasi per lo
meno.
In sostanza scriviamo dati su tun0 e vogliamo che vengano rediretti su eth...

Tra l'altro domanda stupida, ma è possibile che usare una virtual
machine e sniffare sulla sua interfaccia sia diverso che farlo su una
macchina reale?
Non credevo fosse questo il caso, ma ho un comportamento diverso...

 Uh?
Era per metterti alla prova per vedere se capivi che avevo sminchiattato 
male con le configurazioni dei profili di pan.
Prova superata, ovviamente ! :-D
Max

Stiamo anche notando che stranamente su una macchina questo "trucco"
funziona mentre su altre due no, e tutte e tre sono linux teoricamente
con stesse configurazioni di rete.
E poi un altra domanda, la stessa cosa non sarebbe fattibile anche con
una route entry?
qualcosa tipo (vagamente)
ip route add 10.0.0.0 via eth0
non potrebbe funzionare?

 non potrebbe funzionare?
La risposta breve è "no"...


 La risposta breve è "no"...
Ok perfetto, ma sarebbe molto interessante anche vedere la risposta non breve...

 tun0.
Vediamo se capisco:
  PC1 ()========) PC2 --------- Router --------- Internet
Dove PC1 è privo di connettività IP salvo il tunnel (quello
scarabocchio) con PC2.
PC2 ha invece una NIC che va verso un gateway e da lì in internet.
E' così semplice?
E, se sì: si vuole che PC1 sia raggiungibile? E su quali porte? Oppure
deve solamente poter raggiungere la Internet senza esserne raggiungibile?


 deve solamente poter raggiungere la Internet senza esserne raggiungibile?
Esattamente proprio così, che pc1 sia raggiungibile non interessa, basta
che si riesca a farlo uscire e siamo a posto.
Tra l'altro se ci esce un ping all'esterno siamo già contenti, la
bandwidth è penosa e il massimo di bytes per messaggio sono sui 60 :Dc


Ok.
Facciamo due ipotesi.
La prima è che tra PC1 e PC2, ai due lati del tunnel, ci siano indirizzi
della 
10.1.1.0/30
.
10.1.1.1 è PC1
10.1.1.2 è PC2
Ipotizziamo che PC2 abbia sulla NIC eth0 l'indirizzo 192.168.1.2 e che
abbia default gateway già impostato verso il router
Su PC1:
ip route add default via 10.1.1.2
Su PC2:
sysctl -w net.ipv4.ip_forward=1
iptables -A POSTROUTING -t nat -s 10.1.1.1 -o eth0 -j SNAT --to-source
192.168.1.2
Tutto qui.


 192.168.1.2
Se PC2 è "dedicato" allo scopo (AKA non è un firewall vero e proprio) si può
semplificare ulteriormente.
# sysctl -w net.ipv4.ip_forward=1
# iptables -t nat -I POSTROUTING -j MASQUERADE
E' quel che faccio io quando sono da qualche cliente e devo far uscire un
server attraverso la mia VPN per bypassare i vari filtri del firewall.
-- 
Flavio Visentin
Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

 server attraverso la mia VPN per bypassare i vari filtri del firewall.
Fantastico, PC2 è dedicato ma dovrebbe comunque essere sempre in grado
di navigare su internet.
E' magari possibile che prima funzionasse solo un sistema perché usavo
cat /proc/.. invece di sysctl (domani lo saprò)?
E un altra cosa, mi dà un po' fastidio dover tirare in ballo iptables
(ma naturalmente per testing e prototipo va benissimo) lato gateway.
Sarebbe stato bello fare tutto da C, ma solo per settare una route ci
eravamo mangiati il fegato, quindi non so ne vale la pena...
Si può fare con altri comandi più comunemente presenti?
Ora tra l'altro abbiamo un Makefile piuttosto complesso
http://github.com/AndreaCrotti/Network-mote/blob/master/driver/Makefile
non mi dispiacerebbe controllare le varie dipendenze da lì, o meglio
usare autoconf se finalmente risco a capire come caspita si usa...

 usare autoconf se finalmente risco a capire come caspita si usa...
Su questo alzo codardamente bandiera bianca...



Sì ok decisamente non ne vale la pena, anche perché avrebbe senso se si
fa qualcosa di portabile, altrimenti è solo una rottura di balle...
Comunque usando questo script
--8<---------------cut here---------------start------------->8---
set -x
sysctl -w net.ipv4.ip_forward=1
IPT="iptables"
if [ $# -lt 2 ]
then
    echo "./gateway.sh <tun> <external>"
    exit 1
fi
TUN=$1
GATEWAY_IP=10.0.0.254
CLIENT_IP=10.0.0.1
ETH=$2
ETH_IP=$(ifconfig $ETH | grep "inet addr:" | awk -F: '{ print $2 }' | awk '{ print $1 }')
ip link set $TUN up
ip addr add $GATEWAY_IP dev $TUN
$IPT -t nat -F
$IPT -Z
# from what they say on the internet THIS rule should be enough
# $IPT -A POSTROUTING -t nat -s $TUN_IP -o $ETH -j SNAT --to-source $ETH_IP
# or also this one
# insert a nat rule in the postrougint which jumps to masquerading
$IPT -t nat -I POSTROUTING -j MASQUERADE
# -o $TUN 
$IPT -t mangle -A FORWARD --destination $CLIENT_IP -j LOG --log-prefix
# "packets on eth: " --log-level 7
--8<---------------cut here---------------end--------------->8---
Ora otteniamo questo:
--8<---------------cut here---------------start------------->8---
Jul 27 12:00:31 test kernel: packets on eth: IN=eth0 OUT=eth0
SRC=134.130.4.1 DST=10.0.0.1 LEN=129 TOS=0x00 PREC=0x00 TTL=127 ID=20105
PROTO=UDP SPT=53 DPT=37090 LEN=109
--8<---------------cut here---------------end--------------->8---
In pratica non riesce a rimandarli indietro perché non cambia
l'interfaccia, any idea??

 # iptables -t nat -I POSTROUTING -j MASQUERADE
Occhio che però così MASQUERi anche quel che esce sulla tun0 (anche se
in questo caso non dovrebbe rappresentare un problema...)


 l'interfaccia, any idea??
riportaci l'output di un "ip route show" su PC2...


 riportaci l'output di un "ip route show" su PC2...
anche di un "iptables-save", sempre su PC2


 anche di un "iptables-save", sempre su PC2
Ora funziona abbiamo aggiunto questo
10.0.0.0/24
 via 10.0.0.254 dev tun0 
c'è ancora qualche problemino con chunks mancanti..

 in questo caso non dovrebbe rappresentare un problema...)
Sì, sì, è proprio voluto. Così ci si risparmiano anche problemi con il
routing :-)
Ovviamente è una configurazione che va bene "one-shot", non è certo corretta
per qualcosa di definitivo.



Non so come funzioni il protocollo che avete "sotto" al tunnel, ma
occhio ai problemi di frammentazione...


 occhio ai problemi di frammentazione...
beh in sostanza ogni pacchetto IP va spezzato e riconstruito, perché
abbiamo la bellezza di 60 BYTES come payload da poter inviare.
Ora funziona, ma c'è una latenza di 1000ms per un semplice ping, il
problema è che sono troppo lenti, e
1. se aggiungiamo un handshaking rallentiamo ancora di più
2. i motes si devono sincronizzare quindi bisogna rallentarli parecchio
   purtroppo e non abbiamo molto controllo
Ho visto che anche nel kernel ci sono molti timeout, tipo:
--8<---------------cut here---------------start------------->8---
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 180
net.netfilter.nf_conntrack_icmp_timeout = 30
--8<---------------cut here---------------end--------------->8---
Sono quello che penso io?
Potrebbe essere utile per provare almeno ad aprire una pagina web molto
semplice :D

 semplice :D
Se i problemi che avete sono dovuti a latenze estremamente elevate che
pregiudicano il funzionamento di TCP, lì potreste anche cavare qualcosa,
MA rammenta che la sessione TCP la mantenete in piedi in due: tu (PC1) e
il webserver.
E senza replicare analogo tuning lato webserver, le modifiche dei
parametri di TCP dal tuo lato non hanno molto effetto.
Una via potrebbe essere l'uso di un proxy HTTP in esecuzione su una
macchina (eventualmente lo stesso PC2) su cui abbiate la possibilità di
fare analogo tuning.
In tal modo la sessione TCP viene operata tra due macchine che puoi
"tunare", ma la sessione HTTP con il webserver "finale" su Internet
viene mantenuta da una macchina che non abbia latenze esagerate, tali da
compromettere la comunicazione con il webserver stesso...


 compromettere la comunicazione con il webserver stesso...
Siamo perfino risciti ad aprire una pagina di wikipedia e mandare una
mail ;)
Non è così male come sembrava (siamo sui 1k/s), forse i tweak non sono
nemmeno necessari i tweak, se riesco a far andare la compressione si
guadagna qualcos altro magari.
In effetti non avevo pensato che non basta modificare i miei parametri,
grazie per avermelo fatto notare!