Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Matériel Réseaux et Internet IP suspicion de bug dans netfilter ?

suspicion de bug dans netfilter ?

9 réponses
Avatar
Eric Belhomme
bonjour,

Suite au fil que j'ai lancé la semaine dernière sur fcri, j'ai posté un
message sur la mailing-list de netfilter, sans succès, mis à part un
contributeur qui me suggère de venir en (re) discuter ici même, et sur
fcolc...

Donc je reposte, mais en francais :

Je ne suis ni un guru netfilter, ni un guru de la pile ip de linux, mais
je suis contronté à un curieux problème, et je soupconne un bogue...

Ma config est une Debian Sarge avec un kernel Vanilla 2.6.18.2 et
iptables iptables 1.2.11

Ma passerelle est dotée de 3 interfaces :
* eth0 192.168.1.254/24 connecté au lan
* eth1 connect& à mon FAI pro qui me fournit une /28 ipv4
* eth2 10.75.1.254 connecté à une DMZ

Il y a aussi un alias sur eth0:1 192.168.100.253/24 pour une pseudo DMZ.
Le but etant qu'un hote de mon LAN soit obligé de passer par la
passerelle pour atteindre une machine de mon pseudo DMZ, bien qu'elles
soient sur le même segment ethernet

Voici le début de ma table FORWARD (police par défaut : DROP)

Chain FORWARD (policy DROP)
target prot opt source destination
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state ESTABLISHED
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state ESTABLISHED
log_drop tcp -- 0.0.0.0/0 0.0.0.0/0 state INVALID
log_drop udp -- 0.0.0.0/0 0.0.0.0/0 state INVALID
ACCEPT tcp -- 192.168.1.0/24 192.168.100.0/24 state NEW

Donc un hôte 192.168.1.125 _devrait_ être capable de se connecter à un
hôte 192.168.100.254... Mais regardez une session de capture sur la
passerelle :

# tcpdump -n -i eth0 net 192.168.100.254
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
13:46:08.297208 IP 192.168.1.125.3580 > 192.168.100.254.22: S
3913030203:3913030203(0) win 65535 <mss 1460,nop,nop,sackOK>
13:46:08.297289 IP 192.168.1.125.3580 > 192.168.100.254.22: S
3913030203:3913030203(0) win 65535 <mss 1460,nop,nop,sackOK>
13:46:08.297585 IP 192.168.1.125.3580 > 192.168.100.254.22: . ack
2474300259 win 65535
13:46:11.497946 IP 192.168.1.125.3580 > 192.168.100.254.22: . ack 1 win
65535
13:46:17.496303 IP 192.168.1.125.3580 > 192.168.100.254.22: . ack 1 win
65535

On voit que l'hôte source envoie le 1er paquet pour une poignée de main
TCP, ce paquet est réémis via la même interface.
mais ensuite, au lieu de recevoir un SYN-ACK de la part de l'hôte
destination, on voit que l'hôte source emet un ACK, alors qu'il n'a r^çu
aucun SYN-ACK !

note: la machine source est un poste windows 2000, et j'ai capturé aussi
sur cette machine lors de la tentative de connexion, et elle n'a reçu
_aucun_ SYN-ACK

J'ai pu avoir l'explication en jetant un oeuil dans mon /var/log/message
sur la passerelle :
# tail -n 1000 /var/log/messages|grep 192.168.100.254
Nov 14 13:46:08 localhost kernel: IPT_DROP: IN=eth0 OUT=eth0 SRC=
192.168.1.125 DST=192.168.100.254 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=
51586 DF PROTO=TCP SPT=3580 DPT=22 WINDOW=65535 RES=0x00 ACK URGP=0
Nov 14 13:46:11 localhost kernel: IPT_DROP: IN=eth0 OUT=eth0 SRC=
192.168.1.125 DST=192.168.100.254 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=
51589 DF PROTO=TCP SPT=3580 DPT=22 WINDOW=65535 RES=0x00 ACK URGP=0

