Hum bizarre, ça. J’ai rencontré ce genre de choses une fois, c’était avec des machines sous Windows/linux. Si la machine était sous Windows, alors au bout d’un certain temps, elle était inaccessible et mieux, elle ne pouvait se connecter au réseau qu’à partir d’un certain temps. (Sous linux sans problème). La seule façon de réguler les choses était de «pinguer» en permanence ces machines.
J’ai toujours soupconné un problème de «table arp» dans les switchs (le terme «table arp» n’est pas bon et désigne simplement la liste des associations adresses arp <-> ports sur les switchs.
Essaye sur une des machines qui ne peut pas pinguer le serveur de rentrer l’adresse arp du serveur (via arp -s) puis réessaye le ping.
[quote=“fran.b”]Hum bizarre, ça. J’ai rencontré ce genre de choses une fois, c’était avec des machines sous Windows/linux. Si la machine était sous Windows, alors au bout d’un certain temps, elle était inaccessible et mieux, elle ne pouvait se connecter au réseau qu’à partir d’un certain temps. (Sous linux sans problème). La seule façon de réguler les choses était de «pinguer» en permanence ces machines.
J’ai toujours soupconné un problème de «table arp» dans les switchs (le terme «table arp» n’est pas bon et désigne simplement la liste des associations adresses arp <-> ports sur les switchs.
Essaye sur une des machines qui ne peut pas pinguer le serveur de rentrer l’adresse arp du serveur (via arp -s) puis réessaye le ping.[/quote]
ok, ma question était stupide… la commande arp existe sous windows
Une autre question me vient à l’esprit, le fait d’ajouter une entrée ARP avec arp -s, est-ce que ca reste en mémoire après un reboot ?
En fait ARP ne me dit rien, je ne voit pas trop ce à quoi ca sert au niveau réseau…
L’adresse arp est ce qui sert à router les trames ethernet, c’est situé en dessous de la couche IP donc au niveau 2 ou 3 du modèle OSI (3 sans doute en fait). Les adresses arp sont les adresses physiques des cartes réseaux.
Au bout d’un certain temps, la table arp de ta machine (i.e celles qui contient les xcorrespondances entre adresses IP et adresses arp) perd l’entrée de ton serveur. Dans ce cas, quand tu fais un ping, une requête arp est faite. Comme l’adresse arp a disparu, ta machine doit faire une requête arp, elle envoit sur le réseau une requête
Sur tcpdump, ça fait
[quote]16:50:06.039818 arp who-has tonserveur.labase tell tamachine.atoi
[/quote]
Le serveur ou un intermédiaire qui sait (le switch) devrait répondre
[quote]16:51:29.397392 arp reply tonserveur.labas is-at 00:1f:19:f5:aa:f9 (oui Unknown)
[/quote]
par exemple et là les pings partent. Il faudrait savoir pourquoi ces requêtes n’aboutissent pas et donc regarder avec tcpdump qui les reçoit et ne répond pas. Je suoupconne le switch mais bon…
Pascal Hambourg saurait mieux te répondre, il est au fait de ces trucs là je crois bien.
Merci pour cette explication.
Je viens de constater une chose, après avoir fait plusieurs commande arp -a sous windows XP (sous un client linux le problème est le même)
C:\>arp -a
Interface : 172.16.43.150 --- 0x2
Adresse Internet Adresse physique Type
172.16.43.142 00-0e-0c-60-06-25 dynamique
172.16.43.161 00-e0-81-b1-04-58 dynamique
C:\>arp -a
Interface : 172.16.43.150 --- 0x2
Adresse Internet Adresse physique Type
172.16.43.142 00-0e-0c-60-06-25 dynamique
172.16.43.161 00-00-00-00-00-00 non valide
Est-ce que ca peut vous aider à comprendre d’ou vient le problème ?
Si je comprend bien, le serveur doit renvoyer une mauvaise adresse MAC sur le réseau ? Est-ce possible ?
on répond un peu en décalé lol mais bon…
Je ne pense pas que ca soit le switch qui est en cause car le problème ne vient uniquement de ce serveur.
Peut-être que c’est le serveur principale qui est en cause ?
Ou alors ce serveur debian qui est peut-être mal configuré au niveau de son réseau ?
Ce serveur à 2 cartes réseaux et pourtant je vois un eth0, eth1 et eth2.
Pour l’instant tout marche grace à ta commande arp -s mais je suis curieux de savoir le réel problème.
Il faudrait écouter le traffic arp sur le serveur et l’analyser afin de voir comment il répond aux requêtes arp… Une capture du traffic pendant l’essai d’un ping après effacement de l’entrée dans la table arp sur le client.
[code]tcpdump: WARNING: arptype 24 not supported by libpcap - falling back to cooked socket
tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
0 packets captured
0 packets received by filter
0 packets dropped by kernel
[/code]
je pense qu’il y a un problème…
Je vous donne le résultat de ifconfig aussi
[code]eth0 Link encap:UNSPEC HWaddr 00-E0-81-00-00-28-2F-57-00-00-00-00-00-00-00-00
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:7084 dropped:7084 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Bon, je crois avoir quelque chose d’intéressant.
En faite le serveur debian avait avant l’adresse ip 172.16.43.32
Et suite a une coupure de courant, un autre serveur à pris cette adresse ip (172.16.43.32)
Le serveur debian a donc du en trouver une autre.
Via mon serveur DHCP je lui ai réservé 172.16.43.161 pour éviter ce genre de problème.
Quand je regarde le tcpdump, il y a beaucoup de 172.16.43.32 comme si le serveur debian croyait que c’était encore son adresse ip !!
10:54:31.173730 IP serveurdebian.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 250.255.255.239.in-addr.arpa. (46)
10:54:33.169900 IP serveurdebian.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 250.255.255.239.in-addr.arpa. (46)
10:54:35.070178 IP serveurdebian.local.32930 > srvdell.local.domain: 16412+ PTR? 32.43.16.172.in-addr.arpa. (43)
10:54:35.070512 IP srvdell.local.domain > serveurdebian.local.32930: 16412 NXDomain* 0/1/0 (132)
10:54:35.174070 IP serveurdebian.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 32.43.16.172.in-addr.arpa. (43)
10:54:36.178157 IP serveurdebian.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 32.43.16.172.in-addr.arpa. (43)
10:54:36.885985 IP 172.16.43.32.32786 > 239.255.255.250.1900: UDP, length 296
10:54:36.995297 IP 172.16.43.32.32786 > 239.255.255.250.1900: UDP, length 296
10:54:37.105486 IP 172.16.43.32.32786 > 239.255.255.250.1900: UDP, length 297
10:54:37.215673 IP 172.16.43.32.32786 > 239.255.255.250.1900: UDP, length 297
10:54:37.326237 IP 172.16.43.32.32786 > 239.255.255.250.1900: UDP, length 342
10:54:37.436299 IP 172.16.43.32.32786 > 239.255.255.250.1900: UDP, length 342
10:54:37.547110 IP 172.16.43.32.32786 > 239.255.255.250.1900: UDP, length 346
10:54:37.656924 IP 172.16.43.32.32786 > 239.255.255.250.1900: UDP, length 346
10:54:37.767609 IP 172.16.43.32.32786 > 239.255.255.250.1900: UDP, length 346
10:54:37.877424 IP 172.16.43.32.32786 > 239.255.255.250.1900: UDP, length 346
10:54:38.174327 IP serveurdebian.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 32.43.16.172.in-addr.arpa. (43)
10:54:40.074606 IP serveurdebian.local.32930 > srvdell.local.domain: 43147+ PTR? 251.0.0.224.in-addr.arpa. (42)
10:54:40.075055 IP srvdell.local.domain > serveurdebian.local.32930: 43147 NXDomain 0/1/0 (100)
10:54:40.178496 IP serveurdebian.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 251.0.0.224.in-addr.arpa. (42)
10:54:41.178583 IP serveurdebian.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 251.0.0.224.in-addr.arpa. (42)
10:54:43.178754 IP serveurdebian.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 251.0.0.224.in-addr.arpa. (42)
10:54:46.407222 IP info1.local.netbios-dgm > 172.16.43.255.netbios-dgm: NBT UDP PACKET(138)
10:54:46.407291 IP serveurdebian.local.32930 > srvdell.local.domain: 6335+ PTR? 255.43.16.172.in-addr.arpa. (44)
10:54:46.407721 IP srvdell.local.domain > serveurdebian.local.32930: 6335 NXDomain* 0/1/0 (133)
10:54:46.408971 IP 172.16.43.32.netbios-dgm > 172.16.43.255.netbios-dgm: NBT UDP PACKET(138)
10:54:46.511040 IP serveurdebian.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 255.43.16.172.in-addr.arpa. (44)
10:54:47.515124 IP serveurdebian.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 255.43.16.172.in-addr.arpa. (44)
10:54:49.511296 IP serveurdebian.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 255.43.16.172.in-addr.arpa. (44)
10:54:51.412960 IP serveurdebian.local.32930 > srvdell.local.domain: 41078+ PTR? 249.43.16.172.in-addr.arpa. (44)
10:54:51.413389 IP srvdell.local.domain > serveurdebian.local.32930: 41078* 1/0/0 (76)
10:54:57.939572 IP 172.16.43.32.32786 > 239.255.255.250.1900: UDP, length 296
10:54:58.048885 IP 172.16.43.32.32786 > 239.255.255.250.1900: UDP, length 296
10:54:58.159073 IP 172.16.43.32.32786 > 239.255.255.250.1900: UDP, length 297
10:54:58.269261 IP 172.16.43.32.32786 > 239.255.255.250.1900: UDP, length 297
10:54:58.379573 IP 172.16.43.32.32786 > 239.255.255.250.1900: UDP, length 342
10:54:58.489886 IP 172.16.43.32.32786 > 239.255.255.250.1900: UDP, length 342
10:54:58.600697 IP 172.16.43.32.32786 > 239.255.255.250.1900: UDP, length 346
10:54:58.710511 IP 172.16.43.32.32786 > 239.255.255.250.1900: UDP, length 346
10:54:58.821198 IP 172.16.43.32.32786 > 239.255.255.250.1900: UDP, length 346
10:54:58.931010 IP 172.16.43.32.32786 > 239.255.255.250.1900: UDP, length 346
Si j’ai bien suivi, le serveur debian fait une requete DNS sur son propre nom, et le serveur DNS lui renvoie son ancienne ip…
Un truc du genre mais je ne suis pas spécialiste…
Une idée ?
[quote]
Bon, je crois avoir quelque chose d’intéressant.
En faite le serveur debian avait avant l’adresse ip 172.16.43.32
Et suite a une coupure de courant, un autre serveur à pris cette adresse ip (172.16.43.32)
Le serveur debian a donc du en trouver une autre.
Via mon serveur DHCP je lui ai réservé 172.16.43.161 pour éviter ce genre de problème.
Quand je regarde le tcpdump, il y a beaucoup de 172.16.43.32 comme si le serveur debian croyait que c’était encore son adresse ip !!
[code]10:54:31.173730 IP serveurdebian.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 250.255.255.239.in-addr.arpa. (46)
10:54:33.169900 IP serveurdebian.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 250.255.255.239.in-addr.arpa. (46)
10:54:35.070178 IP serveurdebian.local.32930 > srvdell.local.domain: 16412+ PTR? 32.43.16.172.in-addr.arpa. (43)
[/quote]Là serveurlocal demande à srvdell qui est à l’adresse 172.16.43.32
Là, c’est la machine 172.16.43.32 qui envoit des paquets à un peu tout le monde (?)
[quote]
10:54:38.174327 IP serveurdebian.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 32.43.16.172.in-addr.arpa. (43)
10:54:40.074606 IP serveurdebian.local.32930 > srvdell.local.domain: 43147+ PTR? 251.0.0.224.in-addr.arpa. (42)
10:54:40.075055 IP srvdell.local.domain > serveurdebian.local.32930: 43147 NXDomain 0/1/0 (100)
10:54:40.178496 IP serveurdebian.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 251.0.0.224.in-addr.arpa. (42)
10:54:41.178583 IP serveurdebian.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 251.0.0.224.in-addr.arpa. (42)
10:54:43.178754 IP serveurdebian.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 251.0.0.224.in-addr.arpa. (42)
10:54:46.407222 IP info1.local.netbios-dgm > 172.16.43.255.netbios-dgm: NBT UDP PACKET(138)
10:54:46.407291 IP serveurdebian.local.32930 > srvdell.local.domain: 6335+ PTR? 255.43.16.172.in-addr.arpa. (44)
10:54:46.407721 IP srvdell.local.domain > serveurdebian.local.32930: 6335 NXDomain* 0/1/0 (133)
10:54:46.408971 IP 172.16.43.32.netbios-dgm > 172.16.43.255.netbios-dgm: NBT UDP PACKET(138)
10:54:46.511040 IP serveurdebian.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 255.43.16.172.in-addr.arpa. (44)
10:54:47.515124 IP serveurdebian.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 255.43.16.172.in-addr.arpa. (44)
10:54:49.511296 IP serveurdebian.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 255.43.16.172.in-addr.arpa. (44)
10:54:51.412960 IP serveurdebian.local.32930 > srvdell.local.domain: 41078+ PTR? 249.43.16.172.in-addr.arpa. (44)
10:54:51.413389 IP srvdell.local.domain > serveurdebian.local.32930: 41078* 1/0/0 (76)
10:54:57.939572 IP 172.16.43.32.32786 > 239.255.255.250.1900: UDP, length 296
10:54:58.048885 IP 172.16.43.32.32786 > 239.255.255.250.1900: UDP, length 296
10:54:58.159073 IP 172.16.43.32.32786 > 239.255.255.250.1900: UDP, length 297
10:54:58.269261 IP 172.16.43.32.32786 > 239.255.255.250.1900: UDP, length 297
10:54:58.379573 IP 172.16.43.32.32786 > 239.255.255.250.1900: UDP, length 342
10:54:58.489886 IP 172.16.43.32.32786 > 239.255.255.250.1900: UDP, length 342
10:54:58.600697 IP 172.16.43.32.32786 > 239.255.255.250.1900: UDP, length 346
10:54:58.710511 IP 172.16.43.32.32786 > 239.255.255.250.1900: UDP, length 346
10:54:58.821198 IP 172.16.43.32.32786 > 239.255.255.250.1900: UDP, length 346
10:54:58.931010 IP 172.16.43.32.32786 > 239.255.255.250.1900: UDP, length 346
[/code]
Si j’ai bien suivi, le serveur debian fait une requete DNS sur son propre nom, et le serveur DNS lui renvoie son ancienne ip…
Un truc du genre mais je ne suis pas spécialiste…
Une idée ?[/quote]
Ben en fait ce traffic n’est pas très clair, tu devrais faire la chose suivante:
Alors voila, je me suis mis sur une autre machine webserveur.local et j’ai lancé un tcpdump et un ping vers serveurdebian
Sur cette machine, j’avait ajouté serveurdebian dans la table arp
08:15:29.659114 IP webserveur.local.47181 > srvdell.local.domain: 46644+ PTR? 250.255.255.239.in-addr.arpa. (46)
08:15:29.659718 IP srvdell.local.domain > webserveur.local.47181: 46644 NXDomain 0/1/0 (103)
08:15:29.660098 IP webserveur.local.47181 > srvdell.local.domain: 54657+ PTR? 32.43.16.172.in-addr.arpa. (43)
08:15:29.660598 IP srvdell.local.domain > webserveur.local.47181: 54657 NXDomain* 0/1/0 (132)
08:15:29.767916 IP 172.16.43.32.32787 > 239.255.255.250.1900: UDP, length 296
08:15:29.878258 IP 172.16.43.32.32787 > 239.255.255.250.1900: UDP, length 297
08:15:29.988454 IP 172.16.43.32.32787 > 239.255.255.250.1900: UDP, length 297
08:15:30.098762 IP 172.16.43.32.32787 > 239.255.255.250.1900: UDP, length 342
08:15:30.209033 IP 172.16.43.32.32787 > 239.255.255.250.1900: UDP, length 342
08:15:30.319839 IP 172.16.43.32.32787 > 239.255.255.250.1900: UDP, length 346
08:15:30.429578 IP 172.16.43.32.32787 > 239.255.255.250.1900: UDP, length 346
08:15:30.540356 IP 172.16.43.32.32787 > 239.255.255.250.1900: UDP, length 346
08:15:30.650110 IP 172.16.43.32.32787 > 239.255.255.250.1900: UDP, length 346
08:15:35.419290 IP webserveur.local.47181 > srvdell.local.domain: 37224+ A? teracpc8.airaps.local. (39)
08:15:35.419940 IP srvdell.local.domain > webserveur.local.47181: 37224* 1/0/0 A[|domain]
08:15:35.420982 IP webserveur.local > serveurdebian.local: ICMP echo request, id 4415, seq 1, length 64
08:15:35.421427 IP webserveur.local.47181 > srvdell.local.domain: 55471+ PTR? 161.43.16.172.in-addr.arpa. (44)
08:15:35.421784 IP srvdell.local.domain > webserveur.local.47181: 55471* 1/0/0 (79)
08:15:35.425685 arp who-has webserveur.local tell serveurdebian.local
08:15:35.425738 arp reply webserveur.local is-at 00:30:f1:0d:84:be (oui Unknown)[/code]
Donc le ping marche, bizarrement y'a toujours ces lignes avec 172.16.43.32
J'ai fait pareils avec une autre machine (172.16.43.143) ou je n'ai pas rempli la table arp
[code]08:26:05.562836 IP 172.16.43.143.32768 > srvdell.local.domain: 10705+ PTR? 255.43.16.172.in-addr.arpa. (44)
08:26:05.563209 IP srvdell.local.domain > 172.16.43.143.32768: 10705 NXDomain* 0/1/0 (133)
08:26:05.563470 IP 172.16.43.143.32768 > srvdell.local.domain: 62356+ PTR? 154.43.16.172.in-addr.arpa. (44)
08:26:05.563614 IP 172.16.43.32.netbios-ns > 172.16.43.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
08:26:05.563892 IP srvdell.local.domain > 172.16.43.143.32768: 62356* 1/0/0 (79)
08:26:06.457650 arp who-has serveurdebian.local tell 172.16.43.143
08:26:07.457771 arp who-has serveurdebian.local tell 172.16.43.143
08:26:07.560546 IP 172.16.43.32.netbios-ns > 172.16.43.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
08:26:07.561013 IP 172.16.43.32.netbios-ns > 172.16.43.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST[/code]
JE n'ai aucune réponse de serveurdebian, normal puisque je n'arrive pas a le pinguer.
Par contre, toujours ce 172.16.43.32 qui est en fait un NAS, un petit systeme linux embarqué avec samba, ftp, telnet dessus.
Voici les nslookup
[code]# nslookup srvdell
Server: 172.16.43.142
Address: 172.16.43.142#53
Name: srvdell.local
Address: 172.16.43.142
# nslookup serveurdebian
Server: 172.16.43.142
Address: 172.16.43.142#53
Name: serveurdebian.local
Address: 172.16.43.161
# nslookup 172.16.43.32
Server: 172.16.43.142
Address: 172.16.43.142#53
** server can't find 32.43.16.172.in-addr.arpa: NXDOMAIN
je devrais peut etre rajouter l’entrée DNS de 172.16.43.32 sur mon serveur de domaine (srvdell)
J’espère que je vous “embrouille” pas trop avec tout ca, mais ce problème reste tout de même un défit.
qui explique ce qu’est l’adresse 239.255.255.250 et les ports 1900 et 5000.
Tout ce traffic de paquet serait initié par le protocol SSDP (Simple Service Discovery Protocol) et UPnP
Donc surment mon srvdell (windows server 2003) qui fait tout ca…
Dans tous les cas, mon serveurdebian fait le fantome, il peut aller se connecter partout, mais personne ne l’atteind SAUF si le serveurdebian ping la machine qui essaie de l’atteindre…
On dirait une règle de sécurité que si j’avais voulu le faire, je n’y serait jamais arriver
Il serait judicieu, je pense, de mettre sur papier ton plan d’addressage IP complet. Cela t’aideras pour t’y retrouver d’un seul coup d’oeuil.
Attention aux masques! Perso avec du 172.16.x.x en IP, je préfère rester en “classfull”, donc un masque de 255.255.0.0. Mais ça reste un choix.
En ce qui concerne les IP des serveurs, fixes les en dur(dans leurs /etc/network/interfaces respectifs). Cela permetterat d’éviter qu’une machine prenne l’IP prévue pour une autre(suite à une panne de courant par ex…).
auto eth0
iface eth0 inet static
address 172.16.43.161
netmask 255.255.255.0
network 172.16.43.0
broadcast 172.16.43.255
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers 172.16.43.x
dns-search lenomdedomaine.dureseau
Vérifies ensuite la config de ton serveur DNS(+ reverse DNS, of course). Histoire d’être sûr que la bonne IP correspond au bon nom de machine et inversement. Suite à la panne de courant, le serveur DHCP a donné l’IP à un autre serveur, mais le changement a-t-il été fait au niveau du DNS?
A partir de là, il te serat plus simple de rectifier le tir.
D’après ton /etc/network/interfaces, il y a une interface déclarée et t’en as trois d’après ifconfig
Juste deux questions, “avahi” ne serait pas installé par hazard? Y’a-t-il un ou plusieur port firewire actif sur la machine?
J’ai demandé à Pascal de jeter un oeil. Je vais mieux regarder les tcpdump que tu as fait, un coup de google m’avait conduit à soupconner que effectivement, l’autre serveur n’y était pour rien, il faudrait effectivement le mettre dans le DNS, ça calmerait les requêtes qui doivent venir des autres serveurs, je réfléchis sinon…
eth0 est probablement une interface Firewire.
Je doute d’un problème de masque suggéré par debcool car une entrée statique ARP ne le résoudrait pas, mais on ne sait jamais, donc vérifier sur chaque machine concernée avec
ip addr
ip route
Commentaire perso : ces captures sont illisibles, icomplètes et polluées par du multicast UPnP, du trafic DNS, Netbios et autres trucs sans intérêt. Je suggère plutôt :
Explications :
"-n" c’est pour ne pas faire de résolution d’adresses et ports
"-e" c’est pour afficher les adresses MAC source et destination, afin de voir exactement qui envoie les trames à qui.
“arp or icmp” c’est pour ne capturer que le trafic ARP et ICMP/IP (en faisant un ping donc)
Remplacer “ethX” par le nom réel de l’interface concernée.
A faire sur les deux marchines, celle qui envoie le ping et celle qui en est la cible, pour pouvoir comparer.
Et tant qu’on y est :
toujours des deux côtés, avant et après. Le -n, c’est toujours pour éviter les résolutions d’adresses. Les noms, c’est pas clair. Les adresses, si.
une idée? iptables peut bloquer le traffic arp mais cela me parait curieux sur un serveur interne. Je ne vois pas trop d’où ça peut venir. J’aurais plutôt tendance à penser que la requête ne parvient pas au serveur mais bon.
Tiens une question, est ce que les pings des machines clients sont tous bloqués en même temps ou c’est un pbm individuel et indépendant d’un client à un autre?
Non, iptables ne voit passer que le trafic IPv4, pas le trafic ARP. IP et ARP sont deux protocoles distincts. Ce n’est pas comme en IPv6 où le procotole équivalent à ARP, qu’on appelle “Neighbor Discovery”, est un sous-ensemble d’ICMPv6, donc fait partie intégrante du protocole IPv6 et peut être filtré avec ip6tables.
ARP peut être filtré par arptables, ou par ebtables sur les interfaces pontées. Il y a aussi des paramètres du noyau dans /proc/sys/net/ipv4/conf/ (arp_ignore, arp_filter…) qui influent sur la réponse aux requêtes ARP, mais je doute que ce soit le cas ici.
C’est pour ça qu’il faut faire tourner tcpdump des deux côtés en même temps pour comparer ce qui part et ce qui arrive dans les deux sens.
