Gérer le réseau

Les procédures de configuration réseau décrites dans cette section varient selon que vous configurez un hôte autonome ou un hôte faisant partie d’un pool de ressources.

Création de réseaux dans un hôte autonome

Comme des réseaux externes sont créés pour chaque PIF lors de l’installation de l’hôte, la création de réseaux supplémentaires n’est généralement requise que pour :

• Utilisez un réseau privé

• Prise en charge des opérations avancées telles que des VLAN ou des liaisons NIC

Pour plus d’informations sur la façon d’ajouter ou de supprimer des réseaux à l’aide de XenCenter, consultez la section Ajouter un nouveau réseau dans la documentation XenCenter.

Ouvrez la console de texte de l’hôte XenServer.

Créez le réseau à l’aide de la commande network-create, qui renvoie l’UUID du nouveau réseau :

xe network-create name-label=mynetwork
<!--NeedCopy-->

À ce stade, le réseau n’est pas connecté à un PIF et est donc interne.

Création de réseaux dans des pools de ressources

Tous les hôtes XenServer d’un pool de ressources doivent avoir le même nombre de cartes réseau physiques. Cette exigence n’est pas strictement appliquée lorsqu’un hôte est joint à un pool. L’une des cartes réseau est toujours désignée comme interface de gestion, utilisée pour le trafic de gestion XenServer.

Comme tous les hôtes d’un pool partagent un réseau commun. Il est important d’avoir la même configuration réseau physique pour les hôtes XenServer d’un pool. Les PIF sur les hôtes individuels sont connectés aux réseaux de l’ensemble du pool en fonction du nom de l’appareil. Par exemple, tous les hôtes XenServer d’un pool avec une carte réseau eth0 ont un PIF correspondant connecté au réseau à l’échelle du pool Network 0. Il en va de même pour les hôtes dotés de cartes réseau eth1 et Network 1, et d’autres cartes d’interface réseau présentes sur au moins un hôte XenServer du pool.

Si un hôte XenServer possède un nombre de cartes réseau différent de celui des autres hôtes du pool, des complications peuvent survenir. Les complications peuvent survenir car tous les réseaux de pool ne sont pas valides pour tous les hôtes de pool. Par exemple, si les hôtes host1 et host2 se trouvent dans le même pool et que host1 possède quatre cartes réseau et que host2 n’en possède que deux, seuls les réseaux connectés aux PIF correspondant à eth0 et eth1 sont valides sur host2. Les machines virtuelles de l’hôte 1 avec des VIF connectées à des réseaux correspondant à eth2 et eth3 ne peuvent pas migrer vers l’hôte hôte 2.

Créer des VLAN

Pour les hôtes d’un pool de ressources, vous pouvez utiliser la commande pool-vlan-create. Cette commande crée le VLAN et crée automatiquement et plug-ins les PIF requis sur les hôtes du pool. Pour plus d’informations, consultez pool-vlan-create.

Ouvrez la console hôte XenServer.

Créez un réseau à utiliser avec le VLAN. L’UUID du nouveau réseau est renvoyé :

xe network-create name-label=network5
<!--NeedCopy-->

Utilisez la commande pif-list pour trouver l’UUID du PIF correspondant à la carte réseau physique prenant en charge la balise VLAN souhaitée. Les UUID et les noms de périphériques de tous les PIF sont renvoyés, y compris les VLAN existants :

xe pif-list
<!--NeedCopy-->

Créez un objet VLAN spécifiant le PIF physique et la balise VLAN souhaités sur toutes les machines virtuelles à connecter au nouveau VLAN. Un nouveau PIF est créé et connecté au réseau spécifié. L’UUID du nouvel objet PIF est renvoyé.

xe vlan-create network-uuid=network_uuid pif-uuid=pif_uuid vlan=5
<!--NeedCopy-->

Attachez des VIF VM au nouveau réseau. Pour plus d’informations, consultez la section Création de réseaux sur un hôte autonome.

Créer des liaisons NIC sur un hôte autonome

Nous vous recommandons d’utiliser XenCenter pour créer des liaisons de carte réseau. Pour plus d’informations, reportez-vous à la section Configuration des cartes réseau.

Cette section décrit comment utiliser l’interface de ligne de commande xe pour lier des interfaces réseau sur des hôtes XenServer qui ne font pas partie d’un pool. Pour plus d’informations sur l’utilisation de l’interface de ligne de commande xe pour créer des liaisons de carte réseau sur des hôtes XenServer qui constituent un pool de ressources, consultez la section Création de liaisons de carte réseau dans des pools de ressources.

Créer une liaison NIC

Lorsque vous liez une carte réseau, la liaison absorbe le PIF/NIC utilisé comme interface de gestion. L’interface de gestion est automatiquement déplacée vers le PIF de l’obligation.

1. Utilisez la commande network-create pour créer un réseau à utiliser avec la carte réseau liée. L’UUID du nouveau réseau est renvoyé :

   xe network-create name-label=bond0
   <!--NeedCopy-->
   

2. Utilisez la commande pif-list pour déterminer les UUID des PIF à utiliser dans la liaison :

   xe pif-list
   <!--NeedCopy-->
   

3. Procédez comme suit :

   • Pour configurer la liaison en mode actif-actif (par défaut), utilisez la commande bond-create pour créer la liaison. À l’aide de virgules pour séparer les paramètres, spécifiez l’UUID réseau nouvellement créé et les UUID des PIF à lier :

      xe bond-create network-uuid=network_uuid /
           pif-uuids=pif_uuid_1,pif_uuid_2,pif_uuid_3,pif_uuid_4
      <!--NeedCopy-->
     

     Saisissez deux UUID lorsque vous liez deux cartes réseau et quatre UUID lorsque vous liez quatre cartes réseau. L’UUID de la liaison est renvoyé après l’exécution de la commande.

   • Pour configurer la liaison en mode de liaison actif-passif ou LACP, utilisez la même syntaxe, ajoutez le paramètre mode facultatif et spécifiez lacp ou active-backup :

      xe bond-create network-uuid=network_uuid pif-uuids=pif_uuid_1, /
           pif_uuid_2,pif_uuid_3,pif_uuid_4 /
           mode=balance-slb | active-backup | lacp
      <!--NeedCopy-->
     

Contrôler l’adresse MAC de la liaison

Lorsque vous liez l’interface de gestion, elle englobe le PIF/NIC utilisé comme interface de gestion. Si l’hôte utilise DHCP, l’adresse MAC de la liaison est la même que celle du PIF/NIC utilisé. L’adresse IP de l’interface de gestion peut rester inchangée.

Vous pouvez modifier l’adresse MAC de la liaison afin qu’elle soit différente de l’adresse MAC de la carte réseau de l’interface de gestion (actuelle). Toutefois, à mesure que la liaison est activée et que l’adresse MAC/IP utilisée change, les sessions réseau existantes sur l’hôte sont supprimées.

Vous pouvez contrôler l’adresse MAC d’une liaison de deux manières :

• Un paramètre mac facultatif peut être spécifié dans la commande bond-create. Vous pouvez utiliser ce paramètre pour définir l’adresse MAC de la liaison sur n’importe quelle adresse arbitraire.

