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.
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 reç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 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 !
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,
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.
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 reç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 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 !
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,
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.
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 reç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 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 !
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,
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
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
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
Ç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
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 :))
Sans -v, on ne voit pas les interfaces. iptables-save, c'est mieux je
trouve.
'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
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
Ç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
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 :))
Sans -v, on ne voit pas les interfaces. iptables-save, c'est mieux je
trouve.
'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
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
Ç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
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 :))
Sans -v, on ne voit pas les interfaces. iptables-save, c'est mieux je
trouve.
'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
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
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
[...]
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 :)
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
[...]
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 :)
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
[...]
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 :)
Ç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
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
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 !
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
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û
Ç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
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
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 !
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
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û
Ç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
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
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 !
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
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û
# 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
[...]
# 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
[...]
# 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
Plus simple :
grep "." /proc/sys/net/ipv4/conf/*/*redirects
Plus simple :
grep "." /proc/sys/net/ipv4/conf/*/*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
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 !
# 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
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 !
# 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
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 !
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
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
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
