Pas d'accès Internet depuis container sur Serveur Advanced / Proxmox / VM Debian / Docker

MickaelG12 · April 2, 2025, 3:27pm

Bonjour à tous,

Depuis la dernière gamme de serveurs Advanced et ses particularités pour gérer les IP failover sur les VM Proxmox, je n'arrive pas à faire en sorte que les containers Docker déployés sur une VM Debian 12 accèdent à Internet.

Le trafic entrant sur une IP failover (Internet -> Proxmox -> VM Debian -> Docker -> Container) fonctionne très bien, mais l'inverse n'est pas vrai.

Le coupable est tout désigné, c'est le marquage des paquets pour qu'ils reviennent au bon endroit.
Un ping depuis la VM vers l'IP local de Proxmox (réseau 192.168.0.x) indique bien l'IP publique configurée sur la VM comme source du ping.
Le même ping depuis un container vers l'IP local de Proxmox indique malheureusement l'IP locale de la VM (192.168.0.x) en source.

Qui aurait une solution ?
Merci

le_sbraz · April 2, 2025, 3:45pm

Bonjour,
Avez-vous suivi https://help.ovhcloud.com/csm/fr-dedicated-servers-proxmox-network-hg-scale?id=kb_article_view&sysparm_article=KB0043915 ? Il faut bien laisser la règle de routage avec comme IP source l'additional IP.
Avec ifupdown :

up ip route replace default via 192.168.0.1 dev $IFACE onlink src ADDITIONAL_IP

Avec Netplan :

from: ADDITIONAL_IP

Pouvez-vous partager la config réseau de votre VM et la sortie de :

ip -4 ro

MickaelG12 · April 2, 2025, 3:54pm

Bonjour le_sbraz

Oui on avait même fait ça ensemble pour les VM Windows en septembre dernier.

La VM accède correctement à internet.
C'est seulement depuis les containers Docker qu'Internet n'est pas accessible.

le_sbraz · April 2, 2025, 4:17pm

Ah oui ça me rappelle quelque chose :) J'ai lu la question trop vite, désolé.

Pouvez-vous :

- lancer sur la VM "tcpdump -ni any icmp and host ovh.com"
- Exécuter "ping ovh.com -c1" depuis le conteneur
- Exécuter le même ping mais depuis la VM

Normalement, dans le premier cas, vous allez voir des paquets avec comme source le réseau Docker en 172.x sur veth puis sur bridge dockerX, ensuite le paquet sortant par l'interface de la VM qui porte l'IP publique. Dans le second cas, il n'y aura que le paquet sortant de l'interface de la VM.

Je suis curieux de voir ce que ça donne. Il faudra peut-être jouer avec des règles de SNAT comme proposé sur le forum en effet. J'attends le résultat de vos commandes pour aller plus loin dans le diag.

MickaelG12 · April 2, 2025, 4:25pm

Voici les résultats :

Depuis le container :
18:22:57.695623 vethc5f41af P   IP 172.26.0.2 > 198.27.92.1: ICMP echo request, id 44, seq 0, length 64
18:22:57.695623 br-f62a70ba5d30 In  IP 172.26.0.2 > 198.27.92.1: ICMP echo request, id 44, seq 0, length 64
18:22:57.695646 ens18 Out IP 192.168.0.102 > 198.27.92.1: ICMP echo request, id 44, seq 0, length 64

Depuis la VM :
18:23:07.993138 ens18 Out IP 164.132.xxx.yyy > 198.27.92.1: ICMP echo request, id 1884, seq 1, length 64
18:23:07.993294 ens18 In  IP 198.27.92.1 > 164.132.xxx.yyy: ICMP echo reply, id 1884, seq 1, length 64

PS : comment on répond en texte brut car les réponse en HTML bug à l'affichage ?

le_sbraz · April 2, 2025, 5:08pm

Essayez peut-être le bouton "code source" pour répondre en texte. J'ai remonté le bug aux équipes qui gèrent le forum dans tous les cas.

Que donne "iptables-save" sur la VM ? Vous avez une règle de masquerade du genre "-A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE" ? Cette règle doit prendre l'IP principale de l'interface au lieu de l'IP publique.