• Si le paramètre mac n’est pas spécifié, XenServer utilise l’adresse MAC de l’interface de gestion s’il s’agit de l’une des interfaces de la liaison. Si l’interface de gestion ne fait pas partie de la liaison, mais qu’une autre interface de gestion l’est, la liaison utilise l’adresse MAC (ainsi que l’adresse IP) de cette interface de gestion. Si aucune des cartes réseau de la liaison n’est une interface de gestion, la liaison utilise la MAC de la première carte réseau nommée.

Annuler les obligations NIC

Lorsque vous revenez à une configuration non liée de l’hôte XenServer, la commande bond-destroy configure automatiquement la carte réseau principale en tant qu’interface pour l’interface de gestion. Par conséquent, tous les VIF sont déplacés vers l’interface de gestion. Si l’interface de gestion d’un hôte se trouve sur une interface liée VLAN balisée, lors de l’exécution de bond-destroy, le VLAN de gestion est déplacé vers la carte réseau principale.

Le terme carte réseau principale fait référence au PIF à partir duquel la configuration MAC et IP a été copiée lors de la création de la liaison. Lors de la liaison de deux cartes réseau, la carte réseau principale est :

1. La carte réseau de l’interface de gestion (si l’interface de gestion est l’une des cartes réseau liées).

2. Toute autre carte réseau avec une adresse IP (si l’interface de gestion ne faisait pas partie de la liaison).

3. Le premier nommé NIC. Vous pouvez découvrir de quel fichier il s’agit en exécutant ce qui suit :

   xe bond-list params=all
   <!--NeedCopy-->
   

Créer des liaisons NIC dans les pools de ressources

Dans la mesure du possible, créez des liaisons NIC dans le cadre de la création initiale du pool de ressources, avant de joindre d’autres hôtes au pool ou de créer des machines virtuelles. Cela permet de répliquer automatiquement la configuration de liaison sur les hôtes lorsqu’ils sont joints au pool et de réduire le nombre d’étapes requises.

L’ajout d’une liaison de carte réseau à un pool existant nécessite l’une des opérations suivantes :

• Utilisation de l’interface de ligne de commande pour configurer les liaisons sur le coordinateur de pool, puis sur chaque membre du pool.

• Utilisation de l’interface de ligne de commande pour configurer des liaisons sur le coordinateur de pool, puis redémarrer chaque membre du pool afin qu’il hérite de ses paramètres du coordinateur de pool.

• Utilisation de XenCenter pour configurer les liaisons sur le coordinateur du pool. XenCenter synchronise automatiquement les paramètres réseau des hôtes membres avec le coordinateur du pool, vous n’avez donc pas besoin de redémarrer les hôtes membres.

Pour plus de simplicité et pour éviter les erreurs de configuration, nous vous recommandons d’utiliser XenCenter pour créer des liaisons de carte réseau. Pour plus d’informations, reportez-vous à la section Configuration des cartes réseau.

Cette section décrit l’utilisation de l’interface de ligne de commande xe pour créer des interfaces réseau liées sur des hôtes XenServer qui constituent un pool de ressources. Pour plus d’informations sur l’utilisation de l’interface de ligne de commande xe pour créer des liaisons de carte réseau sur un hôte autonome, consultez Création de liaisons de carte réseau sur un hôte autonome.

Avertissement :

N’essayez pas de créer des liaisons réseau lorsque la haute disponibilité est activée. Le processus de création de liens perturbe le rythme cardiaque de haute disponibilité en cours et amène les hôtes à s’auto-clôturer (s’arrêter eux-mêmes). Les hôtes peuvent ne pas redémarrer correctement et peuvent avoir besoin de la commande host-emergency-ha-disable pour récupérer.

Sélectionnez l’hôte dont vous souhaitez être le coordinateur du pool. Le coordinateur du pool appartient par défaut à un pool anonyme. Pour créer un pool de ressources avec l’interface de ligne de commande, renommez le pool sans nom existant :

xe pool-param-set name-label="New Pool" uuid=pool_uuid
<!--NeedCopy-->

Créez le lien NIC comme décrit dans Créer une liaison NIC.

Ouvrez une console sur un hôte que vous souhaitez joindre au pool et exécutez la commande :

xe pool-join master-address=host1 master-username=root master-password=password
<!--NeedCopy-->

Les informations de réseau et de liaison sont automatiquement répliquées sur le nouvel hôte. L’interface de gestion est automatiquement déplacée de la carte réseau hôte où elle a été initialement configurée vers le PIF lié. En d’autres termes, l’interface de gestion est maintenant absorbée dans la liaison, de sorte que l’ensemble de la liaison fonctionne comme interface de gestion.

Utilisez la commande host-list pour rechercher l’UUID de l’hôte en cours de configuration :

xe host-list
<!--NeedCopy-->

Avertissement :

n’essayez pas de créer des liaisons réseau lorsque la haute disponibilité est activée. Le processus de création de liens perturbe le rythme cardiaque de haute disponibilité en cours et amène les hôtes à s’auto-clôturer (s’arrêter eux-mêmes). Les hôtes peuvent ne pas redémarrer correctement et vous devrez peut-être exécuter la commande host-emergency-ha-disable pour récupérer.

Configuration d’une carte réseau de stockage dédiée

Vous pouvez utiliser XenCenter ou l’interface de ligne de commande xe pour attribuer une adresse IP à une carte réseau et la dédier à une fonction spécifique, telle que le trafic de stockage. Lorsque vous configurez une carte réseau avec une adresse IP, vous le faites en créant une interface secondaire. (La carte réseau XenServer compatible IP utilisée pour la gestion est connue sous le nom d’interface de gestion.)

Lorsque vous souhaitez dédier une interface secondaire dans un but spécifique, assurez-vous que la configuration réseau appropriée est en place. Cela permet de s’assurer que la carte réseau est utilisée uniquement pour le trafic souhaité. Pour dédier une carte réseau au trafic de stockage, configurez la carte réseau, la cible de stockage, le commutateur et le VLAN de telle sorte que la cible ne soit accessible que via la carte réseau attribuée. Si votre configuration physique et IP ne limite pas le trafic envoyé via la carte réseau de stockage, vous pouvez envoyer du trafic, tel que le trafic de gestion via l’interface secondaire.

Lorsque vous créez une nouvelle interface secondaire pour le trafic de stockage, vous devez lui attribuer une adresse IP qui est la suivante :

• Sur le même sous-réseau que le contrôleur de stockage, le cas échéant, et

• Pas sur le même sous-réseau que les autres interfaces secondaires ou l’interface de gestion.

Lorsque vous configurez des interfaces secondaires, chaque interface secondaire doit se trouver sur un sous-réseau distinct. Par exemple, si vous souhaitez configurer deux autres interfaces secondaires pour le stockage, vous avez besoin d’adresses IP sur trois sous-réseaux différents : un sous-réseau pour l’interface de gestion, un sous-réseau pour l’interface secondaire 1 et un sous-réseau pour l’interface secondaire 2.

