# Problème réseau avec xen/bridge **URL:** \ **Category:** Support Debian\ **Created:** [Mars 29, 2018, 4:41 UTC](https://www.debian-fr.org/t/probleme-reseau-avec-xen-bridge/76273 "2018-03-29T16:41:32Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![mazarini](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/m/6f9a4e/32.png) [@mazarini](https://www.debian-fr.org/u/mazarini)\ **Post date:** [Mars 29, 2018, 4:41 UTC](https://www.debian-fr.org/t/probleme-reseau-avec-xen-bridge/76273/1 "2018-03-29T16:41:32Z")
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. ---
**Author:** ![Clochette](https://www.debian-fr.org/user_avatar/www.debian-fr.org/clochette/32/8757_2.png) [@Clochette](https://www.debian-fr.org/u/Clochette)\ **Post date:** [Mars 29, 2018, 5:57 UTC](https://www.debian-fr.org/t/probleme-reseau-avec-xen-bridge/76273/2 "2018-03-29T17:57:18Z")
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. ---
**Author:** ![mazarini](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/m/6f9a4e/32.png) [@mazarini](https://www.debian-fr.org/u/mazarini)\ **Post date:** [Mars 29, 2018, 6:31 UTC](https://www.debian-fr.org/t/probleme-reseau-avec-xen-bridge/76273/3 "2018-03-29T18:31:28Z")
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 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 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 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) ---
**Author:** ![mazarini](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/m/6f9a4e/32.png) [@mazarini](https://www.debian-fr.org/u/mazarini)\ **Post date:** [Mars 29, 2018, 7:28 UTC](https://www.debian-fr.org/t/probleme-reseau-avec-xen-bridge/76273/4 "2018-03-29T19:28:26Z")
2 jours de galère pour avoir oublié : `net.ipv4.conf.enp0s20f0.proxy_arp=1` ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Mars 30, 2018, 8:44 UTC](https://www.debian-fr.org/t/probleme-reseau-avec-xen-bridge/76273/5 "2018-03-30T08:44:11Z")
La nécessité d’activer le proxy ARP signifie qu’on a fait du routage de merde. ---
**Author:** ![mazarini](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/m/6f9a4e/32.png) [@mazarini](https://www.debian-fr.org/u/mazarini)\ **Post date:** [Mars 31, 2018, 1:50 UTC](https://www.debian-fr.org/t/probleme-reseau-avec-xen-bridge/76273/6 "2018-03-31T13:50:08Z")
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. ---
**Author:** ![anon36725218](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/8e8cbc/32.png) [@anon36725218](https://www.debian-fr.org/u/anon36725218)\ **Post date:** [Mars 31, 2018, 2:08 UTC](https://www.debian-fr.org/t/probleme-reseau-avec-xen-bridge/76273/7 "2018-03-31T14:08:19Z")
> [@mazarini](#): > > Je ne souhaite pas qu’une vm ait un accès direct à l’extérieur ni faire de nat. 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 ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Mars 31, 2018, 9:59 UTC](https://www.debian-fr.org/t/probleme-reseau-avec-xen-bridge/76273/8 "2018-03-31T21:59:10Z")
> [@mazarini](#): > > routage d’une adresse IP public sur le bridge C’est-à-dire ? > [@mazarini](#): > > ajout de l’adresse public sur l’interface de la VM (eth1 ou eth0:1) 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) ? ---
**Author:** ![mazarini](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/m/6f9a4e/32.png) [@mazarini](https://www.debian-fr.org/u/mazarini)\ **Post date:** [Avril 1, 2018, 1:24 UTC](https://www.debian-fr.org/t/probleme-reseau-avec-xen-bridge/76273/9 "2018-04-01T13:24:25Z")
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. ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Avril 1, 2018, 3:57 UTC](https://www.debian-fr.org/t/probleme-reseau-avec-xen-bridge/76273/10 "2018-04-01T15:57:14Z")
> [@mazarini](#): > > A priori ca doit être “/sbin/ip route add 212.83.130.31 via 10.1.10.254” qui n’est pas propre 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. > [@mazarini](#): > > 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 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. ---
**Author:** ![mazarini](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/m/6f9a4e/32.png) [@mazarini](https://www.debian-fr.org/u/mazarini)\ **Post date:** [Avril 1, 2018, 9:14 UTC](https://www.debian-fr.org/t/probleme-reseau-avec-xen-bridge/76273/11 "2018-04-01T21:14:35Z")
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. ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Avril 2, 2018, 8:26 UTC](https://www.debian-fr.org/t/probleme-reseau-avec-xen-bridge/76273/12 "2018-04-02T08:26:47Z")
> [@mazarini](#): > > 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. 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 ? > [@mazarini](#): > > 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. 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 ? ---
**Author:** ![Clochette](https://www.debian-fr.org/user_avatar/www.debian-fr.org/clochette/32/8757_2.png) [@Clochette](https://www.debian-fr.org/u/Clochette)\ **Post date:** [Avril 2, 2018, 8:32 UTC](https://www.debian-fr.org/t/probleme-reseau-avec-xen-bridge/76273/13 "2018-04-02T08:32:27Z")
Il me semble que cela avait été discuté ici même il y a quelques temps déjà : > [@Xen, mode bridge plus Ip Failover... Comment faire ?](https://www.debian-fr.org/t/xen-mode-bridge-plus-ip-failover-comment-faire/55824/2): > > D’abord je veux faire une mise au point : arrêtez de parler d’IP failover à tort et à travers ! Ce n’est pas parce que l’hébergeur ou le FAI appelle ça “failover” que c’en est. Le failover, c’est une fonctionnalité pour faire de la redondance entre deux machines ou plus. Ici comme dans la plupart des cas, cette adresse IP supplémentaire sert pour une tout autre fonction qui n’a strictement rien à voir avec le failover. > > Je suppose que cette adresse IP supplémentaire est routée directement sur le réseau local sur lequel est connecté l’interface eth0 du dom0, mais c’est à vérifier. Dans ce cas, je vois trois solutions : une propre, une moins propre et une pas propre du tout. > > La propre : un second pont entre eth0 du dom0 et une interface virtuelle du domU concerné (qui peut être en plus de l’interface connectée au pont local des autres domU) > > La moins propre : annoncer l’adresse supplémentaire par proxy ARP sur le dom0, et la router sur le domU concerné via une paire d’interfaces virtuelles (pas besoin de pont) > > La pas propre du tout : affecter l’adresse supplémentaire au dom0 et faire du NAT source et destination depuis et vers l’adresse privée du domU concerné. > > Si au contraire l’adresse IP supplémentaire est routée via l’adresse principale de ton dom0, alors c’est simple : il suffit de la configurer sur le domU et de créer la route correspondante sur le dom0. > > PS : Curiosité de ma part, à quoi sert l’interface dummy et pourquoi lui attribuer une adresse MAC particulière ? 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 ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Avril 2, 2018, 9:04 UTC](https://www.debian-fr.org/t/probleme-reseau-avec-xen-bridge/76273/14 "2018-04-02T09:04:05Z")
@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. > [@Clochette](#): > > 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 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… ---
**Author:** ![Clochette](https://www.debian-fr.org/user_avatar/www.debian-fr.org/clochette/32/8757_2.png) [@Clochette](https://www.debian-fr.org/u/Clochette)\ **Post date:** [Avril 2, 2018, 9:18 UTC](https://www.debian-fr.org/t/probleme-reseau-avec-xen-bridge/76273/15 "2018-04-02T09:18:18Z")
> [@PascalHambourg](#): > > > [@Clochette](#): > > > > 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. > > 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… Effectivement il faudra bien un bridge 😛 toute mes confuses 😕 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](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. ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Avril 2, 2018, 9:42 UTC](https://www.debian-fr.org/t/probleme-reseau-avec-xen-bridge/76273/16 "2018-04-02T09:42:11Z")
> [@Clochette](#): > > Le désavantage du direct routing c’est que la communication avec les domU public se fera par l’IP pubique du dom0 Je ne suis pas sûr de comprendre, que désignes-tu par « direct routing » ? ---
**Author:** ![Clochette](https://www.debian-fr.org/user_avatar/www.debian-fr.org/clochette/32/8757_2.png) [@Clochette](https://www.debian-fr.org/u/Clochette)\ **Post date:** [Avril 2, 2018, 2:38 UTC](https://www.debian-fr.org/t/probleme-reseau-avec-xen-bridge/76273/17 "2018-04-02T14:38:52Z")
> [@PascalHambourg](#): > > Je ne suis pas sûr de comprendre, que désignes-tu par “direct routing” ? 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. ---
**Author:** ![mazarini](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/m/6f9a4e/32.png) [@mazarini](https://www.debian-fr.org/u/mazarini)\ **Post date:** [Avril 2, 2018, 8:22 UTC](https://www.debian-fr.org/t/probleme-reseau-avec-xen-bridge/76273/18 "2018-04-02T20:22:50Z")
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. ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Avril 2, 2018, 10:13 UTC](https://www.debian-fr.org/t/probleme-reseau-avec-xen-bridge/76273/19 "2018-04-02T22:13:56Z")
> [@Clochette](#): > > 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. Je ne vois pas de quoi tu parles. Quel genre de règle de PREROUTING ? > [@Clochette](#): > > De ce fait les paquets devront systématiquement passer par l’IP publique de l’hôte. 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. ---
**Author:** ![Clochette](https://www.debian-fr.org/user_avatar/www.debian-fr.org/clochette/32/8757_2.png) [@Clochette](https://www.debian-fr.org/u/Clochette)\ **Post date:** [Avril 3, 2018, 10:41 UTC](https://www.debian-fr.org/t/probleme-reseau-avec-xen-bridge/76273/20 "2018-04-03T10:41:04Z")
> [@mazarini](#): > > dans la doc de l’hébergeur, “net.ipv4.conf.enp0s20f0.proxy\_arp=1” est indiqué comme obligatoire Il indiquent seulement cette façon de faire tirer de la documentation officielle : > **[Vif-route - Xen](https://wiki.xenproject.org/wiki/Vif-route)** Quant à la documentation (du projet xen) sur le network ça donne ça : > **[Xen Networking - Xen](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](https://tr.opensuse.org/Xen3_and_a_Virtual_Network) > [@PascalHambourg](#): > > > [@Clochette](#): > > > > 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 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. 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. > [@PascalHambourg](#): > > > [@Clochette](#): > > > > 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. > > Je ne vois pas de quoi tu parles. Quel genre de règle de PREROUTING ? 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. [Page suivante](https://www.debian-fr.org/t/probleme-reseau-avec-xen-bridge/76273.md?page=2)