Les paquets retour (hote destination vers hote source) sont droppés par
ma 3e règle iptables car conntrack marque la connexion comme étant
invalide !

J'ai fait un test en déplacant la règle 5 de la table FORWARD en position
1, et j'ai rajouté une nouvelle règle :

# iptables -I FORWARD 2 -i eth0 -o eth0 -s 192.168.100.0/24 -d
192.168.1.0/24 -j ACCEPT

Dans ce cas je peux voir le paquet SYN-ACK transiter par la passerelle,
mais les paquets suivant sont bloqués. J'ai donc remplacé la 1ere règle
par celle-ci :
# iptables -R FORWARD 1 -i eth0 -o eth0 -s 192.168.1.0/24 -d
192.168.100.0/24 -j ACCEPT

Et là la connexion peut enfin s'établir... bien que les paquets soient
traités comme invalides par netfilter !

Je ne sais pas que penser de tout ca, surtout devant le peu d'entousiasme
qu'a provoqué mon post sur la ML de netfilter !
Donc si vous avez des avis éclairés sur la question...

suivi placé sur fcri

--
Rico
Signaler un problème avec ce contenu

9 réponses

Supprimer
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
Avatar
Pascal Hambourg
Salut,


Ma config est une Debian Sarge avec un kernel Vanilla 2.6.18.2 et
iptables iptables 1.2.11


Ça tombe bien, j'ai la même chose sur une machine, je pourrai reproduire
ta manip et comparer au besoin. Je précise sur architecture i386, car
j'ai eu des échos comme quoi Netfilter pouvait avoir des bugs sur
d'autres architectures.

Ma passerelle est dotée de 3 interfaces :
* eth0 192.168.1.254/24 connecté au lan
* eth1 connect& à mon FAI pro qui me fournit une /28 ipv4
* eth2 10.75.1.254 connecté à une DMZ

Il y a aussi un alias sur eth0:1 192.168.100.253/24 pour une pseudo DMZ.


192.168.100.253 ou 192.168.100.254 ? Dans ton précédent fil, c'était
192.168.100.254 si je ne m'abuse.

Voici le début de ma table FORWARD (police par défaut : DROP)

Chain FORWARD (policy DROP)
target prot opt source destination
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state ESTABLISHED
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state ESTABLISHED
log_drop tcp -- 0.0.0.0/0 0.0.0.0/0 state INVALID
log_drop udp -- 0.0.0.0/0 0.0.0.0/0 state INVALID
ACCEPT tcp -- 192.168.1.0/24 192.168.100.0/24 state NEW


Sans -v, on ne voit pas les interfaces. iptables-save, c'est mieux je
trouve.

Donc un hôte 192.168.1.125 _devrait_ être capable de se connecter à un
hôte 192.168.100.254... Mais regardez une session de capture sur la
passerelle :

# tcpdump -n -i eth0 net 192.168.100.254


'net' pour une adresse d'hôte ?

tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
13:46:08.297208 IP 192.168.1.125.3580 > 192.168.100.254.22: S
3913030203:3913030203(0) win 65535 <mss 1460,nop,nop,sackOK>
13:46:08.297289 IP 192.168.1.125.3580 > 192.168.100.254.22: S
3913030203:3913030203(0) win 65535 <mss 1460,nop,nop,sackOK>
13:46:08.297585 IP 192.168.1.125.3580 > 192.168.100.254.22: . ack
2474300259 win 65535
13:46:11.497946 IP 192.168.1.125.3580 > 192.168.100.254.22: . ack 1 win
65535
13:46:17.496303 IP 192.168.1.125.3580 > 192.168.100.254.22: . ack 1 win
65535

On voit que l'hôte source envoie le 1er paquet pour une poignée de main
TCP, ce paquet est réémis via la même interface.
mais ensuite, au lieu de recevoir un SYN-ACK de la part de l'hôte
destination, on voit que l'hôte source emet un ACK, alors qu'il n'a reçu
aucun SYN-ACK !