Si vous utilisez la liaison pour la résilience de votre trafic de stockage, vous pouvez envisager d’utiliser LACP au lieu de la liaison de pont Linux. Pour utiliser la liaison LACP, vous devez configurer le vSwitch en tant que pile réseau. Pour plus d’informations, consultez Réseaux vSwitch.

Remarque :

Lorsque vous sélectionnez une carte réseau à configurer en tant qu’interface secondaire à utiliser avec les SR iSCSI ou NFS, assurez-vous que la carte réseau dédiée utilise un sous-réseau IP distinct qui n’est pas routable à partir de l’interface de gestion. Si cela n’est pas appliqué, le trafic de stockage peut être dirigé sur l’interface de gestion principale après un redémarrage de l’hôte, en raison de l’ordre dans lequel les interfaces réseau sont initialisées.

Assurez-vous que le PIF se trouve sur un sous-réseau distinct ou que le routage est configuré en fonction de la topologie de votre réseau afin de forcer le trafic souhaité sur le PIF sélectionné.

Configurez une configuration IP pour le PIF, en ajoutant les valeurs appropriées pour le paramètre mode. Si vous utilisez l’adressage IP statique, ajoutez les paramètres IP, masque de réseau, passerelle et DNS :

xe pif-reconfigure-ip mode=DHCP | Static uuid=pif-uuid
<!--NeedCopy-->

Définissez le paramètre disallow-unplug du PIF sur true :

xe pif-param-set disallow-unplug=true uuid=pif-uuid
<!--NeedCopy-->

xe pif-param-set other-config:management_purpose="Storage" uuid=pif-uuid
<!--NeedCopy-->

Si vous souhaitez utiliser une interface secondaire pour le stockage qui peut également être routée à partir de l’interface de gestion (sachant que cette configuration n’est pas la meilleure pratique), vous avez deux options :

• Après le redémarrage de l’hôte, assurez-vous que l’interface secondaire est correctement configurée. Utilisez les commandes xe pbd-unplug et xe pbd-plug pour réinitialiser les connexions de stockage sur l’hôte. Cette commande redémarre la connexion de stockage et l’achemine sur la bonne interface.

• Vous pouvez également utiliser xe pif-forget pour supprimer l’interface de la base de données XenServer et la configurer manuellement dans le domaine de contrôle. xe pif-forget est une option avancée qui nécessite que vous sachiez comment configurer manuellement le réseau Linux.

Utiliser des cartes réseau compatibles SR-IOV

La virtualisation des E/S à racine unique (SR-IOV) est une technologie de virtualisation qui permet à un seul périphérique PCI d’apparaître comme plusieurs périphériques PCI sur le système physique. Le périphérique physique réel est connu sous le nom de fonction physique (PF) tandis que les autres sont connus sous le nom de fonctions virtuelles (VF). L’hyperviseur peut attribuer un ou plusieurs VF à une machine virtuelle (VM) : l’invité peut alors utiliser le périphérique comme s’il était directement affecté.

L’attribution d’un ou de plusieurs VF de carte réseau à une machine virtuelle permet à son trafic réseau de contourner le commutateur virtuel. Une fois configurée, chaque machine virtuelle se comporte comme si elle utilisait directement la carte réseau, ce qui réduit la surcharge de traitement et améliore les performances.

Avantages du SR-IOV

Un VF SR-IOV offre de meilleures performances que le VIF. Il peut garantir la ségrégation matérielle entre le trafic provenant de différentes machines virtuelles via la même carte réseau (en contournant la pile réseau XenServer).

Grâce à cette fonctionnalité, vous pouvez :

• Activez SR-IOV sur les cartes réseau prenant en charge SR-IOV.

• Désactivez SR-IOV sur les cartes réseau prenant en charge SR-IOV.

• Gérez les VF SR-IOV en tant que pool de ressources VF.

• Attribuez des VF SR-IOV à une machine virtuelle.

• Configurez les VF SR-IOV (par exemple, adresse MAC, VLAN, débit).

• Exécutez des tests pour confirmer si SR-IOV est pris en charge dans le cadre du kit de certification automatisé.

Configuration du système

Configurez correctement la plate-forme matérielle pour prendre en charge SR-IOV. Les technologies suivantes sont requises :

• Virtualisation MMU d’E/S (AMD-Vi et Intel VT-d)

• Interprétation alternative de l’ID de routage (ARI)

• Services de traduction d’adresses (ATS)

• Services de contrôle d’accès (ACS)

Consultez la documentation fournie avec votre système pour savoir comment configurer le microprogramme du système afin d’activer les technologies mentionnées.

Activer un réseau SR-IOV sur une carte réseau

Dans XenCenter, utilisez l’assistant Nouveau réseau de l’onglet Mise en réseau pour créer et activer un réseau SR-IOV sur une carte réseau.

Attribuer un réseau SR-IOV à l’interface virtuelle (au niveau de la machine virtuelle)

Dans XenCenter, au niveau de la machine virtuelle, utilisez l’assistant Ajouter une interface virtuelle de l’onglet Mise en réseau pour ajouter un réseau SR-IOV en tant qu’interface virtuelle pour cette machine virtuelle. Pour plus d’informations, consultez la section Ajouter un nouveau réseau.

NIC et invités pris en charge

Pour obtenir la liste des plates-formes matérielles et des cartes réseau prises en charge, consultez la section Liste de compatibilité matérielle. Consultez la documentation fournie par le fournisseur pour un invité particulier afin de déterminer s’il prend en charge SR-IOV.

Limitations

• Pour certaines cartes réseau utilisant des pilotes hérités (par exemple, la famille Intel I350), l’hôte doit être redémarré pour activer ou désactiver SR-IOV sur ces périphériques.

• Un réseau SR-IOV au niveau du pool comportant différents types de cartes réseau n’est pas pris en charge.

• Un VF SR-IOV et un VIF normal de la même carte réseau peuvent ne pas être en mesure de communiquer entre eux en raison des limitations matérielles de la carte réseau. Pour permettre à ces machines virtuelles de communiquer, assurez-vous que la communication utilise le modèle VF à VF ou VIF à VIF, et non VF à VIF.

• Les paramètres de qualité de service de certains VF SR-IOV ne prennent pas en compte car ils ne prennent pas en charge la limitation du débit du réseau.

• L’exécution de la migration en direct, de la suspension et du point de contrôle n’est pas prise en charge sur les machines virtuelles utilisant un VF SR-IOV.

• Les VF SR-IOV ne prennent pas en charge le branchement à chaud.

• Les VF SR-IOV ne prennent pas en charge le démarrage réseau.

• Pour certaines cartes réseau dotées de pilotes de carte réseau hérités, un redémarrage peut être nécessaire même après le redémarrage de l’hôte, ce qui indique que la carte réseau n’est pas en mesure d’activer SR-IOV.

• Si votre machine virtuelle dispose d’un VF SR-IOV, les fonctions qui nécessitent une migration en direct ne sont pas possibles. En effet, la machine virtuelle est directement liée au VF de carte réseau physique compatible SR-IOV.

• SR-IOV peut être utilisé dans un environnement qui utilise la haute disponibilité. Cependant, la SR-IOV n’est pas prise en compte dans la planification des capacités. Les machines virtuelles auxquelles des VF SR-IOV sont attribués sont redémarrées au mieux lorsqu’un hôte du pool dispose des ressources appropriées. Ces ressources incluent SR-IOV activé sur le bon réseau et un VF gratuit.

