iptables, iproute2, et deux ADSL

Bonjour,

Petit problème de routage + masquerading

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)

La passerelle est une debian avec noyau 2.6.13.1 compilé maison. Je n'en
ai pas réalisé l'installation, mais il semble que le noyau ait été
patché. Le dernier kernel de Etch entraine une régression au niveau des
vlans, probablement du fait de patchs manquants.




# 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Þst_test sportI267
dport„43 packets=1 bytes` srcÞst_test dst=IP_ADSL2 sport„43
dportI267 packets=3 bytes0 mark=0 use=1

Côté client, on voit que le SYN+ACK n'est pas retransmis par le routeur NAT.

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

(Je peux fournir en privé des informations plus complètes sur les
configurations de routage et de firewall)
--
Vincent Riquer

BOFH excuse #405:

Sysadmins unavailable because they are in a meeting talking about why
they are unavailable so much.