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).
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)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Pascal Hambourg
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)
(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 dport43 packets=1 bytes` srcÞst_test dst=IP_ADSL2 sport43 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.
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)
(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
dport43 packets=1 bytes` srcÞst_test dst=IP_ADSL2 sport43
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.
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)
(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 dport43 packets=1 bytes` srcÞst_test dst=IP_ADSL2 sport43 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
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 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
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
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.
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.