• Les VF SR-IOV ne sont pas compatibles avec l’accélérateur PVS.

Configurer les VF SR-IOV pour les pilotes hérités

En général, le nombre maximal de VF qu’une carte réseau peut prendre en charge peut être déterminé automatiquement. Pour les cartes réseau utilisant des pilotes hérités (par exemple, la famille Intel I350), la limite est définie dans le fichier de configuration du module de pilote. Il se peut que la limite doive être ajustée manuellement. Pour le définir au maximum, ouvrez le fichier à l’aide d’un éditeur et modifiez la ligne de départ :

## VFs-maxvfs-by-user:
<!--NeedCopy-->

Par exemple, pour définir le maximum de VF sur 4 pour que le pilote igb, modifiez /etc/modprobe.d/igb.conf pour lire :

## VFs-param: max_vfs
## VFs-maxvfs-by-default: 7
## VFs-maxvfs-by-user: 4
options igb max_vfs=0
<!--NeedCopy-->

Remarques :

• La valeur doit être inférieure ou égale à la valeur de la ligne VFs-maxvfs-by-default.

• Ne modifiez aucune autre ligne de ces fichiers.

• Apportez les modifications nécessaires avant d’activer SR-IOV.

LIGNE DE COMMANDE

Reportez-vous aux commandes SR-IOV pour obtenir des instructions CLI sur la création, la suppression, l’affichage des réseaux SR-IOV et l’attribution d’un VF SR-IOV à une machine virtuelle.

Contrôler le débit de données sortantes (QoS)

Pour limiter la quantité de données sortantes qu’une machine virtuelle peut envoyer par seconde, définissez une valeur facultative de qualité de service (QoS) sur les interfaces virtuelles (VIF) de machine virtuelle. Le paramètre vous permet de spécifier un débit de transmission maximal pour les paquets sortants en kilo-octets par seconde.

La valeur de qualité de service limite le débit de transmission depuis la machine virtuelle. Le paramètre Quality of Service ne limite pas la quantité de données que la machine virtuelle peut recevoir. Si une telle limite est souhaitée, nous recommandons de limiter le débit des paquets entrants plus haut dans le réseau (par exemple, au niveau du commutateur).

En fonction de la pile réseau configurée dans le pool, vous pouvez définir la valeur Quality of Service sur les interfaces virtuelles de VM (VIF) à l’un des deux endroits. Vous pouvez définir cette valeur à l’aide de l’interface de ligne de commande xe ou dans XenCenter.

• XenCenter Vous pouvez définir la valeur limite de débit de transmission Qualité de service dans la boîte de dialogue des propriétés de l’interface virtuelle.
• Commandes xe Vous pouvez définir le débit de transmission de la qualité de service à l’aide de l’interface de ligne de commande à l’aide des commandes de la section suivante.

Exemple de commande CLI pour QoS

Pour limiter un VIF à un débit de transmission maximal de 100 kilo-octets par seconde à l’aide de l’interface de ligne de commande, utilisez la commande vif-param-set :

xe vif-param-set uuid=vif_uuid qos_algorithm_type=ratelimit
xe vif-param-set uuid=vif_uuid qos_algorithm_params:kbps=100
<!--NeedCopy-->

Remarque :

Le paramètre kbps indique les kilobits par seconde (Kbits/s), et non les kilobits par seconde (Kbits/s).

Modifier les options de configuration réseau

Cette section explique comment modifier la configuration réseau de votre hôte XenServer. Elle comprend :

• Modification du nom d’hôte (c’est-à-dire le nom du système de noms de domaine (DNS))

• Ajout ou suppression de serveurs DNS

• Modification des adresses IP

• Modification de la carte réseau utilisée comme interface de gestion

• Ajout d’une nouvelle carte réseau physique au serveur

• Ajout d’un objectif à un réseau

• Activation du filtrage ARP (verrouillage du port de commutation)

Nom d’hôte

Le nom d’hôte système, également connu sous le nom de domaine ou de nom DNS, est défini dans la base de données à l’échelle du pool et modifié à l’aide de la commande CLI xe host-set-hostname-live comme suit :

xe host-set-hostname-live host-uuid=host_uuid host-name=host-name
<!--NeedCopy-->

Le nom d’hôte du domaine de contrôle sous-jacent change dynamiquement pour refléter le nouveau nom d’hôte.

Serveurs DNS

Pour ajouter ou supprimer des serveurs DNS dans la configuration d’adressage IP de l’hôte XenServer, utilisez la commande pif-reconfigure-ip. Par exemple, pour un PIF avec une adresse IP statique :

xe pif-reconfigure-ip uuid=pif_uuid mode=static DNS=new_dns_ip IP=IP netmask=netmask
<!--NeedCopy-->

Modifier la configuration de l’adresse IP pour un hôte autonome

Vous pouvez utiliser l’interface de ligne de commande xe pour modifier la configuration de l’interface réseau. Ne modifiez pas directement les scripts de configuration réseau sous-jacents.

Pour modifier la configuration de l’adresse IP d’un PIF, utilisez la commande CLI pif-reconfigure-ip. Pour plus de détails sur les paramètres de la commande pif-reconfigure-ip, consultez pif-reconfigure-ip. Reportez-vous à la section suivante pour plus d’informations sur la modification des adresses IP de l’hôte dans les pools de ressources.

Modifier la configuration des adresses IP dans les pools de ressources

Les hôtes XenServer des pools de ressources disposent d’une adresse IP de gestion unique utilisée pour la gestion et la communication vers et depuis les autres hôtes du pool. Les étapes requises pour modifier l’adresse IP de l’interface de gestion d’un hôte sont différentes pour le coordinateur de pool et les autres hôtes.

Remarque :

Vous devez être prudent lorsque vous modifiez l’adresse IP d’un hôte et d’autres paramètres réseau. En fonction de la topologie du réseau et de la modification apportée, les connexions au stockage réseau peuvent être perdues. Dans ce cas, le stockage doit être rebranché à l’aide de la fonction Réparer le stockage de XenCenter ou à l’aide de la commande CLI pbd-plug. Pour cette raison, nous vous recommandons de migrer les machines virtuelles hors de l’hôte avant de modifier sa configuration IP.

Utilisez la commande CLI pif-reconfigure-ip pour définir l’adresse IP comme vous le souhaitez. Pour plus de détails sur les paramètres de la commande pif-reconfigure-ip, consultez pif-reconfigure-ip :

xe pif-reconfigure-ip uuid=pif_uuid mode=DHCP
<!--NeedCopy-->

Utilisez la commande host-list CLI pour confirmer que l’hôte membre s’est reconnecté avec succès au coordinateur du pool en vérifiant que tous les autres hôtes XenServer du pool sont visibles :

xe host-list
<!--NeedCopy-->

La modification de l’adresse IP de l’hôte XenServer du coordinateur du pool nécessite des étapes supplémentaires. En effet, chaque membre du pool utilise l’adresse IP publiée du coordinateur de pool pour la communication. Les membres du pool ne savent pas comment contacter le coordinateur du pool lorsque son adresse IP change.