[Plutôt que d'hôte source et destination, ce qui peut prêter à confusion
selon la direction du paquet considéré, je préfère parler de client et
de serveur.]

note: la machine source est un poste windows 2000, et j'ai capturé aussi
sur cette machine lors de la tentative de connexion, et elle n'a reçu
_aucun_ SYN-ACK


Si le client envoie un ACK, c'est forcément qu'il a reçu un SYN/ACK du
serveur en réponse à son SYN. Je ne vois pas comment il pourrait en être
autrement. Soit tcpdump n'a pas capturé les paquets émis par le serveur,
soit ils ne sont pas passés par la passerelle.

J'ai pu avoir l'explication en jetant un oeuil dans mon /var/log/message
sur la passerelle :
# tail -n 1000 /var/log/messages|grep 192.168.100.254
Nov 14 13:46:08 localhost kernel: IPT_DROP: IN=eth0 OUT=eth0 SRC > 192.168.1.125 DST2.168.100.254 LEN@ TOS=0x00 PREC=0x00 TTL7 ID > 51586 DF PROTO=TCP SPT580 DPT" WINDOWe535 RES=0x00 ACK URGP=0
Nov 14 13:46:11 localhost kernel: IPT_DROP: IN=eth0 OUT=eth0 SRC > 192.168.1.125 DST2.168.100.254 LEN@ TOS=0x00 PREC=0x00 TTL7 ID > 51589 DF PROTO=TCP SPT580 DPT" WINDOWe535 RES=0x00 ACK URGP=0

Les paquets retour (hote destination vers hote source) sont droppés par
ma 3e règle iptables car conntrack marque la connexion comme étant
invalide !


Il me semble que tu as mal interprété ces messages. On n'y voit aucun
paquet émis par le serveur, mais seulement les deux premiers ACK du
client vus par tcpdump qui n'ont pas été retransmis par la passerelle.

Envisageons que les paquets émis par le serveur ne passent pas par la
passerelle. Elle ne voit pas le SYN/ACK, donc considère que le ACK du
client est inattendu, le marque comme INVALID et le bloque. Je suppose
que le serveur n'ayant pas vu l'acquittement de son SYN/ACK car bloqué
par la passerelle, il le retransmet et donc le client retransmet son
ACK. Tout colle avec les traces.

J'ai fait un test en déplacant la règle 5 de la table FORWARD en position
1, et j'ai rajouté une nouvelle règle :

# iptables -I FORWARD 2 -i eth0 -o eth0 -s 192.168.100.0/24 -d
192.168.1.0/24 -j ACCEPT

Dans ce cas je peux voir le paquet SYN-ACK transiter par la passerelle,


Le SYN/ACK du serveur ? Sur la passerelle ? Ça devient surréaliste...

Avatar
Julien Salgado
Eric Belhomme a écrit(wrote):
bonjour,


Bonjour,


Ma passerelle est dotée de 3 interfaces :
* eth0 192.168.1.254/24 connecté au lan
* eth1 connect& à mon FAI pro qui me fournit une /28 ipv4
* eth2 10.75.1.254 connecté à une DMZ

Il y a aussi un alias sur eth0:1 192.168.100.253/24 pour une pseudo DMZ.
Le but etant qu'un hote de mon LAN soit obligé de passer par la
passerelle pour atteindre une machine de mon pseudo DMZ, bien qu'elles
soient sur le même segment ethernet


Il me semble qu'il y a un autre test à faire en plus de ceux que tu as
fait qui consiste à être sûr de l'état des tables de routage des deux
équipements. Il faut vérifier qu'il n'y a pas au moment du test des
routes en plus.

En effet, si ta passerelle à émis ou émet des icmp-redirect
(ce qui peut être possible, je ne connais pas exactement le comportement
de la pile IPv4 pour des IP aliasées dans des réseaux différents), les
deux machines peuvent avoir apris qu'il est possible d'utiliser le
segment Ethernet commun pour communiquer. Ensuite en fonction du temps
cette information est supprimée.

