web-dev-qa-db-fra.com

Comment configurer un pont xen?

Je lisais diverses pages sur la manière de configurer le réseau pour xen. Malheureusement, aucun d’entre eux n’a un exemple complet de configuration. Ils montrent clairement à quoi la section xenbr0 devrait ressembler, mais pas comment vous devriez changer l’eth0 après avoir mentionné:

Remarque! La configuration IP du périphérique de pont doit remplacer la configuration IP de l’interface sous-jacente, c’est-à-dire supprimer les paramètres IP de eth0 et les déplacer vers l’interface de pont. eth0 fonctionnera uniquement comme liaison montante physique à partir du pont, il ne peut donc pas y avoir de paramètres IP (L3)!

J'ai essayé de nombreuses configurations qui échouent toutes (après avoir exécuté /etc/init.d/networking restart, il n’ya pas d’accès netowork normal et ne peut pas entrer ou sortir en ssh).

Voici ma configuration actuelle:

auto lo
iface lo inet loopback

auto xenbr0
iface xenbr0 inet static
    bridge_ports eth0
    address 10.0.0.3
    netmask 255.0.0.0
    broadcast 10.255.255.255
    gateway 10.0.0.1

auto eth0
iface eth0 inet manual

C’est peut-être vrai et j’ai juste besoin de mettre en place des règles de transfert iptables? J'ai essayé d'exécuter la commande Sudo iptables -I FORWARD -m physdev --physdev-is-bridged -j ACCEPT mais j'ai reçu un message d'erreur indiquant que --physdev-is-bridged n'était pas une option reconnue.

La sortie de débogage du redémarrage du réseau donne la sortie suivante:

Reconfiguring network interfaces...
Waiting for xenbr0 to get ready (MAXWAIT is 32 seconds).
RTNETLINK answers: No such process
Failed to bring up xenbr0
ssh stop/waiting
ssh start/running, process 3775

J'ai vérifié que xenbr0 existe déjà, car lorsque j'essaie de créer un pont portant ce nom, brctl me dit qu'il ne peut pas en créer car il en existe déjà un.

5
Programster

Finalement, j'ai fini par créer une interface et transférer des paquets dessus avec quelques règles iptables, ce qui semble fonctionner pour moi. Cela n'utilise PAS l'option 'bridge' que tous les tutoriels semblent suggérer, donc je ne sais pas s'il y a un défaut fatal?

auto lo
iface lo inet loopback


auto xenbr0
iface xenbr0 inet static
        bridge_ports none
        address 192.168.2.1
        netmask 255.255.255.0
        network 192.168.2.0
        broadcast 192.168.2.255
        gateway 10.0.0.3


# The primary network interface
auto eth0
iface eth0 inet static
        address 10.0.0.3
        netmask 255.0.0.0
        network 10.0.0.0
        broadcast 10.255.255.255
        gateway 10.0.0.1
        # dns-* options are implemented by the resolvconf package, if installed
        dns-nameservers 8.8.8.8

Vous devez éditer /etc/sysctl.conf et décommenter la ligne suivante:

net.ipv4.ip_forward=1 

Ensuite, vous devez créer un script pour éditer iptables afin de transférer les paquets:

Sudo /sbin/iptables --table nat --append POSTROUTING --out-interface eth0 -j MASQUERADE
Sudo /sbin/iptables --append FORWARD --in-interface xenbr0 -j ACCEPT
return 0

Ensuite, vous devez vous assurer que le script est appelé par le fichier rc.local:

Sudo vi /etc/rc.local

Ajoutez la ligne suivante:

/bin/sh <path-to-script-you-just-created-here>

Puis redémarrez pour que tous les paramètres prennent effet.

Comme vous le remarquerez peut-être, je l’ai configuré de sorte que les machines virtuelles utilisent un sous-réseau d’adresses 192.168.2.x, tandis que le réseau extérieur est sur 10.xxx, ce qui est probablement différent de ce que la plupart des gens voudront. Vous devrez donc les éditer. vos propres besoins personnels.


Mise à jour
Plus tard, j'ai réalisé que l'absence de pontage signifiait que je ne pouvais pas accéder à mes machines virtuelles de l'extérieur du réseau (c'est-à-dire que je ne pouvais pas y entrer directement depuis chez moi, ni exécuter un site Web, etc.).

En utilisant une configuration réseau ainsi travaillée:

# The loopback network interface
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual

auto xenbr0
iface xenbr0 inet static
        address 23.29.115.142
        netmask 255.255.255.248
        network 23.29.115.136
        broadcast 23.29.115.143
        gateway 23.29.115.137
        bridge_ports eth0
        bridge_stp off
        bridge_fd 0
        bridge_maxwait 0

(copié d'ici)

Je suppose que ces options de pont supplémentaires ont permis son fonctionnement, ou peut-être l'ordre dans lequel les interfaces ont été répertoriées dans le fichier (eth0 avant le pont cette fois)

3
Programster

Définissez d'abord eth0, sans en configurant une passerelle et une adresse IP. (Sinon, vous obtiendrez des erreurs "RTNETLINK answers: File Exist" lorsque le système tente de créer une route pour l'interface, car le pont tente de créer une route avec la même priorité et la même passerelle et ce n'est pas assez intelligent pour se rendre compte qu'elles ' re identiques de toute façon.)

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual

auto xenbr0
iface xenbr0 inet static
    address 192.168.1.10
    netmask 255.255.255.0
    gateway 192.168.1.1
    bridge_ports eth0
    #allow-hotplug xenbr0 #Uncomment if using vSwitches

Alternativement, votre pont peut utiliser DHCP:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual

auto xenbr0
iface xenbr0 inet dhcp
    bridge_ports eth0
    #allow-hotplug xenbr0 #Uncomment if using vSwitches

Une fois terminé, redémarrez. Sinon, étant donné que vous avez modifié eth0 mais que vous n'avez pas défini de nouvelle adresse IP, votre pont risque de ne pas s'afficher correctement, même si vous utilisez la commande ifup/relancer la mise en réseau. En effet, eth0 peut accidentellement conserver son adresse IP.

Enfin, configurez les interfaces réseau de votre système d'exploitation invité comme s'il s'agissait de tout autre hôte physique sur votre réseau. (Avec l'exemple 1, vous pouvez utiliser 192.168.1.11.) À ce stade, les autres périphériques de votre réseau doivent pouvoir atteindre l'invité.

ping 192.168.1.11 

Aucun iptables ou transfert IP (sysctl.conf) n'est nécessaire. STP est nécessaire niquement si votre réseau prend en charge STP et que vous devez éviter les boucles réseau de couche 2 et que vous ne souhaitez pas gérer cela manuellement. (c'est-à-dire que les petits réseaux n'auront pas besoin de bridge_stp, bridge_fd ou bridge_maxwait.)

2