Dans la mesure du possible, utilisez une adresse IP dédiée qui n’est pas susceptible de changer pendant la durée de vie du pool pour les coordinateurs de pool.

Utilisez la commande CLI pif-reconfigure-ip pour définir l’adresse IP comme vous le souhaitez :

xe pif-reconfigure-ip uuid=pif_uuid mode=DHCP
<!--NeedCopy-->

Lorsque l’adresse IP du coordinateur du pool change, tous les hôtes membres passent en mode d’urgence lorsqu’ils ne parviennent pas à contacter le coordinateur du pool.

Sur le coordinateur de pool, utilisez la commande pool-recover-slaves pour forcer le coordinateur de pool à contacter chaque membre du pool et à les informer de la nouvelle adresse IP du coordinateur de pool :

xe pool-recover-slaves
<!--NeedCopy-->

Interface de gestion

Lorsque vous installez XenServer sur un hôte, l’une de ses cartes réseau est désignée comme interface de gestion : la carte réseau utilisée pour le trafic de gestion XenServer. L’interface de gestion est utilisée pour les connexions XenCenter à l’hôte (par exemple, Citrix Virtual Apps and Desktops) et pour les communications entre hôtes.

Utilisez la commande pif-list pour déterminer quelle PIF correspond à la carte réseau à utiliser comme interface de gestion. L’UUID de chaque PIF est renvoyé.

xe pif-list
<!--NeedCopy-->

Utilisez la commande pif-param-list pour vérifier la configuration d’adressage IP pour le PIF utilisé pour l’interface de gestion. Si nécessaire, utilisez la commande pif-reconfigure-ip pour configurer l’adressage IP pour le PIF à utiliser.

xe pif-param-list uuid=pif_uuid
<!--NeedCopy-->

Utilisez la commande host-management-reconfigure CLI pour modifier le PIF utilisé pour l’interface de gestion. Si cet hôte fait partie d’un pool de ressources, cette commande doit être émise sur la console de l’hôte membre :

xe host-management-reconfigure pif-uuid=pif_uuid
<!--NeedCopy-->

Utilisez la commande network-list pour déterminer quel PIF correspond à la carte réseau à utiliser comme interface de gestion pour tous les hôtes du pool. L’UUID du réseau à l’échelle du pool est renvoyé.

xe network-list
<!--NeedCopy-->

Utilisez la commande network-param-list pour récupérer les UUID PIF de tous les hôtes du pool. Utilisez la commande pif-param-list pour vérifier la configuration de l’adressage IP pour le PIF de l’interface de gestion. Si nécessaire, utilisez la commande pif-reconfigure-ip pour configurer l’adressage IP pour le PIF à utiliser.

xe pif-param-list uuid=pif_uuid
<!--NeedCopy-->

Utilisez la commande pool-management-reconfigure CLI pour modifier le PIF utilisé pour l’interface de gestion répertoriée dans la liste Réseaux.

xe pool-management-reconfigure network-uuid=network_uuid
<!--NeedCopy-->

Restreindre l’utilisation du port 80

Vous pouvez utiliser le protocole HTTPS sur le port 443 ou le protocole HTTP sur le port 80 pour communiquer avec XenServer. Pour des raisons de sécurité, vous pouvez fermer le port TCP 80 sur l’interface de gestion. Par défaut, le port 80 est toujours ouvert. Si vous le fermez, tous les clients externes qui utilisent l’interface de gestion doivent utiliser le protocole HTTPS sur le port 443 pour se connecter à XenServer. Toutefois, avant de fermer le port 80, vérifiez si tous vos clients API (Citrix Virtual Apps and Desktops en particulier) peuvent utiliser le protocole HTTPS sur le port 443.

Pour fermer le port 80, consultez la commande de CLI xe https-only ou la section Modifier les propriétés du pool dans la documentation XenCenter.

Désactiver l’accès à la gestion

Pour désactiver complètement l’accès à distance à la console de gestion, utilisez la commande CLI host-management-disable.

Avertissement :

Lorsque l’interface de gestion est désactivée, vous devez vous connecter à la console de l’hôte physique pour effectuer des tâches de gestion. Les interfaces externes telles que XenCenter ne fonctionnent pas lorsque l’interface de gestion est désactivée.

Ajouter une nouvelle carte réseau physique

1. Installez une nouvelle carte réseau physique sur votre hôte XenServer de la manière habituelle.
2. Redémarrez votre hôte XenServer.

3. Répertoriez toutes les cartes réseau physiques de cet hôte XenServer à l’aide de la commande suivante :

   xe pif-list host-uuid=<host_uuid>
   

4. Si vous ne voyez pas la carte réseau supplémentaire, recherchez de nouvelles interfaces physiques à l’aide de la commande suivante :

   xe pif-scan host-uuid=<host_uuid>
   

   Cette commande crée un nouvel objet PIF pour la nouvelle carte réseau.

5. Répertoriez les cartes réseau physiques de l’hôte XenServer pour vérifier que la nouvelle carte réseau est visible :

   xe pif-list host-uuid=<host_uuid>
   

6. Le nouveau PIF est initialement répertorié comme étant déconnecté (currently-attached ( RO): false). Pour l’afficher, utilisez la commande suivante :

   xe pif-plug uuid=<uuid_of_pif>
   

Vous pouvez également utiliser XenCenter pour rechercher de nouvelles cartes réseau. Pour plus d’informations, consultez la section Configuration des cartes réseau dans la documentation XenCenter.

Supprimer une carte réseau physique

Avant de retirer la carte réseau, assurez-vous de connaître l’UUID du PIF correspondant. Retirez la carte réseau physique de votre hôte XenServer de la manière habituelle. Après avoir redémarré l’hôte, exécutez la commande xe CLI pif-forget uuid=<UUID> pour détruire l’objet PIF.

Ajouter un objectif à un réseau

L’objectif du réseau peut être utilisé pour ajouter des fonctionnalités supplémentaires à un réseau. Par exemple, la possibilité d’utiliser le réseau pour établir des connexions NBD.

Pour ajouter un objectif réseau, utilisez la commande xe network-param-add :

xe network-param-add param-name=purpose param-key=purpose uuid=network-uuid
<!--NeedCopy-->

Pour supprimer un objectif réseau, utilisez la commande xe network-param-remove :

xe network-param-remove param-name=purpose param-key=purpose uuid=network-uuid
<!--NeedCopy-->

Actuellement, les valeurs disponibles pour l’objectif réseau sont nbd et insecure_nbd. Pour plus d’informations, consultez le Guide de suivi des blocs modifiés de XenServer.

Utiliser le verrouillage du port du commutateur

La fonction de verrouillage des ports de commutateur XenServer vous permet de contrôler le trafic envoyé par des machines virtuelles inconnues, non fiables ou potentiellement hostiles en limitant leur capacité à prétendre détenir une adresse MAC ou IP qui ne leur a pas été attribuée. Vous pouvez utiliser les commandes de verrouillage de port pour bloquer tout le trafic sur un réseau par défaut ou définir des adresses IP spécifiques à partir desquelles une machine virtuelle individuelle est autorisée à envoyer du trafic.

