Host non visible à partir d’un seul autre sur le même réseau local

J’ai un pb que je n’arrive pas à expliquer.

PC1, PC2, et PC3 sont sur le même réseau local, j’effectue toutes mes cdes avec les adresses IP.

Sur PC1, : ping PC3 Ok

Sur PC2 : ping PC3 KO

Sur PC2 : la table arp est à jour.

Sur PC2 : traceroute PC3

1 * * *

30 * * *

Sur PC3 : iptables est vide.

Un lecteur a-til une idée pour d’autres analyses, je ne souhaite pas réinitialiser la box, qui est distante, pour l’instant.

C’est-à-dire ?

C’est-à-dire ?

Pas besoin de la reset, tu rentres dedans via ton navigateur et tu vois dans les options d’administration si quelquechose cloche

@DarkGagan

Précisément je ne vois rien qui cloche …

vous avez pensé au cable tout simplement ?
Ping PC1 PC2 ?
Ping PC2 PC1 ?

Le cable est - il le bon ?
Est -il defectueux ?

1 J'aime

Bonsoir @PascalHambourg
Pour info
PC1 192.168.0.180
PC2 … 190
PC3 … 186

ping PC3 à partir de PC2

ping 192.168.0.186
PING 192.168.0.186 (192.168.0.186) 56(84) bytes of data.

Arrêt par CTRL+C
— 192.168.0.186 ping statistics —
1107 packets transmitted, 0 received, 100% packet loss, time 1132403ms

arp PC2
arp -na
? (192.168.0.1) at 88:71:b1:aa:60:5f [ether] on eno1 <------ Box
? (192.168.0.186) at 4a:4b:4c:4d:00:86 [ether] on eno1 <----- PC3
? (192.168.0.180) at 54:04:a6:b4:aa:09 [ether] on eno1 <------ PC1
? (169.254.60.6) at on eno1

@Tamie
Merci pour cette piste que j’avais oubliée.
Je n’ai pas accès aux câbles , c’est une config distante sans personne présente (avant ~1 mois)
PC1 et PC2 sont 2 hosts physiques, je ne suis plus sûr je crois que l’un est en ethernet direct, j’autre via un module CPL … et en écrivant ces lignes c’est peut la cause du pb? (d’autant que c’est une modif ‹ récente ›)
PC3 est un LXC dans PC1
Ceci dit à distance j’accède sans pb aux 3 hosts en passant pas PC2 (NAT du ssh sur ce PC)

Les PCL sont en général d’une fiabilité douteuse. Il faut souvent les relancer, ou les reconfigurer.

Bonsoir @Zargos

Je n’ai jamais eu à faire avec un CPL, je ne pense pas que l’on puisse faire qqc à distance d’autant que je ne sais même pas la marque et le modèle!
Sans autre idée, il me faudra attendre une présence physique sur place.
Ceci dit PC2 ping sans pb PC1 …

Infos complémentaires.

Sur le réseau local, il y a un autre host physique (PC4) , le ping passe.

Je viens de mettre en service un 2ème LXC sur PC1, le ping ne passe pas …

A noter que ces LXC fonctionnaient sans pb avant (le CPL)

Repondre à un ping est peut-être interdit selon l’architecture… selon la pile de couche OSI.

Autre chose, au pif…
On est en train de changer d’adressage.
On passe de IPv4 à IPv6, peut-être qu’il répond à IPv6 et point barre.

Explication possible et probable au réveil.

PC1 et PC2 étaient sur un même câble ethernet derrière un switch local. PC3, les LXC, sont configurés depuis longtemps, mais à l’arrêt et démarrés de temps en temps pour essais.
Il y a ~2 mois, le switch est tombé en panne et un CPL disponible a été mis en place immédiatement. Comme tout fonctionnait (hors LXC non démarrés et (donc) testés) le CPL a été laissé en place.
Hier j’ai pour la première fois depsui 2 mois, souhaité faire un essai avec le LXC PC3 et suis tombé sur ce pb … et j’avais totalement oublié le CPL.
J’imagine donc que le CPL enregistrerait les hosts à sa mise en service ou ? pour une cause inconnue il ne passerait pas le bridge sur PC1 pour atteindre les LXC.
Explication finale dans ~1mois je l’espère (sauf si l’on imagine d’autres essais à faire à distance)
Merci à tous pour vos retour et en particulier à @Tamie qui m’a remis le CPL en tête.

Dans les logs tu ne vois rien ? Aucune trace de refus ?

Rien vu de spécial , vais approfondir un peu …

Pas d’erreur « unreachable host » de ping et la résolution ARP semble fonctionner donc la connectivité ethernet semble bonne.

Que donne un ping de PC3 vers PC2 ?
Quelle est le contenu de la table ARP de PC3 ?
Y a-t-il un jeu de règles iptables ou nftables sur PC1 ?

Qu’entends-tu exactement par « accéder » ?

Depuis où vers où ?

Depuis où vers où ?

En coaxial ?

Afin d'être plus lisible, je rebaptise PC3 en LXC11.

La situation est donc la suivante.

PC1 (192.168.0.180) host physique sur lequel se trouve le container LXC11 (192.168.0.186)

