iptables, iproute2, et deux ADSL

Le
Riquer Vincent
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.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Pascal Hambourg
Le #18672761
Salut,

Riquer Vincent a écrit :
[...]
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT



Il doit manquer une règle dans FORWARD pour accepter les demandes de
connexion (NEW) sortantes.

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.



As-tu essayé de tracer ce paquet dans les chaînes iptables avec LOG pour
voir où exactement il est bloqué ?

La validation d'adresse source (rp_filter) est-elle bien désactivée sur
$IF_ADSL2 ? Sans cela, le code de routage jette les paquets reçus par
cette interface ayant une adresse source couverte par la route par défaut.

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



Qu'est-ce qui te fait penser ça ? Au contraire l'état SYN_RECV indique
que le SYN+ACK a bien été reconnu par le suivi de connexion.
Vincent Riquer
Le #18682191
Pascal Hambourg a écrit :
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT



Il doit manquer une règle dans FORWARD pour accepter les demandes de
connexion (NEW) sortantes.



Elle manquait juste de mon extrait..

La validation d'adresse source (rp_filter) est-elle bien désactivée sur
$IF_ADSL2 ? Sans cela, le code de routage jette les paquets reçus par
cette interface ayant une adresse source couverte par la route par défaut.



C'était ça... Merci, grâce à toi je n'entendrai plus 3 fois par jour
"Internet ça rame"... :)
--
Vincent Riquer

BOFH excuse #182:

endothermal recalibration
Pascal Hambourg
Le #18682481
Vincent Riquer a écrit :
Pascal Hambourg a écrit :

La validation d'adresse source (rp_filter) est-elle bien désactivée sur
$IF_ADSL2 ?



C'était ça...



Un grand classique. On s'est tous fait avoir une fois.
Publicité
Suivre les réponses
Poster une réponse
Anonyme