Le verrouillage des ports de commutation est une fonctionnalité conçue pour les fournisseurs de services cloud publics dans des environnements préoccupés par les menaces internes. Cette fonctionnalité aide les fournisseurs de services cloud publics qui disposent d’une architecture réseau dans laquelle chaque machine virtuelle possède une adresse IP publique connectée à Internet. Étant donné que les locataires du cloud ne sont pas fiables, vous pouvez utiliser des mesures de sécurité telles que la protection contre l’usurpation pour vous assurer que les locataires ne peuvent pas attaquer d’autres machines virtuelles dans le cloud.

L’utilisation du verrouillage des ports de commutation vous permet de simplifier la configuration de votre réseau en permettant à tous vos locataires ou invités d’utiliser le même réseau de couche 2.

L’une des fonctions les plus importantes des commandes de verrouillage de port est qu’elles peuvent restreindre le trafic envoyé par un invité non approuvé. Cela limite la capacité de l’invité à prétendre qu’il possède une adresse MAC ou IP qu’il ne possède pas réellement. Plus précisément, vous pouvez utiliser ces commandes pour empêcher un invité de :

• Réclamer une adresse IP ou MAC autre que celles que l’administrateur XenServer a spécifiées pour qu’il puisse utiliser

• Intercepter, usurper ou perturber le trafic d’autres machines virtuelles

Exigences

• La fonctionnalité de verrouillage des ports de commutateur XenServer est prise en charge sur le pont Linux et les piles réseau vSwitch.

• Lorsque vous activez le contrôle d’accès basé sur les rôles (RBAC) dans votre environnement, l’utilisateur qui configure le verrouillage du port de commutation doit être connecté avec un compte qui possède au moins un rôle d’opérateur de pool ou d’administrateur de pool. Lorsque le RBAC n’est pas activé dans votre environnement, l’utilisateur doit être connecté avec le compte racine du coordinateur de pool.

• Lorsque vous exécutez les commandes de verrouillage du port de commutation, les réseaux peuvent être en ligne ou hors ligne.

• Dans les invités Windows, l’icône réseau déconnectée n’apparaît que lorsque XenServer VM Tools est installé sur l’invité.

Remarques

Sans aucune configuration de verrouillage des ports de commutation, les VIF sont définis sur « network_default » et les réseaux sont définis sur « déverrouillés ».

La configuration du verrouillage des ports de commutation n’est pas prise en charge lorsque des contrôleurs tiers sont utilisés dans l’environnement.

Le verrouillage du port du commutateur n’empêche pas les locataires du cloud de :

• Effectuer une attaque au niveau IP contre un autre locataire/utilisateur. Cependant, le verrouillage du port de commutation les empêche d’effectuer l’attaque au niveau IP s’ils tentent d’utiliser les moyens suivants pour le faire et que le verrouillage du port de commutation est configuré : a) usurper l’identité d’un autre locataire dans le cloud ou d’un utilisateur ou b) initier une interception du trafic destiné à un autre utilisateur.

• Épuiser les ressources du réseau.

• Réception d’un trafic destiné à d’autres machines virtuelles via des comportements normaux d’inondation des commutateurs (pour les adresses MAC de diffusion ou les adresses MAC de destination inconnues).

De même, le verrouillage du port de commutation ne limite pas l’endroit où une machine virtuelle peut envoyer du trafic.

Notes d’implémentation

Vous pouvez implémenter la fonctionnalité de verrouillage des ports de commutation à l’aide de la ligne de commande ou de l’API XenServer. Cependant, dans les grands environnements, où l’automatisation est une préoccupation majeure, la méthode de mise en œuvre la plus courante peut être l’utilisation de l’API.

Exemples

Cette section fournit des exemples de la manière dont le verrouillage du port de commutateur peut empêcher certains types d’attaques. Dans ces exemples, VM-c est une machine virtuelle qu’un locataire hostile (tenant C) loue et utilise pour des attaques. Les machines virtuelles A et VM-b sont des machines virtuelles louées par des locataires non agresseurs.

Exemple 1 : Comment le verrouillage du port du commutateur peut empêcher la prévention de l’usurpation ARP :

L’usurpation ARP est utilisée pour indiquer les tentatives d’un attaquant d’associer son adresse MAC à l’adresse IP d’un autre nœud. L’usurpation ARP peut potentiellement entraîner l’envoi du trafic du nœud à l’attaquant. Pour atteindre cet objectif, l’attaquant envoie de faux messages ARP (usurpés) à un réseau local Ethernet.

Scénario :

La machine virtuelle A (VM-a) souhaite envoyer le trafic IP de la machine virtuelle A à la machine virtuelle B (VM-b) en l’adressant à l’adresse IP de la VM-b. Le propriétaire de Virtual Machine C veut utiliser l’usurpation d’ARP pour prétendre que leur VM, VM-c, est en fait VM-b.

1. VM-c envoie un flux spéculatif de réponses ARP à VM-a. Les réponses ARP affirment que l’adresse MAC dans la réponse (C_Mac) est associée à l’adresse IP, b_IP

   Résultat : étant donné que l’administrateur a activé le verrouillage du port de commutation, ces paquets sont tous abandonnés car l’activation du verrouillage du port de commutateur empêche l’usurpation d’identité.

2. VM-b envoie une réponse ARP à VM-a, affirmant que l’adresse MAC dans la réponse (b_Mac) est associée à l’adresse IP, B_IP.

   Résultat : VM-a reçoit la réponse ARP de VM-b.

Exemple 2 : prévention de l’usurpation d’adresse IP :

L’usurpation d’adresse IP est un processus qui masque l’identité des paquets en créant des paquets IP (Internet Protocol) avec une adresse IP source falsifiée.

Scénario :

Le locataire C tente d’effectuer une attaque par déni de service en utilisant son hôte, Host-C, sur un système distant pour dissimuler son identité.

Tentative 1 :

Le locataire C définit l’adresse IP et l’adresse MAC de l’hôte C sur les adresses IP et MAC de la VM-a (a_IP et a_Mac). Le locataire C demande à Host-C d’envoyer le trafic IP à un système distant.

Résultat : les paquets Host-C sont supprimés. Cela est dû au fait que l’administrateur a activé le verrouillage du port de commutation. Les paquets Host-C sont abandonnés car l’activation du verrouillage du port de commutation empêche l’usurpation d’identité.

Tentative 2 :

Le locataire C définit l’adresse IP de l’hôte C sur l’adresse IP de la VM-a (a_IP) et conserve son C_Mac d’origine.

Le locataire C demande à Host-C d’envoyer le trafic IP à un système distant.

Résultat : les paquets Host-C sont supprimés. En effet, l’administrateur a activé le verrouillage du port de commutation, ce qui empêche l’usurpation d’identité.

Exemple 3 : hébergement Web :

Scénario :

Alice est administratrice d’infrastructure.

L’un de ses locataires, le locataire B, héberge plusieurs sites Web à partir de sa machine virtuelle, VM-b. Chaque site Web a besoin d’une adresse IP distincte hébergée sur la même interface réseau virtuelle (VIF).