PC2 (192.168.0.190) host physisque qui n'arrive pas à pinger LXC11

Pour mémoire j'effectue toutes mes ces avec les adresses IP.

J’ai un autre pb, ping n’est pas installé et je n’arrive pas à installer (apt update reste à 0% alors que /etc/resolv.conf est a priori correst)
Par contre ping est installé sur LXC12, et je n’arrive qu’à pinger PC1 (le host maître) localhost, parc ontre même pas la box!. Par ailleurs apt update ne fonctionne pas non plus.

arp -an
? (192.168.0.185) at 4a:4b:4c:4d:00:85 [ether] on eth0 <------------- LXC12
? (192.168.0.18) at 00:16:d3:4d:69:c0 [ether] on eth0 <------------- PC4
? (192.168.0.190) at ec:9a:74:42:f2:74 [ether] on eth0 <------------- PC2
? (192.168.0.1) at 88:71:b1:aa:60:5f [ether] on eth0 <------------- Box
? (192.168.0.180) at 54:04:a6:b4:aa:09 [ether] on eth0 <------------- PC1

Oui, PC1 et PC2, monitorix et fail2ban. Monitorix supervision uniquement a priori et pas de LXC11 dans la jail fail2ban

Au besoin je peux supprimer temporairement ces 2 règles.

ssh <ip_wan> -> PC2

de PC2, ssh PC1

de PC1, ssh LXC11

mais ssh LXC11 pas possible de PC1

De tous et surtout de PC2 qui est l’ennoncé du pb.

Toujours de PC2, donc ping PC2 vers LXC11 ou LXC12 (2 LXC sur PC1) ne passe pas

RJ45

Complément 1 - Tcpdump

j’ai regardé avec tcp dump (tcpdump -nN -s 1500 icmp)
sur PC1 je vois bien les requêtes du ping émis par PC2 vers LXC11, mais aucun reply.

Je ne sais pas si je peux pousser l’analyse avec cet outil.

Complément 2 - Les routes - à toutes fins utiles

PC1
default via 192.168.0.1 dev br0 onlink
192.168.0.0/24 dev br0 proto kernel scope link src 192.168.0.180
PC2
default via 192.168.0.1 dev eno1 onlink
192.168.0.0/24 dev eno1 proto kernel scope link src 192.168.0.190
LXC11
default via 192.168.0.1 dev eth0
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.186

ping fait pourtant partie du système de base de Debian. Puisquie tu peux accéder à la machine par SSH, tu peux copier et installer le paquet iputils-ping manuellement.

Il faut être plus précis. Que se passe-t-il exactement ?

D’après la table ARP de LXC11, le trafic ARP passe bien entre elle et toutes les autres machines.

Les deux dernières lignes se contredisent.
« Pas possible » : pas assez précis. Que se passe-t-il exactement ?

Donc vers PC4 ? Comment peux-tu dire de tous alors que ping n’est pas installé sur LXC11 ?

Difficile à croire. Cela voudrait dire qu’elles sont connectées aux deux extrémités d’un même câble, donc pas au reste du réseau.

Mais comme tu ne regardes pas l’ARP, tu te prives de la moitié des informations.
Note : -N est superflu avec -n.

Idéalement, il faudrait faire une capture sur toutes les interfaces qui sont censées voir passer le trafic :

  • eth0 de LXC11
  • l’interface virtuelle vers LXC11 et l’interface ethernet physique du pont br0 de PC1
  • l’interface eno1 de PC2

Bonsoir @PascalHambourg ,

Merci pour ton retour, je regroupe l’ensemble questions/réponses pour obtenir un ensemble plus lisible en commençant par les sujets les plus simples (a prioiri)

1) câbles ethernet

Il fallait comprendre, en fonction des posts précédents, PC1 et PC2 étaient reliés via un switch à la box par un même câble ethernet RJ45.

2) accès ssh

Effectivement les 2 dernières lignes sont contradictoires car il y a une erreur de frappe, c’est bien (toujours) l’accès à partir de PC2 qui ne passe pas.

de PC2 : ssh -vvv LCX11
OpenSSH_7.4p1 Debian-10+deb9u7, OpenSSL 1.0.2u 20 Dec 2019
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving « 192.168.0.186 » port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 192.168.0.186 [192.168.0.186] port 22.
debug1: connect to address 192.168.0.186 port 22: Connection timed out
ssh: connect to host 192.168.0.186 port 22: Connection timed out

3) Ping sur LXC11
Je n’ai pas cherché à installé ping sur LXC11 sachant que j’avais le résultat souhaité via LXC12

4) Tcpdump sur toutes les interfaces concernées.
Compris et en phase, il faut bien voir si la requête arrive à LXC11 et le cas échéant où passe la réponse.

Pour cela il faut que j’installe tcpdump (et iputils-pingsur LXC11) sans apt. A suivre.

en gros, fait nous un détail de ton architecture pour éviter qu’on ne parle tous dans le vide.
Architecture ca veut dire tous les elements de ton reseau local avec qui est relié physiquement à qui, déjà, pour le logique ca sera après.

1 J'aime