Problème réseau avec xen/bridge

Support Debian
#1

Bonjour,

J’ai une machine avec xen installé et plusieures domU. Les domU sont reliées à un bridge sur une interface dummy avec des adresses locales. Une des domU a aussi une adresse public.

Toutes les domU ont un accès à l’extérieur. Depuis la dom0 et les domU, je peux pinguer l’adresse public de la domU. Par contre, depuis l’extérieur, je n’arrive pas à pinguer la domU.

Je n’ai qu’une règle iptables active :
iptables -t nat -A POSTROUTING -s 10.1.0.0/16 -o enp0s20f0 -j MASQUERADE

Une route dirige l’adresse public de la domU sur le bridge.

net.ipv4.ip_forward est à 1

Je ne sais plus quoi vérifier.

#2

Pourrais-tu nous fournir le jeux de règles Iptable ?

Tu as le POSTROUTING mais ne faudrait-il pas du PREROUTING aussi pour permettre d’accéder depuis l’extérieur à ton IP public monté sur ton domU.

#3

Je n’ai pas d’autres règles iptables pour le moment.

Pour le retour, je compte sur :

 root@dom0:~# route -n
Table de routage IP du noyau
Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
0.0.0.0         62.210.0.1      0.0.0.0         UG    0      0        0 enp0s20f0
10.1.0.0        0.0.0.0         255.255.0.0     U     0      0        0 lan0
163.172.28.0    0.0.0.0         255.255.255.0   U     0      0        0 enp0s20f0
212.83.130.31   10.1.10.254     255.255.255.255 UGH   0      0        0 lan0

(j’avais essayé avec 163.172.28.1 comme passerelle)

Et sur la DomU :