Alice reconfigure le VIF de l’hôte B pour qu’il soit verrouillé sur un seul MAC mais sur de nombreuses adresses IP.

Comment fonctionne le verrouillage des ports de commutation

La fonction de verrouillage du port de commutation vous permet de contrôler le filtrage des paquets à un ou plusieurs des deux niveaux suivants :

• Niveau VIF. Les paramètres que vous configurez sur le VIF déterminent le mode de filtrage des paquets. Vous pouvez définir le VIF pour empêcher la machine virtuelle d’envoyer du trafic, restreindre le VIF afin qu’il ne puisse envoyer du trafic qu’en utilisant l’adresse IP qui lui est attribuée, ou autoriser la machine virtuelle à envoyer du trafic à n’importe quelle adresse IP du réseau connecté au VIF.

• Au niveau du réseau. Le réseau XenServer détermine la manière dont les paquets sont filtrés. Lorsque le mode de verrouillage d’un VIF est défini sur network_default, il fait référence au paramètre de verrouillage au niveau du réseau pour déterminer le trafic à autoriser.

Quelle que soit la pile réseau que vous utilisez, la fonctionnalité fonctionne de la même manière. Cependant, comme décrit plus en détail dans les sections qui suivent, le pont Linux ne prend pas entièrement en charge le verrouillage des ports de commutation en IPv6.

États du mode de verrouillage du VIF

La fonction de verrouillage des ports de commutateur XenServer fournit un mode de verrouillage qui vous permet de configurer des VIF dans quatre états différents. Ces états ne s’appliquent que lorsque le VIF est connecté à une machine virtuelle en cours d’exécution.

• Network_default. Lorsque l’état du VIF est défini sur network_default, XenServer utilise le default-locking-mode paramètre du réseau pour déterminer si et comment filtrer les paquets transitant par le VIF. Le comportement varie selon que le paramètre de mode de verrouillage par défaut du réseau associé est défini sur désactivé ou déverrouillé :

  -default-locking-mode=disabled, XenServer applique une règle de filtrage afin que le VIF supprime tout le trafic.

  -default-locking-mode=déverrouillé, XenServer supprime toutes les règles de filtrage associées au VIF. Par défaut, le paramètre de mode de verrouillage par défaut est défini sur unlocked.

  Pour plus d’informations sur le paramètre default-locking-mode, voir Commandes réseau .

  Le mode de verrouillage par défaut du réseau n’a aucun effet sur les VIF attachés dont l’état de verrouillage est autre quenetwork_default.

  Remarque :

  Vous ne pouvez pas modifier le default-locking-mode d’un réseau auquel des VIF actifs sont attachés.

• Verrouillé. XenServer applique des règles de filtrage afin que seul le trafic envoyé vers/depuis les adresses MAC et IP spécifiées soit autorisé à être envoyé via le VIF. Dans ce mode, si aucune adresse IP n’est spécifiée, la machine virtuelle ne peut pas envoyer de trafic via ce VIF, sur ce réseau.

  Pour spécifier les adresses IP à partir desquelles le VIF accepte le trafic, utilisez les adresses IP IPv4 ou IPv6 à l’aide des paramètresipv4_allowed ou ipv6_allowed. Toutefois, si le pont Linux est configuré, ne saisissez pas d’adresses IPv6.

  XenServer vous permet de saisir des adresses IPv6 lorsque le pont Linux est actif. Toutefois, XenServer ne peut pas filtrer en fonction des adresses IPv6 saisies. La raison en est que le pont Linux ne possède pas de modules pour filtrer les paquets NDP (Neighbor Discovery Protocol). Par conséquent, une protection complète ne peut pas être mise en œuvre et les invités pourraient se faire passer pour un autre invité en falsifiant des paquets NDP. Par conséquent, si vous spécifiez ne serait-ce qu’une seule adresse IPv6, XenServer laisse tout le trafic IPv6 passer par le VIF. Si vous ne spécifiez aucune adresse IPv6, XenServer ne laisse aucun trafic IPv6 passer vers le VIF.

• Déverrouillé. Tout le trafic réseau peut passer par le VIF. En d’autres termes, aucun filtre n’est appliqué au trafic entrant ou sortant du VIF.

• Désactivé. Aucun trafic n’est autorisé à passer par le VIF. (C’est-à-dire que XenServer applique une règle de filtrage afin que le VIF supprime tout le trafic.)

Configurer le verrouillage du port du commutateur

Cette section propose trois procédures différentes :

• Restreindre les VIF à utiliser une adresse IP spécifique

• Ajoutez une adresse IP à une liste restreinte existante. Par exemple, pour ajouter une adresse IP à un VIF lorsque la machine virtuelle est en cours d’exécution et connectée au réseau (par exemple, si vous déconnectez temporairement un réseau).

• Supprimer une adresse IP d’une liste restreinte existante

Si le mode de verrouillage d’un VIF est défini sur locked, il ne peut utiliser que les adresses spécifiées dans les paramètres ipv4-allowed ou ipv6-allowed.

Étant donné que, dans certains cas relativement rares, les VIF peuvent avoir plus d’une adresse IP, il est possible de spécifier plusieurs adresses IP pour un VIF.

Vous pouvez effectuer ces procédures avant ou après le branchement du VIF (ou le démarrage de la machine virtuelle).

Modifiez le mode de verrouillage par défaut sur verrouillé, s’il n’utilise pas déjà ce mode, en exécutant la commande suivante :

xe vif-param-set uuid=vif-uuid locking-mode=locked
<!--NeedCopy-->

Le vif-uuid représente l’UUID du VIF que vous souhaitez autoriser à envoyer du trafic. Pour obtenir l’UUID, exécutez la commande xe vif-list sur l’hôte. vm-uuid Indique la machine virtuelle pour laquelle les informations apparaissent. L’ID de l’appareil indique le numéro de l’appareil du VIF.

Exécutez la commande vif-param-set pour spécifier les adresses IP à partir desquelles la machine virtuelle peut envoyer du trafic. Effectuez une ou plusieurs des opérations suivantes :

• Spécifiez une ou plusieurs destinations d’adresses IP IPv4. Par exemple :

   xe vif-param-set uuid=vif-uuid ipv4-allowed=comma separated list of ipv4-addresses
   <!--NeedCopy-->
  

• Spécifiez une ou plusieurs destinations d’adresses IP IPv6. Par exemple :

   xe vif-param-set uuid=vif-uuid ipv6-allowed=comma separated list of ipv6-addresses
   <!--NeedCopy-->
  

Vous pouvez spécifier plusieurs adresses IP en les séparant par une virgule, comme indiqué dans l’exemple précédent.

Après avoir effectué la procédure visant à restreindre un VIF à l’utilisation d’une adresse IP spécifique, vous pouvez ajouter une ou plusieurs adresses IP que le VIF peut utiliser.

Exécutez la commande vif-param-add pour ajouter les adresses IP à la liste existante. Effectuez une ou plusieurs des opérations suivantes :

• Spécifiez l’adresse IP IPv4. Par exemple :

   xe vif-param-add uuid=vif-uuid ipv4-allowed=comma separated list of ipv4-addresses
   <!--NeedCopy-->
  

