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