Il serait possible de changer ça côté Docker en désactivant les règles de pare-feu (https://docs.docker.com/engine/network/packet-filtering-firewalls/#prevent-docker-from-manipulating-iptables) et en les gérant manuellement mais je ne le conseille que si vous êtes à l'aise avec iptables.

Sinon, côté hyperviseur, vous pouvez essayer quelque chose comme "iptables -t nat -A POSTROUTING -s 192.168.0.102/32 -j SNAT --to-source 164.132.x.y", c'est ce qui est conseillé sur le forum et ça devrait fonctionner.

N'hésitez pas à lancer du tcpdump sur l'hyperviseur, ça peut vous aider à voir ce que font les paquets. Il est aussi possible d'ajouter des "-j LOG" ou "-j TRACE" dans les règles iptables pour voir ce que font les paquets, mais ça ne devrait pas être nécessaire pour une "simple" NAT source.

MickaelG12 · April 2, 2025, 6:03pm

Il y a bien la ligne "-A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE".

Ci-joint le résultat d'iptables.

J'ai tenté en ajoutant "iptables -t nat -A POSTROUTING -s 192.168.0.102/32 -j SNAT --to-source 164.132.x.y".

Le résultat du ping depuis le container (tcpdump exécuté sur VM) :

19:57:48.089499 veth582d290 P IP 172.26.0.2 > 198.27.92.1: ICMP echo request, id 40, seq 0, length 64

19:57:48.089499 br-f62a70ba5d30 In IP 172.26.0.2 > 198.27.92.1: ICMP echo request, id 40, seq 0, length 64

19:57:48.089517 ens18 Out IP 192.168.0.102 > 198.27.92.1: ICMP echo request, id 40, seq 0, length 64

Le résultat du ping depuis le container (tcpdump exécuté sur Proxmox) :

19:57:48.090965 tap102i0 P IP 192.168.0.102 > 198.27.92.1: ICMP echo request, id 40, seq 0, length 64

19:57:48.090980 fwln102i0 Out IP 164.132.x.y > 198.27.92.1: ICMP echo request, id 40, seq 0, length 64

19:57:48.090981 fwpr102p0 P IP 164.132.x.y > 198.27.92.1: ICMP echo request, id 40, seq 0, length 64

19:57:48.090984 vmbr0 In IP 164.132.x.y > 198.27.92.1: ICMP echo request, id 0, seq 0, length 64

19:57:48.090988 enp10s0f0np0 Out IP 164.132.x.y > 198.27.92.1: ICMP echo request, id 0, seq 0, length 64

19:57:48.091124 enp10s0f0np0 In IP 198.27.92.1 > 164.132.x.y: ICMP echo reply, id 0, seq 0, length 64

19:57:48.091129 vmbr0 Out IP 198.27.92.1 > 164.132.x.y: ICMP echo reply, id 40, seq 0, length 64

19:57:48.091130 fwpr102p0 Out IP 198.27.92.1 > 164.132.x.y: ICMP echo reply, id 40, seq 0, length 64

19:57:48.091132 fwln102i0 P IP 198.27.92.1 > 164.132.x.y: ICMP echo reply, id 40, seq 0, length 64

Mais les paquets ne reviennent toujours pas dans le container.

Le résultat du ping depuis la VM (tcpdump exécuté sur Proxmox) :

20:00:31.403815 tap102i0 P IP 164.132.x.y > 198.27.92.1: ICMP echo request, id 2310, seq 1, length 64

20:00:31.403823 fwln102i0 Out IP 164.132.x.y > 198.27.92.1: ICMP echo request, id 2310, seq 1, length 64

20:00:31.403824 fwpr102p0 P IP 164.132.x.y > 198.27.92.1: ICMP echo request, id 2310, seq 1, length 64

20:00:31.403825 vmbr0 In IP 164.132.x.y > 198.27.92.1: ICMP echo request, id 2310, seq 1, length 64

20:00:31.403827 enp10s0f0np0 Out IP 164.132.x.y > 198.27.92.1: ICMP echo request, id 2310, seq 1, length 64

20:00:31.404021 enp10s0f0np0 In IP 198.27.92.1 > 164.132.x.y: ICMP echo reply, id 2310, seq 1, length 64

20:00:31.404027 vmbr0 Out IP 198.27.92.1 > 164.132.x.y: ICMP echo reply, id 2310, seq 1, length 64

20:00:31.404029 fwpr102p0 Out IP 198.27.92.1 > 164.132.x.y: ICMP echo reply, id 2310, seq 1, length 64

20:00:31.404031 fwln102i0 P IP 198.27.92.1 > 164.132.x.y: ICMP echo reply, id 2310, seq 1, length 64

20:00:31.404035 tap102i0 Out IP 198.27.92.1 > 164.132.x.y: ICMP echo reply, id 2310, seq 1, length 64

Donc la solution du forum ne fonctionne pas. C'est ce que j'avais déjà déterminé sans le tcpdump (donc constat moins sur).

le_sbraz · April 2, 2025, 6:27pm

Merci, la NAT ne semble pas être appliquée du tout lorsque le paquet revient, il rentre dans fwln102i0 avec toujours l'IP 164.132.x.y en destination, elle aurait dû être remplacée par la 192.168.0.102.
Je me demande si le problème n'est pas d'avoir la route vers 164.132.x.y sur Proxmox.

Peut-être faudrait-il que Proxmox porte toutes les IP additionnelles lui-même et que les VM n'en aient pas conscience, quelque chose comme :

- Proxmox porte l'IP du serveur + 164.132.x.y/32 (la ligne "up ip route add 164.132.x.y/32 dev $IFACE" devient "address 164.132.x.y/32")

- Une règle de NAT renvoie le trafic entrant vers la VM : "iptables -t nat -A PREROUTING -d 164.132.x.y -j DNAT --to-destination 192.168.0.102"

- Une autre règle de NAT sert à ce que le trafic sortant soit caché derrière l'IP publique, c'est la règle de nat POSTROUTING que vous avez déjà

- Les VM ne connaissent que le réseau 192.168.0.0/24, on enlève toutes les références aux IP publiques

Il y a des avantages (simplicité côté VM) et des inconvénients (plus de configuration côté Proxmox) à cette configuration. J'essaierai de la mettre en place si j'ai le temps. Ça se rapprocherait assez de ce qu'on fait quand on héberge des choses sur son LAN à la maison derrière un routeur opérateur, avec la subtilité que le routeur porte ici plusieurs IP publiques.

le_sbraz · April 3, 2025, 11:02am

Je confirme que ça fonctionne parfaitement en faisant porter l'IP par l'hyperviseur et en le rendant responsable de la NAT.
J'ai fait les tests sur une machine de gamme SCALE avec de l'agrégation (bond0 contient les deux interfaces publiques) mais le principe reste le même sur les gammes ADV.


Côté VM, on n'a plus que l'IP privée.

root@CT999:~# cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.0.2/24
gateway 192.168.0.1
root@CT999:~# ping -c1 ovh.com
PING ovh.com (198.27.92.1) 56(84) bytes of data.
64 bytes from www.ovh.com (198.27.92.1): icmp_seq=1 ttl=58 time=0.225 ms

--- ovh.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.225/0.225/0.225/0.000 ms

Côté hyperviseur, je n'ai mis que ces deux règles de pare-feu dans la table nat :
root@pve ~ $ iptables-save -t nat | grep ^-A
-A PREROUTING -d 176.31.x/32 -j DNAT --to-destination 192.168.0.2
-A POSTROUTING -s 192.168.0.2/32 -j SNAT --to-source 176.31.x

Et j'ai changé la configuration réseau :
iface vmbr0 inet static
address 135.125.x/32
gateway 100.64.0.1
address 192.168.0.1/24
# Chez vous ça sera ens18 au lieu de bond0
bridge-ports bond0
bridge-stp off
bridge-fd 0
# IP additionnelle ici
address 176.31.x.y/32

Sur un paquet sortant (le ping effectué depuis la VM), on voit bien la SNAT se faire :
root@pve ~ $ tcpdump -ni any host ovh.com
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
10:45:47.223659 veth999i0 P IP 192.168.0.2 > 198.27.92.1: ICMP echo request, id 12381, seq 1, length 64
10:45:47.223659 vmbr0 In IP 192.168.0.2 > 198.27.92.1: ICMP echo request, id 12381, seq 1, length 64
10:45:47.223668 vmbr0 Out IP 176.31.x > 198.27.92.1: ICMP echo request, id 12381, seq 1, length 64
10:45:47.223669 bond0 Out IP 176.31.x > 198.27.92.1: ICMP echo request, id 12381, seq 1, length 64
10:45:47.223670 ens3f0np0 Out IP 176.31.x > 198.27.92.1: ICMP echo request, id 12381, seq 1, length 64
10:45:47.223844 ens3f1np1 In IP 198.27.92.1 > 176.31.x: ICMP echo reply, id 12381, seq 1, length 64
10:45:47.223844 bond0 In IP 198.27.92.1 > 176.31.x: ICMP echo reply, id 12381, seq 1, length 64
10:45:47.223844 vmbr0 In IP 198.27.92.1 > 176.31.x: ICMP echo reply, id 12381, seq 1, length 64
10:45:47.223873 vmbr0 Out IP 198.27.92.1 > 192.168.0.2: ICMP echo reply, id 12381, seq 1, length 64
10:45:47.223877 veth999i0 Out IP 198.27.92.1 > 192.168.0.2: ICMP echo reply, id 12381, seq 1, length 64

Sur un ping entrant, on voit la DNAT :
root@pve ~ $ tcpdump -ni any icmp and host ip.internet
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
10:53:51.621890 ens3f0np0 In IP ip.internet > 176.31.x: ICMP echo request, id 10, seq 1, length 64
10:53:51.621890 bond0 In IP ip.internet > 176.31.x: ICMP echo request, id 10, seq 1, length 64
10:53:51.621890 vmbr0 In IP ip.internet > 176.31.x: ICMP echo request, id 10, seq 1, length 64
10:53:51.621923 vmbr0 Out IP ip.internet > 192.168.0.2: ICMP echo request, id 10, seq 1, length 64
10:53:51.621928 veth999i0 Out IP ip.internet > 192.168.0.2: ICMP echo request, id 10, seq 1, length 64
10:53:51.621949 veth999i0 P IP 192.168.0.2 > ip.internet: ICMP echo reply, id 10, seq 1, length 64
10:53:51.621949 vmbr0 In IP 192.168.0.2 > ip.internet: ICMP echo reply, id 10, seq 1, length 64
10:53:51.621961 vmbr0 Out IP 176.31.x > ip.internet: ICMP echo reply, id 10, seq 1, length 64
10:53:51.621964 bond0 Out IP 176.31.x > ip.internet: ICMP echo reply, id 10, seq 1, length 64
10:53:51.621968 ens3f1np1 Out IP 176.31.x > ip.internet: ICMP echo reply, id 10, seq 1, length 64

le_sbraz · April 3, 2025, 11:05am

Je confirme que ça fonctionne parfaitement en faisant porter l'IP par l'hyperviseur et en le rendant responsable de la NAT.
J'ai fait les tests sur une machine de gamme SCALE avec de l'agrégation (bond0 contient les deux interfaces publiques) mais le principe reste le même sur les gammes ADV.

Côté VM, on n'a plus que l'IP privée.

root@CT999:~# cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.0.2/24
gateway 192.168.0.1
root@CT999:~# ping -c1 ovh.com
PING ovh.com (198.27.92.1) 56(84) bytes of data.
64 bytes from www.ovh.com (198.27.92.1): icmp_seq=1 ttl=58 time=0.225 ms

--- ovh.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.225/0.225/0.225/0.000 ms

Côté hyperviseur, je n'ai mis que ces deux règles de pare-feu dans la table nat :
root@pve ~ $ iptables-save -t nat | grep ^-A
-A PREROUTING -d 176.31.x/32 -j DNAT --to-destination 192.168.0.2
-A POSTROUTING -s 192.168.0.2/32 -j SNAT --to-source 176.31.x

Et j'ai changé la configuration réseau :
iface vmbr0 inet static
address 135.125.x/32
gateway 100.64.0.1
address 192.168.0.1/24
# Chez vous ça sera ens18 au lieu de bond0
bridge-ports bond0
bridge-stp off
bridge-fd 0
# IP additionnelle ici
address 176.31.x.y/32

Sur un paquet sortant (le ping effectué depuis la VM), on voit bien la SNAT se faire :
root@pve ~ $ tcpdump -ni any host ovh.com
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
10:45:47.223659 veth999i0 P IP 192.168.0.2 > 198.27.92.1: ICMP echo request, id 12381, seq 1, length 64
10:45:47.223659 vmbr0 In IP 192.168.0.2 > 198.27.92.1: ICMP echo request, id 12381, seq 1, length 64
10:45:47.223668 vmbr0 Out IP 176.31.x > 198.27.92.1: ICMP echo request, id 12381, seq 1, length 64
10:45:47.223669 bond0 Out IP 176.31.x > 198.27.92.1: ICMP echo request, id 12381, seq 1, length 64
10:45:47.223670 ens3f0np0 Out IP 176.31.x > 198.27.92.1: ICMP echo request, id 12381, seq 1, length 64
10:45:47.223844 ens3f1np1 In IP 198.27.92.1 > 176.31.x: ICMP echo reply, id 12381, seq 1, length 64
10:45:47.223844 bond0 In IP 198.27.92.1 > 176.31.x: ICMP echo reply, id 12381, seq 1, length 64
10:45:47.223844 vmbr0 In IP 198.27.92.1 > 176.31.x: ICMP echo reply, id 12381, seq 1, length 64
10:45:47.223873 vmbr0 Out IP 198.27.92.1 > 192.168.0.2: ICMP echo reply, id 12381, seq 1, length 64
10:45:47.223877 veth999i0 Out IP 198.27.92.1 > 192.168.0.2: ICMP echo reply, id 12381, seq 1, length 64

Sur un ping entrant, on voit la DNAT :
root@pve ~ $ tcpdump -ni any icmp and host ip.internet
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
10:53:51.621890 ens3f0np0 In IP ip.internet > 176.31.x: ICMP echo request, id 10, seq 1, length 64
10:53:51.621890 bond0 In IP ip.internet > 176.31.x: ICMP echo request, id 10, seq 1, length 64
10:53:51.621890 vmbr0 In IP ip.internet > 176.31.x: ICMP echo request, id 10, seq 1, length 64
10:53:51.621923 vmbr0 Out IP ip.internet > 192.168.0.2: ICMP echo request, id 10, seq 1, length 64
10:53:51.621928 veth999i0 Out IP ip.internet > 192.168.0.2: ICMP echo request, id 10, seq 1, length 64
10:53:51.621949 veth999i0 P IP 192.168.0.2 > ip.internet: ICMP echo reply, id 10, seq 1, length 64
10:53:51.621949 vmbr0 In IP 192.168.0.2 > ip.internet: ICMP echo reply, id 10, seq 1, length 64
10:53:51.621961 vmbr0 Out IP 176.31.x > ip.internet: ICMP echo reply, id 10, seq 1, length 64
10:53:51.621964 bond0 Out IP 176.31.x > ip.internet: ICMP echo reply, id 10, seq 1, length 64
10:53:51.621968 ens3f1np1 Out IP 176.31.x > ip.internet: ICMP echo reply, id 10, seq 1, length 64

le_sbraz · April 3, 2025, 11:05am

Je confirme que ça fonctionne parfaitement en faisant porter l'IP par l'hyperviseur et en le rendant responsable de la NAT.
J'ai fait les tests sur une machine de gamme SCALE avec de l'agrégation (bond0 contient les deux interfaces publiques) mais le principe reste le même sur les gammes ADV.

Côté VM, on n'a plus que l'IP privée.

root@CT999:~# cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.0.2/24
gateway 192.168.0.1
root@CT999:~# ping -c1 ovh.com
PING ovh.com (198.27.92.1) 56(84) bytes of data.
64 bytes from www.ovh.com (198.27.92.1): icmp_seq=1 ttl=58 time=0.225 ms

--- ovh.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.225/0.225/0.225/0.000 ms

Côté hyperviseur, je n'ai mis que ces deux règles de pare-feu dans la table nat :
root@pve ~ $ iptables-save -t nat | grep ^-A
-A PREROUTING -d 176.31.x/32 -j DNAT --to-destination 192.168.0.2
-A POSTROUTING -s 192.168.0.2/32 -j SNAT --to-source 176.31.x

Et j'ai changé la configuration réseau :
iface vmbr0 inet static
address 135.125.x/32
gateway 100.64.0.1
address 192.168.0.1/24
# Chez vous ça sera ens18 au lieu de bond0
bridge-ports bond0
bridge-stp off
bridge-fd 0
# IP additionnelle ici
address 176.31.x.y/32

Sur un paquet sortant (le ping effectué depuis la VM), on voit bien la SNAT se faire :
root@pve ~ $ tcpdump -ni any host ovh.com
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
10:45:47.223659 veth999i0 P IP 192.168.0.2 > 198.27.92.1: ICMP echo request, id 12381, seq 1, length 64
10:45:47.223659 vmbr0 In IP 192.168.0.2 > 198.27.92.1: ICMP echo request, id 12381, seq 1, length 64
10:45:47.223668 vmbr0 Out IP 176.31.x > 198.27.92.1: ICMP echo request, id 12381, seq 1, length 64
10:45:47.223669 bond0 Out IP 176.31.x > 198.27.92.1: ICMP echo request, id 12381, seq 1, length 64
10:45:47.223670 ens3f0np0 Out IP 176.31.x > 198.27.92.1: ICMP echo request, id 12381, seq 1, length 64
10:45:47.223844 ens3f1np1 In IP 198.27.92.1 > 176.31.x: ICMP echo reply, id 12381, seq 1, length 64
10:45:47.223844 bond0 In IP 198.27.92.1 > 176.31.x: ICMP echo reply, id 12381, seq 1, length 64
10:45:47.223844 vmbr0 In IP 198.27.92.1 > 176.31.x: ICMP echo reply, id 12381, seq 1, length 64
10:45:47.223873 vmbr0 Out IP 198.27.92.1 > 192.168.0.2: ICMP echo reply, id 12381, seq 1, length 64
10:45:47.223877 veth999i0 Out IP 198.27.92.1 > 192.168.0.2: ICMP echo reply, id 12381, seq 1, length 64

Sur un ping entrant, on voit la DNAT :
root@pve ~ $ tcpdump -ni any icmp and host ip.internet
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
10:53:51.621890 ens3f0np0 In IP ip.internet > 176.31.x: ICMP echo request, id 10, seq 1, length 64
10:53:51.621890 bond0 In IP ip.internet > 176.31.x: ICMP echo request, id 10, seq 1, length 64
10:53:51.621890 vmbr0 In IP ip.internet > 176.31.x: ICMP echo request, id 10, seq 1, length 64
10:53:51.621923 vmbr0 Out IP ip.internet > 192.168.0.2: ICMP echo request, id 10, seq 1, length 64
10:53:51.621928 veth999i0 Out IP ip.internet > 192.168.0.2: ICMP echo request, id 10, seq 1, length 64
10:53:51.621949 veth999i0 P IP 192.168.0.2 > ip.internet: ICMP echo reply, id 10, seq 1, length 64
10:53:51.621949 vmbr0 In IP 192.168.0.2 > ip.internet: ICMP echo reply, id 10, seq 1, length 64
10:53:51.621961 vmbr0 Out IP 176.31.x > ip.internet: ICMP echo reply, id 10, seq 1, length 64
10:53:51.621964 bond0 Out IP 176.31.x > ip.internet: ICMP echo reply, id 10, seq 1, length 64
10:53:51.621968 ens3f1np1 Out IP 176.31.x > ip.internet: ICMP echo reply, id 10, seq 1, length 64

MickaelG12 · April 3, 2025, 11:12am

çà semble pas mal tout çà

Peux tu me donner la config Proxmox et VM type ?
Merci

le_sbraz · April 3, 2025, 11:17am

J'ai mis un extrait de /etc/network/interfaces de l'hôte (j'ai d'autres interfaces dedans, je ne voulais pas polluer). Et tu as l'intégralité de la conf de la VM, c'est juste l'IP privée. Est-ce qu'il te manque des informations ?
En gros :

l'hyperviseur porte l'IP publique du serveur mais aussi les IP additionnelles, ainsi qu'une IP dans un réseau privé 192.168.0.1/24
l'hyperviseur a deux règles de NAT par IP additionnelle : une DNAT pour l'entrant et une SNAT pour le sortant (tu as les règles iptables dans mon post précédent)
la VM ne porte que 192.168.0.2/24 et a comme passerelle la 192.168.0.1

MickaelG12 · April 3, 2025, 4:40pm

Malheureusement ça ne fonctionne pas sur ADVANCED.

Ma config Proxmox :
auto vmbr0
iface vmbr0 inet static
address 91.134.a.b/32
gateway 100.64.0.1
address 192.168.0.1/24
bridge-ports enp10s0f0np0
bridge-stp off
bridge-fd 0
address 164.132.x.y/32
up iptables -t nat -A PREROUTING -d 164.132.x.y/32 -j DNAT --to-destination 192.168.0.102
up iptables -t nat -A POSTROUTING -s 192.168.0.102/32 -j SNAT --to-source 164.132.x.y

Ma config VM :
iface ens18 inet static address 192.168.0.102/24 gateway 192.168.0.1

J'ai ajouté dans sysctl.conf :
net.ipv4.ip_forward = 1
net.ipv6.conf.default.forwarding=1
net.ipv6.conf.all.forwarding=1
net.ipv6.conf.default.proxy_ndp=1
net.ipv6.conf.all.proxy_ndp=1

Proxmox ping vers la VM.
La VM ne ping pas vers Proxmox et n'accède pas à Internet.

Sur Proxmox, "tcpdump -ni any host 192.168.0.1" renvoie ça quand je ping depuis la VM :
18:29:10.399482 tap102i0 P IP 192.168.0.102 > 192.168.0.1: ICMP echo request, id 533, seq 1, length 64
18:29:10.399506 fwln102i0 Out IP 164.132.x.y > 192.168.0.1: ICMP echo request, id 533, seq 1, length 64
18:29:10.399509 fwpr102p0 P IP 164.132.x.y > 192.168.0.1: ICMP echo request, id 533, seq 1, length 64
18:29:10.399512 vmbr0 In IP 164.132.x.y > 192.168.0.1: ICMP echo request, id 0, seq 1, length 64

Et toujours sur Proxmox, "tcpdump -ni any host 198.27.92.1" renvoie ça quand je ping depuis la VM :
18:29:48.527822 tap102i0 P IP 192.168.0.102 > 198.27.92.1: ICMP echo request, id 534, seq 1, length 64
18:29:48.527837 fwln102i0 Out IP 164.132.x.y > 198.27.92.1: ICMP echo request, id 534, seq 1, length 64
18:29:48.527840 fwpr102p0 P IP 164.132.x.y > 198.27.92.1: ICMP echo request, id 534, seq 1, length 64
18:29:48.527843 vmbr0 In IP 164.132.x.y > 198.27.92.1: ICMP echo request, id 0, seq 1, length 64

Je suis à court d'idées.

le_sbraz · April 3, 2025, 5:29pm

Je viens de faire la conf sur un ADV :

Proxmox :
auto lo
iface lo inet loopback

auto vmbr0
iface vmbr0 inet static
address 91.134.x/32
gateway 100.64.0.1
address 192.168.0.1/24
bridge-ports enp8s0f0np0
bridge-stp off
bridge-fd 0
address 178.32.x/32
up iptables -t nat -A PREROUTING -d 178.32.x/32 -j DNAT --to-destination 192.168.0.2
up iptables -t nat -A POSTROUTING -s 192.168.0.2/32 -j SNAT --to-source 178.32.x

VM :
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.0.2/24
gateway 192.168.0.1

Avec net.ipv4.ip_forward=0, le ping VM → Internet ne passe pas, ça ressemble à ton problème (mais ça n'explique pas le VM → Proxmox KO) :
root@ns ~ $ tcpdump -ni any host 198.27.92.1
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
17:18:27.759552 veth999i0 P IP 192.168.0.2 > 198.27.92.1: ICMP echo request, id 20909, seq 1, length 64
17:18:27.759552 vmbr0 In IP 192.168.0.2 > 198.27.92.1: ICMP echo request, id 20909, seq 1, length 64

Avec net.ipv4.ip_forward=1, il passe :
root@ns ~ $ tcpdump -ni any host 198.27.92.1
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
17:19:22.731921 veth999i0 P IP 192.168.0.2 > 198.27.92.1: ICMP echo request, id 54128, seq 1, length 64
17:19:22.731921 vmbr0 In IP 192.168.0.2 > 198.27.92.1: ICMP echo request, id 54128, seq 1, length 64
17:19:22.731941 vmbr0 Out IP 178.32.x > 198.27.92.1: ICMP echo request, id 54128, seq 1, length 64
17:19:22.731943 enp8s0f0np0 Out IP 178.32.x > 198.27.92.1: ICMP echo request, id 54128, seq 1, length 64
17:19:22.732209 enp8s0f0np0 In IP 198.27.92.1 > 178.32.x: ICMP echo reply, id 54128, seq 1, length 64
17:19:22.732209 vmbr0 In IP 198.27.92.1 > 178.32.x: ICMP echo reply, id 54128, seq 1, length 64
17:19:22.732215 vmbr0 Out IP 198.27.92.1 > 192.168.0.2: ICMP echo reply, id 54128, seq 1, length 64
17:19:22.732217 veth999i0 Out IP 198.27.92.1 > 192.168.0.2: ICMP echo reply, id 54128, seq 1, length 64

Tu dis que la VM ne pinge pas vers Proxmox alors que Proxmox pinge vers la VM, c'est étonnant. L'interface de la VM est dans le bon bridge ?
Sur la VM, "ip n" montre la GW en REACHABLE ? Est-ce que le sysctl est bien appliqué ? "sysctl net.ipv4.ip_forward" le montre bien à 1 ?
Tu n'as pas de règle de pare-feu sur Proxmox qui pourrait bloquer les paquets en INPUT ou FORWARD ?

Je pense que la première chose à comprendre est pourquoi le ping dans le réseau en 192.168.0.0/24 est cassé.

MickaelG12 · April 10, 2025, 9:41am

@le_sbraz

Reprenons après une brêve pause...

Tu vas rire, j'avais configuré "net.ipv4.ip_forward=1" sur Proxmox à la place de la VM, comme c'est à faire sur la configuration provenant de la documentation OVH pour les serveurs Advance.

Donc depuis plus d'une semaine, tu m'avais donné la bonne config mais j'avais mal interprété vis à vis des différentes configurations à faire.

L'option "Firewall" de Proxmox sur le Hardware "Network Device" de la VM a son importance aussi. Le ping ne fonctionne que s'il est désactivé. Je vais chercher la règle de Firewall qui va bien pour ne permettre le ping entrant que depuis une Whitelist et autoriser tout ping sortant.

MickaelG12 · April 10, 2025, 10:12am

As tu une solution pour que je puisse continuer à utiliser le Firewall de Proxmox (utilisation de security group et ip set) ?

le_sbraz · April 10, 2025, 10:26am

net.ipv4.ip_forward=1 doit bien être actif sur Proxmox et sur la VM. Les deux font du routage de paquets. Côté VM, Docker doit l'activer automatiquement car, sur la mienne, c'était actif (je n'ai pas vérifié avant installation du paquet docker.io par contre).

Pour le Firewall de Proxmox, je n'ai pas du tout creusé la question, je viens de faire quelques recherches et je trouve des gens qui mettent les règles en post-up dans /etc/network/interfaces : https://pve.proxmox.com/wiki/Network_Configuration#sysadmin_network_masquerading

Je ne sais pas à quel point ça risque de rentrer en conflit avec les autres règles. Il faudrait que tu cherches dans iptables-save ce qui peut bloquer le ping.