Bonjour à toutes et à tous,
J'utilise un nouveau serveur Advance-2 pour lequel il n'est plus possible d'obtenir d'adresse MAC virtuel sur les Additional IP (à priori la généralisation est à venir pour fin 2014).
Je rencontre la problématique suivante : impossible pour le VM Windows d'accéder à Internet alors que je ne rencontre pas le problème pour les VM Linux en ayant suivi ce guide
https://github.com/ovh/docs/blob/9d2fa8f70ad08ec22df0228c41c81874c87e3acb/pages/bare_metal_cloud/dedicated_servers/proxmox-network-HG-Scale/guide.fr-fr.md
Rien y est décrit pour la configuration des guest Windows.
Toutefois à noter qu'en déclarant 2 IPs sur Windows (IP local 192.168.0.xxx et l'Additional IP 46.105.xxx.xxx) j'arrive à accéder au service RDP, par exemple, depuis l'extérieur (réseau public vers VM).
Est ce que quelqu'un peut m'aider pour résoudre mon problème d'accès IN vers OUT ?
Merci
Bonjour,
Si vous faites tourner un ping depuis la VM Windows et un `tcpdump -ni any host ` sur l'hôte Proxmox, est-ce que vous voyez les paquets sortir sur la patte publique avec comme IP source 192.168.0.x ? Si oui, c'est probablement ce qui pose problème.
Dans la documentation, nous mettons deux IP aux VM : une dans le réseau privé et l'autre qui est l'additional IP.
Sous Linux, pour que les paquets à destination d'Internet sortent avec l'additional IP en source au lieu de l'IP privée, on utilise l'option `src` de `ip route`. Vous pouvez essayer d'activer l'option `SkipAsSource` sur l'IP privée, mais je n'ai pas testé.
C'est exactement ça.
Avec un ping initié depuis la VM Windows :
15:08:22.311852 tap102i0 In IP 192.168.0.4 > 8.8.8.8: ICMP echo request, id 1, seq 5, length 40
15:08:22.311852 vmbr0 In IP 192.168.0.4 > 8.8.8.8: ICMP echo request, id 1, seq 5, length 40
15:08:22.311859 enp10s0f0np0 Out IP 192.168.0.4 > 8.8.8.8: ICMP echo request, id 1, seq 5, length 40
Avec un ping initié depuis la VM Linux :
15:10:28.177193 tap100i0 In IP 46.105.xxx.xxx > 8.8.8.8: ICMP echo request, id 50343, seq 3, length 64
15:10:28.177193 vmbr0 In IP 46.105.xxx.xxx > 8.8.8.8: ICMP echo request, id 50343, seq 3, length 64
15:10:28.177211 enp10s0f0np0 Out IP 46.105.xxx.xxx > 8.8.8.8: ICMP echo request, id 50343, seq 3, length 64
15:10:28.182170 enp10s0f0np0 In IP 8.8.8.8 > 46.105.xxx.xxx: ICMP echo reply, id 50343, seq 3, length 64
15:10:28.182183 vmbr0 Out IP 8.8.8.8 > 46.105.xxx.xxx: ICMP echo reply, id 50343, seq 3, length 64
15:10:28.182189 tap100i0 Out IP 8.8.8.8 > 46.105.xxx.xxx: ICMP echo reply, id 50343, seq 3, length 64
Donc l'IP source fournie par Windows dans les paquets est 192.168.0.4 au lieu de 46.105.xxx.xxx
La configuration Linux ayant été réalisée comme l'indique le guide avec un remplacement de la route par défaut :
iface ens18 inet static
address 46.105.xxx.xxx/32
up ip route replace default via 192.168.0.1 dev $IFACE onlink src 46.105.xxx.xxxx
Comment faire la même chose sur une VM Windows ?
@le_sbraz merci pour la piste de l'option SkipAsSource
En effet avec la commande Powershell :
`Get-NetIPAddress 192.168.0.4 | Set-NetIPAddress -SkipAsSource $True`
Le ping fonctionne et l'accès Internet aussi, bien évidemment.
Encore merci infiniment
PS : Je pense que je ne suis pas encore au bout de mes surprises dans mon apprentissage au remplacement d'ESXi par Proxmox
Le ping fonctionne et l'accès Internet aussi, bien évidemment.
Merci pour le retour :)
Que se passe-t-il pour le trafic vers le réseau privé, par exemple 192.168.0.1 ou 192.168.0.2 depuis la machine Windows ? Est-ce que ça fonctionne comme attendu avec des paquets ayant comme source la 192.168.0.4 (ce qui fonctionne bien sous Linux) ? Ou bien ça envoie des paquets avec comme source l'IP publique `46.105.*` ?
En effet un ping vers 192.168.0.1 (proxmox) depuis la VM Windows (IP privée 192.168.0.4) donne comme source de paquet 46.105.xxx.xxx, soit l'Additional IP configurée sur la VM Windows.
Le même test de ping vers 192.168.0.1 depuis un VM Linux (IP privée 192.168.0.2) donne comme source de paquet 192.168.0.2, c'est mieux.
Y a t'il une solution pour obtenir le même comportement sous Windows ?
J'ai un peu creusé et je ne trouve pas vraiment de solution. Sinon, il faut laisser tout le trafic venir de l'IP en 192.168.0.0/24 et faire une règle de SNAT sur Proxmox au moment où les paquets sortent vers Internet.<br />J'ai testé sur une VM Linux portant une IP 192.168.0.2 et une IP additionnelle :<br />```text<br />$ ip -br -4 a<br />lo UNKNOWN 127.0.0.1/8 <br />eth0@if13 UP aa.bb.cc.dd/32 192.168.0.2/24 <br /># j'enlève volontairement l'option "src"<br />$ ip ro replace default via 192.168.0.1 dev eth0<br />$ ping -c1 ovh.com<br />PING ovh.com (198.27.92.1) 56(84) bytes of data.<br />64 bytes from www.ovh.com (198.27.92.1): icmp_seq=1 ttl=58 time=0.204 ms<br /><br />--- ovh.com ping statistics ---<br />1 packets transmitted, 1 received, 0% packet loss, time 0ms<br />rtt min/avg/max/mdev = 0.204/0.204/0.204/0.000 ms<br />```<br /><br />Sur Proxmox j'ai fait :<br />```text<br />$ iptables -t nat -A POSTROUTING -s 192.168.0.2/32 -o enp8s0f0np0 -j SNAT --to-source aa.bb.cc.dd<br />```<br /><br />On voit que le trafic arrive sur le bridge avec une IP source privée puis il est SNATé lors de la sortie sur la patte publique :<br />```text<br />$ tcpdump -ni any icmp and host ovh.com<br />tcpdump: data link type LINUX_SLL2<br />tcpdump: verbose output suppressed, use -v[v]... for full protocol decode<br />listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes<br />16:14:36.819338 veth999i0 P IP 192.168.0.2 > 198.27.92.1: ICMP echo request, id 54733, seq 1, length 64<br />16:14:36.819340 fwln999i0 Out IP 192.168.0.2 > 198.27.92.1: ICMP echo request, id 54733, seq 1, length 64<br />16:14:36.819341 fwpr999p0 P IP 192.168.0.2 > 198.27.92.1: ICMP echo request, id 54733, seq 1, length 64<br />16:14:36.819341 vmbr0 In IP 192.168.0.2 > 198.27.92.1: ICMP echo request, id 54733, seq 1, length 64<br />16:14:36.819350 enp8s0f0np0 Out IP aa.bb.cc.dd > 198.27.92.1: ICMP echo request, id 54733, seq 1, length 64<br />16:14:36.819523 enp8s0f0np0 In IP 198.27.92.1 > aa.bb.cc.dd: ICMP echo reply, id 54733, seq 1, length 64<br />16:14:36.819528 vmbr0 Out IP 198.27.92.1 > 192.168.0.2: ICMP echo reply, id 54733, seq 1, length 64<br />16:14:36.819531 fwpr999p0 Out IP 198.27.92.1 > 192.168.0.2: ICMP echo reply, id 54733, seq 1, length 64<br />16:14:36.819531 fwln999i0 P IP 198.27.92.1 > 192.168.0.2: ICMP echo reply, id 54733, seq 1, length 64<br />16:14:36.819534 veth999i0 Out IP 198.27.92.1 > 192.168.0.2: ICMP echo reply, id 54733, seq 1, length 64<br />```<br /><br />EDIT : sinon, il faut dédier une interface des VM aux IP publiques et une aux IP privées. Il doit être possible de faire un setup dans ce genre-là mais je n'ai pas testé.
Pour le moment, la configuration obtenue me convient.
Comme mes VM Linux exploitent des services Web hébergés sous VM Windows nécessitant le SNI, je n'utiliserais pas le réseau privé entre des VM d'OS différent.
Un détail un peu pénible, c'est qu'à chaque redémarrage d'une VM Windows Server, Windows génère un nouveau réseau qu'il attache à l'interface qui ne change pas.
Si quelqu'un à une idée sur le sujet ?
En tout cas je vous remercie @le_sbraz
J'ai trouvé la solution au problème des VM Windows qui recréent systématiquement un réseau à chaque démarrage : il faut configurer une adresse MAC au bridge Linux vmbr0 (en utilisant le même préfixe que celui des VM de préférence, dans mon cas bc:24:11:xx:xx:xx)
La modification du fichier `/etc/network/interfaces` :
> auto vmbr0
> iface vmbr0 inet static
> address xxx.xxx.xxx.xxx/24
> bridge-ports none
> bridge-stp off
> bridge-fd 0
> bridge-disable-mac-learning 1
> hwaddress ether bc:24:11:xx:xx:xx
Encore un problème en moins…
Bien que ce fil soit assez ancien, je voulais remercier chaleureusement MickaelG12 et le_sbraz pour ces précieuses informations, ça faisait un moment que je tournais en rond avec exactement le même problème.
Il serait bon d'ajouter ces infos pour les VM Windows aux différentes docs OVH qui ne semblent traiter que du cas des VM Linux.