Pour éliminer cette piste il faudrait être sur de ne pas envoyer ce type
d'ICMP, en jouant avec sysctl sur les variables suivantes :
net.ipv4.conf.ethXX.send_redirects = 0
net.ipv4.conf.ethXX.secure_redirects = 0
Pour faire en sorte de ne pas en accepter :
net.ipv4.conf.ethXX.accept_redirects = 0

Il peu aussi être interessant de voir le trafic ICMP depuis le boot des
deux équipements et jusqu'aux tests.

--
Julien

Avatar
Eric Belhomme
Pascal Hambourg wrote in
news:ejidcb$3us$:

Ça tombe bien, j'ai la même chose sur une machine, je pourrai
reproduire ta manip et comparer au besoin. Je précise sur architecture
i386, car j'ai eu des échos comme quoi Netfilter pouvait avoir des
bugs sur d'autres architectures.

oui je n'ai pas précisé mais il s'agit bien d'un serveur x86 (un dell

PE2450 pour etre precis)

192.168.100.253 ou 192.168.100.254 ? Dans ton précédent fil, c'était
192.168.100.254 si je ne m'abuse.

je vois que tu suis :))

je m'etais amusé à brouiller les pistes dans mon précédent fil donc là je
vous livre les véritables adresses, c'est plus facile pour les captures de
paquets ;)

Sans -v, on ne voit pas les interfaces. iptables-save, c'est mieux je
trouve.



mais il y a beaucoup de règles sur cette passerelle, et je ne voudrais pas
noyer l'info dans l'info. En plus, je ne tiens pas à livrer la config
exacte de mon fireuouaule !

Chain FORWARD (policy DROP 17820 packets, 1976K bytes)
pkts bytes target prot opt in out source destination
125K 68M ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
state ESTABLISHED
10537 1508K ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0
state ESTABLISHED
83 4104 log_drop tcp -- * * 0.0.0.0/0 0.0.0.0/0 state
INVALID
0 0 log_drop udp -- * * 0.0.0.0/0 0.0.0.0/0
state INVALID
27 1819 ACCEPT all -- eth0 eth0 192.168.100.0/24 192.168.1.0/24
380 48330 ACCEPT all -- eth0 eth0 192.168.1.0/24 192.168.100.0/24

'net' pour une adresse d'hôte ?

ben c'est un reéseau avec un masque à 32 bits ;)


[Plutôt que d'hôte source et destination, ce qui peut prêter à
confusion selon la direction du paquet considéré, je préfère parler de
client et de serveur.]

soit. donc le client est 192.168.1.125 (win2k) et le serveur est

192.168.100.254 (linux)

Si le client envoie un ACK, c'est forcément qu'il a reçu un SYN/ACK du
serveur en réponse à son SYN. Je ne vois pas comment il pourrait en
être autrement. Soit tcpdump n'a pas capturé les paquets émis par le
serveur, soit ils ne sont pas passés par la passerelle.

Il me semble que tu as mal interprété ces messages. On n'y voit aucun
paquet émis par le serveur, mais seulement les deux premiers ACK du
client vus par tcpdump qui n'ont pas été retransmis par la passerelle.

oui


Envisageons que les paquets émis par le serveur ne passent pas par la
passerelle. Elle ne voit pas le SYN/ACK, donc considère que le ACK du
client est inattendu, le marque comme INVALID et le bloque. Je suppose
que le serveur n'ayant pas vu l'acquittement de son SYN/ACK car bloqué
par la passerelle, il le retransmet et donc le client retransmet son
ACK. Tout colle avec les traces.

je viens de me refaire une séance de capture, et j'ai fais attentien en

particulier aux entetes ethernet :
- les paquets client->serveur transitent pas la passerelle (MAC source =
MAC de la passerelle)
- les paquets serveur->client transitent directement (MAC destination = MAC
du poste client)


J'en conclus donc que l'icmp_redirect _sur_ le serveur (192.168.100.254)
m'a mis dedans, et une fois de plus, le bogue, c'est moi !

