réseau: 2 machines se voient mais ne se répondent pas

Support Debian
#1

salut,

2 machines A et B avec système idendique (Linux debian 2.6.32-5-amd64) sur le même réseau ne se répondent pas

A ping B la réponse est :

tcpdump:

16:56:01.483272 IP debian1.local > debian-2.local: ICMP echo request, id 3816, seq 1, length 64 16:56:02.491815 IP debian1.local > debian-2.local: ICMP echo request, id 3816, seq 2, length 64 16:56:03.502852 IP debian1.local > debian-2.local: ICMP echo request, id 3816, seq 3, length 64 16:56:04.511467 IP debian1.local > debian-2.local: ICMP echo request, id 3816, seq 4, length 64

si la machine B ping la machine A , tcpdump: même constat, les paquets arrivent mais pas de réponse.

sur les 2 machines j’ ai vidé les règles ipables:

[code]Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination [/code]

le routage est bon puisque les paquets icmp arrivent bien à destination

[code]Destination Passerelle Genmask Indic Metric Ref Use Iface
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
0.0.0.0 192.168.2.1 0.0.0.0 UG 0 0 0 eth1

[/code]

sur l’ autre:

Destination Passerelle Genmask Indic Metric Ref Use Iface 192.168.2.0 0.0.0.0 255.255.255.0 U 0 2 0 wlan0 0.0.0.0 192.168.2.1 0.0.0.0 UG 0 0 0 wlan0

chaque machine peut pinguer le routeur 192.168.2.1 et le WAN (internet) sans problème.

ifconfig

[code]eth1 Link encap:Ethernet HWaddr XXXXXXXXXXXXXXXXXXXXXXXX
inet adr:192.168.2.100 Bcast:192.168.2.255 Masque:255.255.255.0
adr inet6: fe80::223:5aff:fee3:c89f/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:4592 errors:0 dropped:0 overruns:0 frame:0
TX packets:3432 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:4221918 (4.0 MiB) TX bytes:1124070 (1.0 MiB)
Interruption:18

lo Link encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hôte
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:305122 errors:0 dropped:0 overruns:0 frame:0
TX packets:305122 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:122027498 (116.3 MiB) TX bytes:122027498 (116.3 MiB)

[/code]

[code]lo Link encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hôte
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:466 errors:0 dropped:0 overruns:0 frame:0
TX packets:466 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:41390 (40.4 KiB) TX bytes:41390 (40.4 KiB)

wlan0 Link encap:Ethernet HWaddr XXXXXXXXXXXXXXXX
inet adr:192.168.2.101 Bcast:192.168.2.255 Masque:255.255.255.0
adr inet6: fe80::21f:3aff:fe3e:9520/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:855 errors:0 dropped:0 overruns:0 frame:0
TX packets:1183 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:247485 (241.6 KiB) TX bytes:175721 (171.6 KiB)
[/code]

j’ ai changé le routeur dlink pour celui de chez free, même constat

une piste si quelqu’ un a une idée:
le système de la machine B est un clone de la machine A (juste changé les hostname)

#2

Que contient /proc/sys/net/ipv4/icmp_echo_ignore_all ?
Que contiennent les autres tables d’iptables (iptables-save) ?
Qu’est-ce que ça donne avec autre chose que le ping (telnet…) ?

Notes :
Tcpdump, c’est mieux avec les adresses numériques (-n).
C’était bien la peine de masquer les adresses MAC, on peut les retrouver à partir de l’EUI-64 des adresses IPv6 link local.

#3

essaye d’ouvrir une connexion ssh entre les deux et dit nous si cela marche

#4

@PASCALHAMBOURG @xps

j’ ai installé le serveur ssh, effectivement j’ arrive à me connecter sans problème.

du coup le partage de fichier (avec le montage de fusesmb) commence à visualiser les répertoires et fichiers sur la destination puis il stoppe net avec le message suivant: “Noeud final de transport n’est pas connecté”

la réponse aux ping (ICMP) ne fonctionne toujours pas.

@PASCALHAMBOURG

sur les 2 machines:

[code]iptables-save

Generated by iptables-save v1.4.8 on Thu Jun 21 10:27:28 2012

*filter
:INPUT ACCEPT [27525]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [27837:9855135]
COMMIT[/code]

cat /proc/sys/net/ipv4/icmp_echo_ignore_all 1

oui c’ est vrai avec IPV6 on peut retrouver l’ adresse MAC, le pire est que je le savais :laughing:

#5 

et retente ton ping

et retente ton ping

#6

et oui ICMP était bien ignoré avec 1 dans ce fichier, /proc/sys/net/ipv4/icmp_echo_ignore_all
les réponses se font bien…
je met ce post en résolu