root@dom1:~# route -n
Table de routage IP du noyau
Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
0.0.0.0         10.1.10.254     0.0.0.0         UG    0      0        0 eth0
10.1.0.0        0.0.0.0         255.255.0.0     U     0      0        0 eth0
root@dom1:~# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.1.20.1  netmask 255.255.0.0  broadcast 10.1.255.255
        inet6 fe80::216:3eff:fe10:385d  prefixlen 64  scopeid 0x20<link>
        ether 00:16:3e:10:38:5d  txqueuelen 1000  (Ethernet)
        RX packets 69  bytes 8468 (8.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 51  bytes 8085 (7.8 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0:1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 212.83.130.31  netmask 255.255.255.255  broadcast 212.83.130.31
        ether 00:16:3e:10:38:5d  txqueuelen 1000  (Ethernet)

lo: ...

(j’avais essayé avec eth1 également)

#4

2 jours de galère pour avoir oublié :

net.ipv4.conf.enp0s20f0.proxy_arp=1

#5

La nécessité d’activer le proxy ARP signifie qu’on a fait du routage de merde.

#6

Possible, mais que changer ?

Je ne souhaite pas qu’une vm ait un accès direct à l’extérieur ni faire de nat.

Ce que je fais :

  • un bridge sur une interface dummy qui permet un échange entre les VM
  • routage d’une adresse IP public sur le bridge
  • ajout de l’adresse public sur l’interface de la VM (eth1 ou eth0:1)

Je suis preneur d’une solution propre pour faire ca.

#7

Si tu as plusieurs bridges IPv4 il suffit de ne pas activer le POSTROUTING de l’interface/réseau que tu souhaites ne pas faire sortir.

Qund tu bridges tu as généralement eth0 (interface connecté à l’extérieur) que tu transforme en br0 un brigde pour l’exterieur IP_PUBLIC et br1 un brigde pour tes VMs/réseau, br2 pour un autre réseau (LAN ou LOCAL) de PCs ou VMs etc. Ensuite tu assignes simplement par iptables tes POST/PRE-ROUTING NAT (pour de l’IPv4).

Cordalement,
Romain

#8

C’est-à-dire ?

eth0 ou eth1 ? Ce n’est pas la même chose, et cela n’a pas le même effet.

En général, le proxy ARP sert à compenser un routage erroné, typiquement quand une adresse ou un bloc sont directement routés sur un lien alors qu’ils sont en fait sur un autre lien.

Peux-tu décrire la topologie, le plan d’adressage et le plan de routage de ton réseau (en incluant les VM) ?

#9

Sur le host :

  • Une adresse public sur l’interface enp0s20f0 du serveur.
  • Une adresse privé (10.1.10.254) sur un bridge lan0 monté sur sur une interface dummy0
  • nat pour permettre l’accès à l’extérieur (iptables -t nat -A POSTROUTING -s 10.1.0.0/16 -o enp0s20f0 -j MASQUERADE)
  • routage d’une seconde adresse public sur le bridge (/sbin/ip route add 212.83.130.31 via 10.1.10.254)

Sur les vm:

  • une adresse privée (10.1.10.X) sur eth0

En dehors du routage, ca me semble relativement propre jusque là.

Sur une vm accessible depuis l’extérieur :

  • une adresse privée (10.1.10.Y) sur eth0
  • la seconde adresse public sur eth0:1

Lors de tests, j’ai crée 2 vif sur le bridge pour cette vm pour utiliser eth1 au lieu de eth0:1. Mais au final les 2 fonctionnent.

A priori ca doit être “/sbin/ip route add 212.83.130.31 via 10.1.10.254” qui n’est pas propre, mais je n’ai pas trouvé d’autre solution.

J’espère que ces informations seront suffisante.

#10

Une machine ne peut pas être sa propre passerelle, ça n’a pas de sens. Si une destination est joignable directement il suffit de spécifier l’interface de sortie, pas besoin de passerelle. Si tu préfères mettre une adresse de passerelle, il vaut mieux mettre l’adresse privée de la VM qui a cette adresse publique, ce sera plus clair.

Mais je ne pense pas que le problème vient de cette route car elle est locale à la machine hôte et n’a pas d’effet sur le routage par les marchines extérieures qui envoient des paquets à destination de l’adresse publique de la VM. Si elle ne fonctionnait pas, le routage entre les VM ne fonctionnerait pas. Heureusement, Linux est tolérant.

C’est pourquoi je te demandais de décrire tout ton réseau et son routage, pas seulement la machine hôte et ses VM. Notamment : comment sont routées les adresses publiques de tes VM, depuis une machine extérieure (sur le LAN physique et sur internet).

Je sourpçonne que le routage défaillant est au niveau du routeur internet.

On n’a plus besoin d’utiliser les alias ethX:Y pour affecter plusieurs adresses IP a une même interface. On peut les affecter directement à ethX.

#11

Merci.
Je ne connais que ce qui se passe sur mon serveur ; le reste n’est pas de mon ressort.

L’adresse supplémentaire concernée, est affectable à n’importe quel serveur. Lorsqu’elle est affectée à l’interface du serveur, ca marche sans problème. Le problème ne se pose que lorsqu’elle est affectée à l’interface d’une vm.

J’ai routé vers l’interface plutôt que l’ip, même si ca ne change rien pour net.ipv4.conf.enp0s20f0.proxy_arp.

Pour ce qui est d’utiliser eth0 pour plusieurs adresses, ca fonctionne. Un ifconfig ne liste que la première adresse et ca ne me plait pas trop.

#12

Je suppose que les deux adresses IP publiques (affectées à l’interface ethernet de l’hôte et à la machine virtuelle) font partie d’un même bloc qui est routé sur le LAN de la machine hôte ? Affecter une des adresses de ce bloc à une interface non directement connectée à ce LAN est donc une violation du plan d’adressage.

Dans ce cas je ne vois que trois solutions :

  • Ajouter une route pour l’adresse publique vers la machine virtuelle sur la machine hôte et activer le proxy ARP sur l’interface ethernet de la machine hôte comme tu l’as fait (sale).

  • Affecter l’adresse IP publique à la machine hôte et faire du NAT bidirectionnel (SNAT et DNAT) entre cette adresse et l’adresse IP privée de la machine virtuelle cible (encore plus sale).

  • Ponter le LAN extérieur et le réseau des VM pour que la machine virtuelle soit directement connectée au réseau sur lequel le bloc d’adresses publiques est routé. Concrètement, cela signifie inclure l’interface ethernet de la machine hôte dans le pont des machines virtuelles. Mais j’ai cru comprendre que tu ne souhaitais pas cette solution ?

C’est une limitation d’ifconfig, qui est un vieux programme qui ne comprend que les alias. Mais il me semblait que la nouvelle version incluse dans Debian Stretch n’avait pas cette limitation. Quelle est la version de Debian sur la machine virtuelle ?

#13

Il me semble que cela avait été discuté ici même il y a quelques temps déjà :

Pascal avait à l’époque signaler quelques points possibles.

Je rajouterai à ça le fait de pouvoir ajouter une interface à ta VM et lui permettre de bénéficier d’un direct routing en utilisant la passerelle qui devrait s’occuper de cette IP public, ainsi le domU aurait une interface public en direct routing et une interface privé pour communiquer avec les autres domU
Un exemple glané vite fait sur le net, je suis pas persuadé que ce soit la solution la plus propre mais elle existe aussi.

Sinon l’artillerie lourde de bridge, l’un pour un LAN pour les domU et un autre pour tous ce qui serait amener à être public, et tu monte les interfaces de tes domU selon leur particularité réseau sur l’un ou sur l’autre (voir les deux) et tu jour après sur des règles de masquerading

#14

@Clochette, tu as beaucoup plus de mémoire que moi…

@mazarini n’a pas indiqué s’il s’agissait d’un serveur dédié chez un hébergeur, ce qui laisse moins de contrôle sur le routage des adresses publiques.

Sans bridge ? Comment fais-tu ?
Sinon, avec bridge, c’est l’option “propre” à deux ponts public/privé que j’avais mentionnée à l’époque. Je n’y ai pas pensé cette fois-ci. Je me fais vieux…

#15

Effectivement il faudra bien un bridge :stuck_out_tongue: toute mes confuses :confused:

En exemple c’est pas tout jeune donc il faudra prendre soin de comprendre la mécanique et non d’appliqué bêtement

http://blog.info16.fr/index.php?article36/domu-en-mode-nated-et-domu-en-mode-routed-xen-4-sur-opensuse-11-3

Le désavantage du direct routing c’est que la communication avec les domU public se fera par l’IP pubique du dom0, c’est loin d’être propre et oblige donc à possédez un deuxième bridge pour séparer l’activité publique de l’activité privé.

En bref deux bridges semble être la solution la plus propre à mon humble avis.

#16

Je ne suis pas sûr de comprendre, que désignes-tu par “direct routing” ?

#17

De ce que je pense du routage direct, l’IP publique supplémentaire pour le domU devra être routé via une règle de PREROUTING vers le domU à l’image d’un NAT mais sans qu’il n’y est de changement d’IP.
A l’inverse en configuration nat l’IP sera sur l’hôte qui se chargera de translater les paquets de l’IP publique vers l’IP ‘nattée’ du domU.

De ce fait les paquets devront systématiquement (sans deuxième bridge s’occupant de la communication inerne de l’hôte entre domU) passer par l’IP publique de l’hôte.

Je trouve pas ça très pratique de devoir systématiquement faire ressortir un paquet vers l’interface publique de l’hôte pour le renvoyer à l’intérieur vers le domU de destination.

#18

En vrac :

  • je n’utilise que stretch en ce moment
  • c’est un serveur chez un hébergeur
  • les 2 ip ne sont pas dans le même bloc
  • j’utilise une interface dummy pour créer le bridge au boot de la machine physique. Le bridge est le seul fonctionnement de xen que je comprends à peu près. Je comprend le nat mais ca semble à éviter et je bloque sur le routage avec les vif.
  • l’hébergeur déconseille de faire un bridge sur l’interface physique à cause de risque de blocage volontaire de la machine pour des motifs de sécurité lié à l’utilisation d’une adresse MAC virtuelle. J’ai envie d’essayer avec l’adresse mac fourni avec l’ip supplémentaire (grosse hésitation)
  • dans la doc de l’hébergeur, “net.ipv4.conf.enp0s20f0.proxy_arp=1” est indiqué comme obligatoire

Merci pour toutes ces infos que je dois encore digérer.

#19

Je ne vois pas de quoi tu parles. Quel genre de règle de PREROUTING ?

Je comprends encore moins ce que tu veux dire. Dire qu’un paquet passe par une adresse IP n’a pas de sens pour moi. Un paquet a une adresse de destination et passe par une interface.

#20

Il indiquent seulement cette façon de faire tirer de la documentation officielle :

https://wiki.xen.org/wiki/Vif-route

Quant à la documentation (du projet xen) sur le network ça donne ça :

https://wiki.xenproject.org/wiki/Xen_Networking

Et la le principe que j’avais évoqué avec le routage depuis le dom0 à l’image d’une gestion en nat ce sera les règle de routage via Iptable qui permettra de renvoyer les paquets au domU.

https://tr.opensuse.org/Xen3_and_a_Virtual_Network

Abus de langage, je voulais dire que si un paquet du domU doit atteindre un domU qui est rattaché uniquement au bridge qui ne doit techniquement pas pouvoir sortir, le paquet fera un aller retour inutile jusqu’à l’interface publique.

Il doit bien pouvoir rediriger les paquets qui viennent sur eth0 vers la vif de son domU avec IP publique, et si celui-ci est sur le même bridge que les autres domU il va y a voir un souci pour ajouter une même route au deux non ?

Du coup il faudra bien une règles iptables pour renvoyer les paquets vers cette domU si tu ne touche pas ua restant ou inversement ?

C’est pourquoi à mon sens sans mettre ne place de solution à base de vlan il serait sans doute plus sage de monter un deuxième bridge permettant ainsi de séparer sereinement les activités dite publique du privé.

Après je n’utilise plus de Xen mais des Xenserver de plus en cluster orchestré par Cloudstack, du coup la partie réseau est radicalement différente de l’utilisation en simple hôte.