Merci pour ta clairvoyance :)

--
Rico

Avatar
Pascal Hambourg

192.168.100.253 ou 192.168.100.254 ? Dans ton précédent fil, c'était
192.168.100.254 si je ne m'abuse.


je vois que tu suis :))


En fait comme les adresses LAN et DMZ de la passerelle finissent aussi
en .254, j'aurais trouvé cohérent que ce soit aussi le cas de l'adresse
pseudo-DMZ.

je m'etais amusé à brouiller les pistes dans mon précédent fil donc là je
vous livre les véritables adresses, c'est plus facile pour les captures de
paquets ;)


D'accord.

Sans -v, on ne voit pas les interfaces. iptables-save, c'est mieux je
trouve.


mais il y a beaucoup de règles sur cette passerelle, et je ne voudrais pas
noyer l'info dans l'info. En plus, je ne tiens pas à livrer la config
exacte de mon fireuouaule !


Ça fait un peu sécurité par l'obscurité, non ? Tu peux toujours couper
ce qui est sans rapport avec le problème, comme tu l'avais fait. En plus
ton problème ne concerne que des communications locales sur le segment LAN.

Chain FORWARD (policy DROP 17820 packets, 1976K bytes)
pkts bytes target prot opt in out source destination
125K 68M ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state ESTABLISHED
10537 1508K ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 state ESTABLISHED
83 4104 log_drop tcp -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
0 0 log_drop udp -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID


C'était bien la peine, il n'y avait même pas d'interfaces. :-D

27 1819 ACCEPT all -- eth0 eth0 192.168.100.0/24 192.168.1.0/24
380 48330 ACCEPT all -- eth0 eth0 192.168.1.0/24 192.168.100.0/24
[...]

je viens de me refaire une séance de capture, et j'ai fais attentien en
particulier aux entetes ethernet :
- les paquets client->serveur transitent pas la passerelle (MAC source =
MAC de la passerelle)
- les paquets serveur->client transitent directement (MAC destination = MAC
du poste client)


Je suppose que tu as vu ça avec un tcpdump -e sur le serveur ?
L'examen de la table ARP, de la table de routage et du cache de routage
de ce dernier serait intéressant.

J'en conclus donc que l'icmp_redirect _sur_ le serveur (192.168.100.254)
m'a mis dedans, et une fois de plus, le bogue, c'est moi !


Pourtant il me semblait que nous étions plusieurs à avoir conclu que cet
ICMP Redirect était ignoré. Il me semblait aussi que tu avais désactivé
son émission par la passerelle. Si c'est parce que tu as redémarré la
passerelle depuis, tu peux rendre le réglage permanent en ajoutant ces
deux lignes à /etc/sysctl.conf (ça le désactive sur toutes les interfaces) :

net/ipv4/conf/all/send_redirects=0
net/ipv4/conf/default/send_redirects=0

Merci pour ta clairvoyance :)


La clairvoyance n'a rien à voir là dedans, je ne suis pas devin. ;-)
J'avais plutôt un fort doute sur la réalité d'un aussi gros bug dans le
suivi de connexion, je savais que ledit suivi (et son compère le NAT)
marche beaucoup moins bien avec du routage asymétrique, et je commence à
savoir un peu interpréter les traces de tcpdump ou de LOG.

Le plus rigolo est que tout aurait probablement marché avec un noyau
antérieur à 2.6.9, comme le 2.6.8 inclus dans Debian Sarge. C'est
seulement à partir du 2.6.9 que le suivi des connexions TCP a été
sensiblement "amélioré" avec l'inclusion du patch tcp-window-tracking
qui classe désormais par défaut dans l'état INVALID tout segment TCP
dont le numéro de séquence est hors fenêtre. Avec un noyau antérieur,
tous les paquets TCP émis par le client auraient simplement été classés
dans l'état NEW et donc acceptés par ton ex-règle n° 5. Tu devrais
pouvoir retrouver ce comportement avec le réglage suivant :