• Spécifiez l’adresse IP IPv6. Par exemple :

   xe vif-param-add uuid=vif-uuid ipv6-allowed=comma separated list of ipv6-addresses
   <!--NeedCopy-->
  

Si vous limitez un VIF à l’utilisation de deux adresses IP ou plus, vous pouvez supprimer l’une de ces adresses IP de la liste.

Exécutez la commande vif-param-remove pour supprimer les adresses IP de la liste existante. Effectuez une ou plusieurs des opérations suivantes :

• Spécifiez l’adresse IP IPv4 à supprimer. Par exemple :

   xe vif-param-remove uuid=vif-uuid ipv4-allowed=comma separated list of ipv4-addresses
   <!--NeedCopy-->
  

• Spécifiez l’adresse IP IPv6 à supprimer. Par exemple :

   xe vif-param-remove uuid=vif-uuid ipv6-allowed=comma separated list of ipv6-addresses
   <!--NeedCopy-->
  

Empêcher une machine virtuelle d’envoyer ou de recevoir du trafic provenant d’un réseau spécifique

La procédure suivante empêche une machine virtuelle de communiquer via un VIF spécifique. Lorsqu’un VIF se connecte à un réseau XenServer spécifique, vous pouvez utiliser cette procédure pour empêcher une machine virtuelle d’envoyer ou de recevoir du trafic en provenance d’un réseau spécifique. Cela fournit un niveau de contrôle plus granulaire que la désactivation d’un réseau entier.

Si vous utilisez la commande CLI, vous n’avez pas besoin de débrancher le VIF pour définir le mode de verrouillage du VIF. La commande modifie les règles de filtrage pendant que le VIF est en cours d’exécution. Dans ce cas, la connexion réseau semble toujours présente, cependant, le VIF supprime tous les paquets que la machine virtuelle tente d’envoyer.

Conseil :

Pour rechercher l’UUID d’un VIF, exécutez la commande xe vif-list sur l’hôte. L’ID de l’appareil indique le numéro de l’appareil du VIF.

Pour empêcher un VIF de recevoir du trafic, désactivez le VIF connecté au réseau à partir duquel vous souhaitez empêcher la machine virtuelle de recevoir du trafic :

xe vif-param-set uuid=vif-uuid locking-mode=disabled
<!--NeedCopy-->

Vous pouvez également désactiver le VIF dans XenCenter en sélectionnant l’interface réseau virtuelle dans l’onglet Mise en réseau de la machine virtuelle et en cliquant sur Désactiver.

Supprimer la restriction d’un VIF à une adresse IP

Pour revenir à l’état du mode de verrouillage par défaut (d’origine), procédez comme suit. Par défaut, lorsque vous créez un VIF, XenServer le configure de manière à ce qu’il ne soit pas limité à l’utilisation d’une adresse IP spécifique.

Pour rétablir un VIF à l’état déverrouillé, définissez le mode de verrouillage par défaut du VIF sur déverrouillé. S’il n’utilise pas déjà ce mode, exécutez la commande suivante :

xe vif-param-set uuid=vif_uuid locking-mode=unlocked
<!--NeedCopy-->

Configuration simplifiée du mode de verrouillage VIF dans le Cloud

Plutôt que d’exécuter les commandes du mode de verrouillage VIF pour chaque VIF, vous pouvez vous assurer que tous les VIF sont désactivés par défaut. Pour ce faire, vous devez modifier le filtrage des paquets au niveau du réseau. La modification du filtrage des paquets amène le réseau XenServer à déterminer comment les paquets sont filtrés, comme décrit dans la section précédente Comment fonctionne le verrouillage des ports de commutation.

Plus précisément, les paramètres default-locking-mode d’un réseau déterminent le comportement des nouveaux VIF avec des paramètres par défaut. Chaque fois qu’un VIF locking-mode est défini sur default, le VIF fait référence au mode de verrouillage du réseau (default-locking-mode) pour déterminer si et comment filtrer les paquets qui transitent par le VIF :

• Déverrouillé. Lorsque le default-locking-mode paramètre réseau est défini sur unlocked, XenServer permet à la machine virtuelle d’envoyer du trafic vers n’importe quelle adresse IP du réseau auquel le VIF se connecte.

• Désactivé. Lorsque le default-locking-mode paramètre est défini sur disabled, XenServer applique une règle de filtrage afin que le VIF supprime tout le trafic.

Par défaut, default-locking-mode pour tous les réseaux créés dans XenCenter et à l’aide de l’interface de ligne de commande sont définis sur unlocked.

En réglant le mode de verrouillage du VIF sur sa valeur par défaut (network_default), vous pouvez créer une configuration par défaut de base (au niveau du réseau) pour tous les VIF nouvellement créés qui se connectent à un réseau spécifique.

Cette illustration montre comment, lorsque le locking-mode d’un VIF est défini sur son paramètre par défaut (network_default ), le VIF utilise le réseau default-locking-mode pour déterminer son comportement.

Par exemple, par défaut, les VIF sont créés avec leur locking-mode définition sur network_default. Si vous définissez le default-locking-mode= d’un réseaudisabled, tous les nouveaux VIF pour lesquels vous n’avez pas configuré le mode de verrouillage sont désactivés. Les VIF restent désactivés jusqu’à ce que vous (a) modifiiez le locking-mode paramètre de chaque VIF ou (b) que vous définissiez explicitement les VIF locking-mode sur « déverrouillés ». Cela est utile lorsque vous faites suffisamment confiance à une machine virtuelle spécifique pour ne pas vouloir filtrer son trafic du tout.

Pour modifier le paramètre de mode de verrouillage par défaut d’un réseau :

Après avoir créé le réseau, modifiez le mode de verrouillage par défaut en exécutant la commande suivante :

xe network-param-set uuid=network-uuid default-locking-mode=[unlocked|disabled]
<!--NeedCopy-->

Remarque :

Pour obtenir l’UUID d’un réseau, exécutez la commande xe network-list. Cette commande affiche les UUID de tous les réseaux de l’hôte sur lequel vous avez exécuté la commande.

Pour vérifier le paramètre de mode de verrouillage par défaut d’un réseau :

Exécutez l’une des commandes suivantes :

xe network-param-get uuid=network-uuid param-name=default-locking-mode
<!--NeedCopy-->

OU

xe network-list uuid=network-uuid params=default-locking-mode
<!--NeedCopy-->

Utiliser les paramètres réseau pour le filtrage du trafic VIF

La procédure suivante indique à un VIF sur une machine virtuelle d’utiliser les paramètres default-locking-mode réseau XenServer sur le réseau lui-même pour déterminer comment filtrer le trafic.

1. Modifiez l’état de verrouillage du VIF sur network_default, s’il n’utilise pas déjà ce mode, en exécutant la commande suivante :

   xe vif-param-set uuid=vif_uuid locking-mode=network_default
   <!--NeedCopy-->
   

2. Modifiez le mode de verrouillage par défaut sur unlocked, s’il n’utilise pas déjà ce mode, en exécutant la commande suivante :

   xe network-param-set uuid=network-uuid default-locking-mode=unlocked
   <!--NeedCopy-->