mais toujours le problème avec fusesmb et son message:
‘fuse: bad mount point Network': Noeud final de transport n'est pas connecté' parfois je commence à voir les répertoires de destination dans thunar puis ce fameux message: 'fuse: bad mount pointNetwork’: Noeud final de transport n’est pas connecté’
pourtant smb.conf est bien configuré.

je fais une recherche la dessus et si je ne trouve pas, je ferais un nouveau post, celui-ci est on va dire résolu

#7

oublie pas de faire en sorte que ton icmp_echo_ignore_all soit bien à 0 au démarrage la commande que je t’ai donné ne supporte pas le redémarrage.

[quote=“nykoos”]

mais toujours le problème avec fusesmb et son message:
‘fuse: bad mount point Network': Noeud final de transport n'est pas connecté' parfois je commence à voir les répertoires de destination dans thunar puis ce fameux message: 'fuse: bad mount pointNetwork’: Noeud final de transport n’est pas connecté’
pourtant smb.conf est bien configuré.

je fais une recherche la dessus et si je ne trouve pas, je ferais un nouveau post, celui-ci est on va dire résolu[/quote]

pour ça je ne pourrait pas t’aider mais quelqu’un trouveras bien^^

#8

Si c’était juste pour tester, ça fait un peu riche…
Il aurait suffit de lancer un telnet ou netcat (nc) sur un port même fermé pour voir si un paquet de réponse (même négative) était émis.

En effet, à ma connaissance ce paramètre du noyau (volatil comme tous les paramètres du noyau ainsi que tu le soulignes) est à 0 (désactivé) par défaut. Donc il y doit y avoir quelque chose qui l’active au démarrage. Nykoos : regarde dans /etc/sysctl.conf ou /etc/sysctl.d/*, ou dans la configuration du pare-feu s’il y en a un (apparemment non d’après l’absence de règles iptables).

Je ne peux pas aider non plus concernant fuse.

#9

bien vu @PASCALHAMBOURG

net.ipv4.icmp_echo_ignore_all=1

était bien dans /etc/sysctl.conf

#10

En même temps il n’a pas 50 endroits où regarder…
Sauf erreur ce n’est pas dans la configuration par défaut de ce fichier, donc quelqu’un a dû le modifier.

#11

[quote=“PascalHambourg”]En même temps il n’a pas 50 endroits où regarder…
Sauf erreur ce n’est pas dans la configuration par défaut de ce fichier, donc quelqu’un a dû le modifier.[/quote]

non en effet ce n’est pas dans la config par défaut vérifie qui accède a ta machine et qui a le mdp root et dit lui de ne pas faire n’importe quoi^^

#12

[quote=“xps”][quote=“PascalHambourg”]En même temps il n’a pas 50 endroits où regarder…
Sauf erreur ce n’est pas dans la configuration par défaut de ce fichier, donc quelqu’un a dû le modifier.[/quote]

non en effet ce n’est pas dans la config par défaut vérifie qui accède a ta machine et qui a le mdp root et dit lui de ne pas faire n’importe quoi^^[/quote]

non c’est moi qui avait rentré des règles iptables, je pensais qu’ en les supprimant, cela remettait tout par défaut.

#13

[quote=“nykoos”][quote=“xps”][quote=“PascalHambourg”]En même temps il n’a pas 50 endroits où regarder…
Sauf erreur ce n’est pas dans la configuration par défaut de ce fichier, donc quelqu’un a dû le modifier.[/quote]

non en effet ce n’est pas dans la config par défaut vérifie qui accède a ta machine et qui a le mdp root et dit lui de ne pas faire n’importe quoi^^[/quote]

non c’est moi qui avait rentré des règles iptables, je pensais qu’ en les supprimant, cela remettait tout par défaut.[/quote]

ce n’est pas une règle iptables du tout…

#14

[quote=“xps”][quote=“nykoos”][quote=“xps”][quote=“PascalHambourg”]En même temps il n’a pas 50 endroits où regarder…
Sauf erreur ce n’est pas dans la configuration par défaut de ce fichier, donc quelqu’un a dû le modifier.[/quote]

non en effet ce n’est pas dans la config par défaut vérifie qui accède a ta machine et qui a le mdp root et dit lui de ne pas faire n’importe quoi^^[/quote]

non c’est moi qui avait rentré des règles iptables, je pensais qu’ en les supprimant, cela remettait tout par défaut.[/quote]

ce n’est pas une règle iptables du tout…[/quote]

personne ne connait le mot de passe root (trop compliqué) et comme je n’ ai jamais écrit dans ce fichier, j’ en déduis que ce sont mes parefeu via iptables qui ont mis cette ligne à 1

d’ ailleurs je vais le savoir je vais les réinstaller de suite.

EDIT: non effectivement, mes script iptables ne modifient pas cette ligne… :017 mystère…
le iptables -t filter -A INPUT -p icmp -j DROP n’ a rien à voir.