sysctl -w net/ipv4/netfilter/ip_conntrack_tcp_be_liberal=1


Avatar
Eric Belhomme
Pascal Hambourg wrote in
news:ejk1i6$r98$:

Ça fait un peu sécurité par l'obscurité, non ? Tu peux toujours couper
ce qui est sans rapport avec le problème, comme tu l'avais fait. En
plus ton problème ne concerne que des communications locales sur le
segment LAN.

non ce n'est pas l'idée ! mais entre l'obscurantisme et le full

disclosure, il y a une marge de manoeuvre assez conséquente ;)

Je suppose que tu as vu ça avec un tcpdump -e sur le serveur ?
L'examen de la table ARP, de la table de routage et du cache de
routage de ce dernier serait intéressant.

euh, j'ai triché : j'ai capturé dans un fichier, et j'ai analysé la

capture avec ethereal :p

# for f in /proc/sys/net/ipv4/conf/*/*redirects; do echo "`cat $f` > $f";
done
1 > /proc/sys/net/ipv4/conf/all/accept_redirects
1 > /proc/sys/net/ipv4/conf/all/secure_redirects
1 > /proc/sys/net/ipv4/conf/all/send_redirects
1 > /proc/sys/net/ipv4/conf/default/accept_redirects
1 > /proc/sys/net/ipv4/conf/default/secure_redirects
1 > /proc/sys/net/ipv4/conf/default/send_redirects
1 > /proc/sys/net/ipv4/conf/eth0/accept_redirects
1 > /proc/sys/net/ipv4/conf/eth0/secure_redirects
1 > /proc/sys/net/ipv4/conf/eth0/send_redirects
1 > /proc/sys/net/ipv4/conf/eth1/accept_redirects
1 > /proc/sys/net/ipv4/conf/eth1/secure_redirects
1 > /proc/sys/net/ipv4/conf/eth1/send_redirects
1 > /proc/sys/net/ipv4/conf/lo/accept_redirects
1 > /proc/sys/net/ipv4/conf/lo/secure_redirects
1 > /proc/sys/net/ipv4/conf/lo/send_redirects

# ip neigh sh
192.168.1.10 dev eth0 lladdr 00:11:43:37:3f:be nud stale
192.168.100.253 dev eth0 lladdr 00:02:b3:28:8e:28 nud stale
192.168.1.125 dev eth0 lladdr 00:0d:56:03:72:7d nud reachable

# ip route sh
192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.254
192.168.1.0/24 via 192.168.100.253 dev eth0

J'en conclus donc que l'icmp_redirect _sur_ le serveur
(192.168.100.254) m'a mis dedans, et une fois de plus, le bogue,
c'est moi !


Pourtant il me semblait que nous étions plusieurs à avoir conclu que
cet ICMP Redirect était ignoré. Il me semblait aussi que tu avais
désactivé son émission par la passerelle. Si c'est parce que tu as
redémarré la passerelle depuis, tu peux rendre le réglage permanent en
ajoutant ces deux lignes à /etc/sysctl.conf (ça le désactive sur
toutes les interfaces) :

c'est le cas sur la passerelle, mais pas sur le poste serveur !

j'ai modifié ma config en conséquence ;)

La clairvoyance n'a rien à voir là dedans, je ne suis pas devin. ;-)
J'avais plutôt un fort doute sur la réalité d'un aussi gros bug dans
le suivi de connexion, je savais que ledit suivi (et son compère le
NAT) marche beaucoup moins bien avec du routage asymétrique, et je
commence à savoir un peu interpréter les traces de tcpdump ou de LOG.

oui, j'ai de toute evidence merdé lors de ma 1ere interprétation des

logs... le concept est simple, pourtant en pratique ce devient vite
inbitable :-S

