iptables, iproute2, et deux ADSL

Top Page

Reply to this message
Author: script.fan
Date:  
To: guilde
Subject: iptables, iproute2, et deux ADSL
Bonjour la liste,

Au boulot, ligne FT de 4km oblige, nous avons 2 ADSL (2 FAI différents).
La répartition entre les 2 ne devra pas se faire en load balancing mais suivant le service (tout simplement, le port de destination).

Schématiquement, j'ai :

                 __________________________,-(ADSL2)-(http, https, ftp)
(Réseau NATté)-->| Routeur/Firewall/Proxy |
                 ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯`-(ADSL1)-(le reste)



# Côté iproute2, je duplique la table de routage "main" (hors route par défaut) dans une table "T1" :

ip route show table main | grep -Ev ^default \
| while read ROUTE ; do

    ip route add table T1 $ROUTE
done
ip route add default via $Passerelle_ADSL2 table T1


# Avec une règle iproute2, j'envoie les paquets marqués 0x1 par iptable vers la table de routage T1 :
ip rule add fwmark 1 table T1
ip route flush cache

# niveau iptables, je marque les paquets :
iptables -t mangle -A PREROUTING -s $source_test -d $dest_test -j MARK --set-mark 1

# je SNAT en sortie :
iptables -t nat -A POSTROUTING -s $NET_LAN -o $IF_ADSL1 -j SNAT --to-source $IP_ADSL1
iptables -t nat -A POSTROUTING -s $NET_LAN -o $IF_ADSL2 -j SNAT --to-source $IP_ADSL2

iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT


MAIS, ça ne fonctionne pas. Lorsque source_test essaye de discuter TCP avec dest_test, le trafic sort bien par ADSL2, mais le connection tracking ne fonctionne pas. Un tcpdump montre le dialogue de sourd suivant (les IP sources et destinations sont bien les bonnes dans les 2 sens) :

(source_dest est une machine du LAN en 192.168.x.x, dest_test est une dédibox, et IP_ADSL2 est l'IP de la connexion ADSL par laquelle le trafic doit passer)

source_test ---(SYN)---> dest_test
            <-(SYN+ACK)- 
            ---(SYN)---> 
            <-(SYN+ACK)- 


(et ainsi de suite jusqu'à expiration côté client)

Dans la table de conntrack, j'ai :
tcp      6 54 SYN_RECV src=source_test dst=dest_test sport=49267 dport=8443 packets=1 bytes=60 src=dest_test dst=IP_ADSL2 sport=8443 dport=49267 packets=3 bytes=180 mark=0 use=1


Je ne comprends pas du tout pourquoi le conntrack ne "prend" pas la deuxième étape du handshake...

(Je peux fournir hors liste des informations plus complètes sur les configurations de routage et de firewall)

PS: sympa le webmail 2.0 beta de Free
--
Vincent Riquer

BOFH excuse #100:

IRQ dropout