Le plus rigolo est que tout aurait probablement marché avec un noyau
antérieur à 2.6.9, comme le 2.6.8 inclus dans Debian Sarge. C'est
seulement à partir du 2.6.9 que le suivi des connexions TCP a été
sensiblement "amélioré" avec l'inclusion du patch tcp-window-tracking
qui classe désormais par défaut dans l'état INVALID tout segment TCP
dont le numéro de séquence est hors fenêtre. Avec un noyau antérieur,
tous les paquets TCP émis par le client auraient simplement été
classés dans l'état NEW et donc acceptés par ton ex-règle n° 5. Tu
devrais pouvoir retrouver ce comportement avec le réglage suivant :

sysctl -w net/ipv4/netfilter/ip_conntrack_tcp_be_liberal=1

le précédent noyau etait un 2.6.11, et ne posait pas ce problème. J'ai dû

mettre à jour le noyau à cause de ipsec, et quitte à avoir un noyau >=
2.6.15, j'ai opté pour le dernier en date !

--
Rico


Avatar
Dominique ROUSSEAU
Le ven, 17 nov 2006 at 11:13 GMT, Eric Belhomme <{rico}+no/ a écrit :
# for f in /proc/sys/net/ipv4/conf/*/*redirects; do echo "`cat $f` > $f";
done
1 > /proc/sys/net/ipv4/conf/all/accept_redirects
1 > /proc/sys/net/ipv4/conf/all/secure_redirects
1 > /proc/sys/net/ipv4/conf/all/send_redirects
[...]


Plus simple :

grep "." /proc/sys/net/ipv4/conf/*/*redirects

Avatar
Eric Belhomme
Dominique ROUSSEAU wrote in
news::

Plus simple :

grep "." /proc/sys/net/ipv4/conf/*/*redirects



J'ai simplifié mais en faisant

echo "echo `cat $f` > $f" >> ./monfichier

j'obtiens un fichier qu'il me suffit de rendre executable pour reconfigurer
ma pile ip dans son état initial _avant_ que je bricole ;)

mais ton grep est tres élégant, je reconnais !

--
Rico

Avatar
Pascal Hambourg
[...]
# ip neigh sh
192.168.1.10 dev eth0 lladdr 00:11:43:37:3f:be nud stale
192.168.100.253 dev eth0 lladdr 00:02:b3:28:8e:28 nud stale
192.168.1.125 dev eth0 lladdr 00:0d:56:03:72:7d nud reachable


Donc il semble bien que le serveur ait trouvé le moyen de communiquer
directement avec des machines de l'autre sous-réseau.

# ip route sh
192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.254
192.168.1.0/24 via 192.168.100.253 dev eth0


Pas dans la table de routage apparemment. Il aurait fallu regarder dans
le cache de routage : ip route show cache 192.168.1.125.

J'en conclus donc que l'icmp_redirect _sur_ le serveur
(192.168.100.254) m'a mis dedans


Pourtant il me semblait que nous étions plusieurs à avoir conclu que
cet ICMP Redirect était ignoré. Il me semblait aussi que tu avais
désactivé son émission par la passerelle.


c'est le cas sur la passerelle, mais pas sur le poste serveur !


Cela ne suffit quand même pas à expliquer par quel prodige le serveur
aurait pris en compte l'ICMP Redirect pour atteindre directement une
adresse appartenant à l'autre sous-réseau. Il a quelle configuration, ce
serveur ?



Avatar
Eric Belhomme
Pascal Hambourg wrote in news:ejlg1m$1gl1$1
@biggoron.nerim.net:

Pas dans la table de routage apparemment. Il aurait fallu regarder dans
le cache de routage : ip route show cache 192.168.1.125.

trop tard : j'ai modifié sa conf pour ignorer les icmp_redirect !


Cela ne suffit quand même pas à expliquer par quel prodige le serveur
aurait pris en compte l'ICMP Redirect pour atteindre directement une
adresse appartenant à l'autre sous-réseau. Il a quelle configuration, ce
serveur ?

c'est une serveur sous Debian Sarge, avec 2 interfaces sur 2 réseaux

différents hérmétiques (pas de routage)

Ce serveur sert à l'échange de fichier via ftp entre ces 2 réseaux.

--
Rico