Verwalten des Netzwerks

Wichtig:

Citrix Hypervisor 8.2 Kumulatives Update 1 wird am 25. Juni 2025 End of Life. Planen Sie jetzt Ihr Upgrade auf XenServer 8, um einen reibungslosen Übergang und kontinuierlichen Support zu gewährleisten. Weitere Informationen finden Sie unter Upgrade.

Wenn Sie Ihre Citrix Virtual Apps and Desktops-Lizenzdateien verwenden, um Ihre Citrix Hypervisor 8.2 Cumulative Update 1-Hosts zu lizenzieren, sind diese Lizenzdateien nicht mit XenServer 8 kompatibel. Vor dem Upgrade müssen Sie XenServer Premium Edition-Socket-Lizenzdateien für die Verwendung mit XenServer 8 erwerben. Diese Socket-Lizenzdateien sind als Berechtigung für die Abonnements Citrix für Private Cloud, Citrix Universal Hybrid Multi-Cloud, Citrix Universal MSP und Citrix Platform License für die Ausführung Ihrer Citrix-Workloads verfügbar. Citrix-Kunden, die noch nicht auf diese neuen Abonnements umgestiegen sind, können die Teilnahme an einer kostenlosen Aktion für 10.000 XenServer Premium Edition-Socket-Lizenzen anfordern. Weitere Informationen finden Sie unter XenServer (Englisch).

Wenn Sie vor dem Upgrade keine kompatible Lizenz für XenServer 8 erhalten, werden Ihre Hosts beim Upgrade auf die 90-Tage-Testversion zurückgesetzt. Die Testversion bietet die gleichen Funktionen wie die Premium Edition, jedoch mit einigen Einschränkungen. Weitere Informationen finden Sie unter Übersicht über die XenServer 8-Lizenzierung.

Die Netzwerkkonfigurationsverfahren in diesem Abschnitt unterscheiden sich je nachdem, ob Sie einen eigenständigen Server oder einen Server konfigurieren, der Teil eines Ressourcenpools ist.

Erstellen von Netzwerken auf einem eigenständigen Server

Da externe Netzwerke für jedes PIF während der Hostinstallation erstellt werden, ist das Erstellen zusätzlicher Netzwerke in der Regel nur für folgende Zwecke erforderlich:

• Verwenden eines privaten Netzwerks

• Unterstützung erweiterter Vorgänge wie VLANs oder NIC-Bonding

Informationen zum Hinzufügen oder Löschen von Netzwerken mit XenCenter finden Sie unter Hinzufügen eines neuen Netzwerks in der XenCenter-Dokumentation.

Öffnen Sie die Textkonsole des Citrix Hypervisor-Servers.

Erstellen Sie das Netzwerk mit dem Befehl network-create, der die UUID des neu erstellten Netzwerks zurückgibt:

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

Zu diesem Zeitpunkt ist das Netzwerk nicht mit einem PIF verbunden und daher intern.

Erstellen von Netzwerken in Ressourcenpools

Alle Citrix Hypervisor-Server in einem Ressourcenpool müssen über die gleiche Anzahl physischer Netzwerkkarten verfügen. Diese Anforderung wird nicht strikt durchgesetzt, wenn ein Host mit einem Pool verbunden ist. Eine der Netzwerkkarten wird immer als Verwaltungsschnittstelle, die für den Citrix Hypervisor-Verwaltungsdatenverkehr verwendet wird.

Da alle Hosts in einem Pool ein gemeinsames Netzwerk verwenden. Es ist wichtig, die gleiche physische Netzwerkkonfiguration für Citrix Hypervisor-Server in einem Pool zu haben. PIFs auf den einzelnen Hosts werden basierend auf dem Gerätenamen mit poolweiten Netzwerken verbunden. Beispielsweise haben alle Citrix Hypervisor-Server in einem Pool mit eth0-Netzwerkkarte einen entsprechenden PIF, der an den gesamten Pool angeschlossen ist Netzwerk 0 Netz. Das Gleiche gilt für Hosts mit eth1-Netzwerkkarten und Netzwerk 1und andere Netzwerkkarten, die in mindestens einem Citrix Hypervisor-Server im Pool vorhanden sind.

Wenn ein Citrix Hypervisor-Server über eine andere Anzahl von Netzwerkkarten verfügt als andere Hosts im Pool, kann es zu Komplikationen kommen. Die Komplikationen können auftreten, da nicht alle Poolnetzwerke für alle Poolhosts gültig sind. Wenn beispielsweise Hosts Gastgeber1 und host2 sich im selben Pool befinden und Gastgeber1 verfügt über vier Netzwerkkarten und host2 hat nur zwei, nur die Netzwerke, die mit PIFs verbunden sind, die eth0 und eth1 entsprechen, sind gültig auf host2. VMs auf Gastgeber1 mit VIFs, die mit Netzwerken verbunden sind, die eth2 und eth3 entsprechen, können nicht auf den Host migriert werden host2.

Erstellen von VLANs

Für Server in einem Ressourcenpool können Sie die pool-vlan-erstellen Befehl. Dieser Befehl erstellt das VLAN und erstellt automatisch die erforderlichen PIFs auf den Hosts im Pool und fügt sie hinzu. Weitere Informationen finden Sie unter pool-vlan-erstellen.

Öffnen Sie die Citrix Hypervisor-Serverkonsole.

Erstellen Sie ein Netzwerk für die Verwendung mit dem VLAN. Die UUID des neuen Netzwerks wird zurückgegeben:

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

Verwenden Sie die Schaltfläche pif-liste , um die UUID des PIF zu finden, die der physischen Netzwerkkarte entspricht, die das gewünschte VLAN-Tag unterstützt. Die UUIDs und Gerätenamen aller PIFs werden zurückgegeben, einschließlich aller vorhandenen VLANs:

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

Erstellen Sie ein VLAN-Objekt, das das gewünschte physische PIF und VLAN-Tag auf allen VMs angibt, die mit dem neuen VLAN verbunden werden sollen. Ein neuer PIF wird erstellt und an das angegebene Netzwerk angeschlossen. Die UUID des neuen PIF-Objekts wird zurückgegeben.

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

Fügen Sie VM-VIFs an das neue Netzwerk an. Weitere Informationen finden Sie unter Erstellen von Netzwerken auf einem eigenständigen Server.

Erstellen von NIC-Bindungen auf einem eigenständigen Host

Wir empfehlen die Verwendung von XenCenter zum Erstellen von NIC-Bindungen. Weitere Informationen finden Sie unter Konfigurieren von Netzwerkkarten.

In diesem Abschnitt wird beschrieben, wie Sie die xe CLI verwenden, um NIC-Schnittstellen auf Citrix Hypervisor-Servern zu binden, die sich nicht in einem Pool befinden. Informationen zur Verwendung der xe CLI zum Erstellen von NIC-Bindungen auf Citrix Hypervisor-Servern, die einen Ressourcenpool umfassen, finden Sie unter Erstellen von NIC-Bindungen in Ressourcenpools.

Erstellen einer NIC-Bindung

Wenn Sie eine Netzwerkkarte verbinden, absorbiert die Bindung die PIF/NIC, die als Verwaltungsschnittstelle verwendet wird. Die Verwaltungsschnittstelle wird automatisch in den Bond-PIF verschoben.

1. Verwenden Sie die Schaltfläche network-create , um ein Netzwerk für die Verwendung mit der gebundenen Netzwerkkarte zu erstellen. Die UUID des neuen Netzwerks wird zurückgegeben:

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

2. Verwenden Sie die Schaltfläche pif-liste , um die UUIDs der PIFs zu bestimmen, die in der Bindung verwendet werden sollen:

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

3. Führen Sie einen der folgenden Schritte aus:

   • Um die Bindung im Aktiv-Aktiv-Modus (Standard) zu konfigurieren, verwenden Sie die Schaltfläche Bindung-Erstellen , um die Bindung zu erstellen. Geben Sie unter Verwendung von Kommas zur Trennung der Parameter die neu erstellte Netzwerk-UUID und die UUIDs der zu bindenden PIFs an:

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

     Geben Sie zwei UUIDs ein, wenn Sie zwei Netzwerkkarten verbinden, und vier UUIDs, wenn Sie vier Netzwerkkarten verbinden. Die UUID für die Bindung wird nach dem Ausführen des Befehls zurückgegeben.

   • Um die Bindung im Aktiv-Passiv- oder LACP-Bindungsmodus zu konfigurieren, verwenden Sie die gleiche Syntax, fügen Sie das optionale Modus und geben Sie LACP oder aktives-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-->
     

Steuern Sie die MAC-Adresse der Anleihe

Wenn Sie die Verwaltungsschnittstelle binden, wird die PIF/Netzwerkkarte zusammengefasst, die als Verwaltungsschnittstelle verwendet wird. Wenn der Host DHCP verwendet, ist die MAC-Adresse der Bindung mit der verwendeten PIF/NIC identisch. Die IP-Adresse der Verwaltungsschnittstelle kann unverändert bleiben.

Sie können die MAC-Adresse der Bindung so ändern, dass sie sich von der MAC-Adresse für die (aktuelle) Verwaltungsschnittstellen-NIC unterscheidet. Wenn die Bindung jedoch aktiviert ist und sich die verwendete MAC/IP-Adresse ändert, werden vorhandene Netzwerksitzungen mit dem Host verworfen.

Sie können die MAC-Adresse für eine Bindung auf zwei Arten steuern:

• Ein optionaler mac kann im Parameter Bindung-Erstellen Befehl. Sie können diesen Parameter verwenden, um die MAC-Adresse der Bindung auf eine beliebige Adresse festzulegen.

• Wenn die Option mac Parameter nicht angegeben ist, verwendet Citrix Hypervisor die MAC-Adresse der Verwaltungsschnittstelle, wenn es sich um eine der Schnittstellen in der Bindung handelt. Wenn die Verwaltungsschnittstelle nicht Teil der Bindung ist, aber eine andere Verwaltungsschnittstelle, verwendet die Bindung die MAC-Adresse (und auch die IP-Adresse) dieser Verwaltungsschnittstelle. Wenn es sich bei keiner der Netzwerkkarten in der Bindung um eine Verwaltungsschnittstelle handelt, verwendet die Bindung die MAC der ersten benannten Netzwerkkarte.

NIC-Anleihen rückgängig machen

Beim Zurücksetzen des Citrix Hypervisor-Servers auf eine nicht gebundene Konfiguration wird die Bindung-zerstören konfiguriert automatisch die primäre Netzwerkkarte als Schnittstelle für die Verwaltungsschnittstelle. Daher werden alle VIFs in die Verwaltungsschnittstelle verschoben. Wenn sich die Verwaltungsschnittstelle eines Hosts auf einer getaggten VLAN-gebundenen Schnittstelle befindet, wird bei der Ausführung Bindung-zerstörenwird das Management-VLAN in die primäre Netzwerkkarte verschoben.

Der Begriff primäre Netzwerkkarte bezieht sich auf den PIF, von dem die MAC- und IP-Konfiguration beim Erstellen der Bindung kopiert wurde. Beim Verbinden von zwei Netzwerkkarten besteht die primäre Netzwerkkarte wie folgt aus:

1. Die Verwaltungsschnittstellen-NIC (wenn es sich bei der Verwaltungsschnittstelle um eine der gebundenen Netzwerkkarten handelt).

2. Jede andere Netzwerkkarte mit einer IP-Adresse (wenn die Verwaltungsschnittstelle nicht Teil der Bindung war).

3. Die erste benannte NIC. Sie können herausfinden, um welche es sich handelt, indem Sie Folgendes ausführen:

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

Erstellen von NIC-Bindungen in Ressourcenpools

Erstellen Sie nach Möglichkeit NIC-Bindungen als Teil der anfänglichen Erstellung des Ressourcenpools, bevor Sie weitere Hosts mit dem Pool verknüpfen oder VMs erstellen. Auf diese Weise kann die Bindungskonfiguration automatisch auf Hosts repliziert werden, wenn diese mit dem Pool verbunden werden, und die Anzahl der erforderlichen Schritte wird reduziert.

Für das Hinzufügen einer NIC-Bindung zu einem vorhandenen Pool ist eine der folgenden Aufgaben erforderlich:

• Verwenden der CLI zum Konfigurieren der Bindungen auf dem Master und dann auf jedem Mitglied des Pools.

• Verwenden der CLI zum Konfigurieren von Bindungen auf dem Master und anschließendes Neustarten jedes Poolmitglieds, sodass es seine Einstellungen vom Master erbt.

• Verwenden von XenCenter zum Konfigurieren der Bindungen auf dem Master. XenCenter synchronisiert automatisch die Netzwerkeinstellungen auf den Mitgliedsservern mit dem Master, sodass Sie die Mitgliedsserver nicht neu starten müssen.

Der Einfachheit halber und um Fehlkonfigurationen zu vermeiden, empfehlen wir die Verwendung von XenCenter zum Erstellen von NIC-Bonds. Weitere Informationen finden Sie unter Konfigurieren von Netzwerkkarten.

In diesem Abschnitt wird die Verwendung der xe CLI zum Erstellen von gebundenen NIC-Schnittstellen auf Citrix Hypervisor-Servern beschrieben, die einen Ressourcenpool umfassen. Informationen zur Verwendung der xe CLI zum Erstellen von NIC-Bonds auf einem eigenständigen Host finden Sie unter Erstellen von NIC-Bindungen auf einem eigenständigen Host.

Warnung:

Versuchen Sie nicht, Netzwerkbindungen zu erstellen, wenn die Hochverfügbarkeit aktiviert ist. Der Prozess der Bindungserstellung stört den laufenden Hochverfügbarkeits-Heartbeat und führt dazu, dass Hosts sich selbst eingrenzen. Die Hosts können nicht ordnungsgemäß neu gestartet werden und benötigen möglicherweise die host-notfall-ha-deaktivieren Befehl zur Wiederherstellung.

Wählen Sie den Host aus, der als Master fungieren soll. Der Masterhost gehört standardmäßig zu einem unbenannten Pool. Um einen Ressourcenpool mit der CLI zu erstellen, benennen Sie den vorhandenen namenlosen Pool um:

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

Erstellen Sie die NIC-Bindung, wie unter Erstellen einer NIC-Bindung.

Öffnen Sie eine Konsole auf einem Host, den Sie dem Pool hinzufügen möchten, und führen Sie den folgenden Befehl aus:

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

Die Netzwerk- und Bindungsinformationen werden automatisch auf den neuen Host repliziert. Die Verwaltungsschnittstelle wird automatisch von der Host-Netzwerkkarte, auf der sie ursprünglich konfiguriert wurde, in die gebundene PIF verschoben. Das heißt, die Verwaltungsschnittstelle wird nun in die Bindung integriert, so dass die gesamte Bindung als Verwaltungsschnittstelle fungiert.

Verwenden Sie die Schaltfläche host-liste , um die UUID des zu konfigurierenden Hosts zu finden:

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

Warnung:

Versuchen Sie nicht, Netzwerkbindungen zu erstellen, während die Hochverfügbarkeit aktiviert ist. Der Prozess der Bindungserstellung stört den laufenden Hochverfügbarkeits-Heartbeat und führt dazu, dass Hosts sich selbst eingrenzen. Die Hosts können nicht ordnungsgemäß neu gestartet werden, und Sie müssen möglicherweise die host-notfall-ha-deaktivieren Befehl zur Wiederherstellung.

Konfigurieren einer dedizierten Speicher-NIC

Sie können XenCenter oder die xe CLI verwenden, um einer Netzwerkkarte eine IP-Adresse zuzuweisen und sie einer bestimmten Funktion zuzuweisen, z. B. Speicherdatenverkehr. Wenn Sie eine Netzwerkkarte mit einer IP-Adresse konfigurieren, erstellen Sie dazu eine sekundäre Schnittstelle. (Die IP-fähige Netzwerkkarte Citrix Hypervisor, die für die Verwaltung verwendet wird, wird als Verwaltungsschnittstelle bezeichnet.)

Wenn Sie eine sekundäre Schnittstelle für einen bestimmten Zweck zuweisen möchten, stellen Sie sicher, dass die entsprechende Netzwerkkonfiguration vorhanden ist. Dadurch soll sichergestellt werden, dass die Netzwerkkarte nur für den gewünschten Datenverkehr verwendet wird. Um eine Netzwerkkarte für den Speicherdatenverkehr zu reservieren, konfigurieren Sie die Netzwerkkarte, das Speicherziel, den Switch und das VLAN so, dass das Ziel nur über die zugewiesene Netzwerkkarte zugänglich ist. Wenn Ihre physische und IP-Konfiguration den über die Speicher-NIC gesendeten Datenverkehr nicht einschränkt, können Sie Datenverkehr, z. B. Verwaltungsdatenverkehr, über die sekundäre Schnittstelle senden.

Wenn Sie eine neue sekundäre Schnittstelle für den Speicherdatenverkehr erstellen, müssen Sie ihr eine IP-Adresse zuweisen, die wie folgt lautet:

• Im selben Subnetz wie der Speichercontroller, falls zutreffend, und

• Sie befinden sich nicht im selben Subnetz wie alle anderen sekundären Schnittstellen oder die Verwaltungsschnittstelle.

Wenn Sie sekundäre Schnittstellen konfigurieren, muss sich jede sekundäre Schnittstelle in einem separaten Subnetz befinden. Wenn Sie z. B. zwei weitere sekundäre Schnittstellen für den Speicher konfigurieren möchten, benötigen Sie IP-Adressen in drei verschiedenen Subnetzen – einem Subnetz für die Verwaltungsschnittstelle, einem Subnetz für die sekundäre Schnittstelle 1 und einem Subnetz für die sekundäre Schnittstelle 2.

Wenn Sie Bonding für die Resilienz Ihres Speicherdatenverkehrs verwenden, sollten Sie die Verwendung von LACP anstelle des Linux-Bridge-Bondings in Betracht ziehen. Um LACP-Bonding zu verwenden, müssen Sie den vSwitch als Netzwerk-Stack konfigurieren. Weitere Informationen finden Sie unter vSwitch-Netzwerke.

Hinweis:

Wenn Sie eine Netzwerkkarte auswählen, die als sekundäre Schnittstelle für die Verwendung mit iSCSI- oder NFS-SRs konfiguriert werden soll, stellen Sie sicher, dass die dedizierte Netzwerkkarte ein separates IP-Subnetz verwendet, das nicht über die Verwaltungsschnittstelle geroutet werden kann. Wenn dies nicht erzwungen wird, kann der Speicherdatenverkehr nach einem Neustart des Hosts aufgrund der Reihenfolge, in der Netzwerkschnittstellen initialisiert werden, über die Hauptverwaltungsschnittstelle geleitet werden.

Stellen Sie sicher, dass sich der PIF in einem separaten Subnetz befindet oder das Routing entsprechend Ihrer Netzwerktopologie konfiguriert ist, um den gewünschten Datenverkehr über den ausgewählten PIF zu erzwingen.

Richten Sie eine IP-Konfiguration für den PIF ein, und fügen Sie entsprechende Werte für den Parameter mode hinzu. Wenn Sie eine statische IP-Adressierung verwenden, fügen Sie die Parameter IP, Netzmaske, Gateway und DNS hinzu:

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

Legen Sie den disallow-unplug-Parameter des PIF auf true fest:

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

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

Wenn Sie eine sekundäre Schnittstelle für den Speicher verwenden möchten, die auch über die Verwaltungsschnittstelle weitergeleitet werden kann (wobei zu beachten ist, dass diese Konfiguration nicht die bewährte Methode ist), haben Sie zwei Möglichkeiten:

• Stellen Sie nach einem Neustart des Hosts sicher, dass die sekundäre Schnittstelle korrekt konfiguriert ist. Verwenden Sie die Schaltfläche xe pbd-unstecker und XE PBD-Stecker Befehle, um die Speicherverbindungen auf dem Host neu zu initialisieren. Mit diesem Befehl wird die Speicherverbindung neu gestartet und über die richtige Schnittstelle weitergeleitet.

• Alternativ können Sie auch xe pif-forget , um die Schnittstelle aus der Citrix Hypervisor-Datenbank zu löschen und manuell in der Steuerungsdomäne zu konfigurieren. xe pif-forget ist eine erweiterte Option und erfordert, dass Sie mit der manuellen Konfiguration des Linux-Netzwerks vertraut sind.

Verwenden von SR-IOV-fähigen Netzwerkkarten

Single Root I/O Virtualization (SR-IOV) ist eine Virtualisierungstechnologie, die es ermöglicht, dass ein einzelnes PCI-Gerät als mehrere PCI-Geräte auf dem physischen System angezeigt wird. Das eigentliche physische Gerät wird als Physical Function (PF) bezeichnet, während die anderen als Virtual Functions (VF) bezeichnet werden. Der Hypervisor kann einer Virtual Machine (VM) einen oder mehrere VFs zuweisen: Der Gast kann das Gerät dann so nutzen, als wäre es direkt zugewiesen.

Durch das Zuweisen eines oder mehrerer Netzwerkkarten-VFs zu einer VM kann der Netzwerkdatenverkehr den virtuellen Switch umgehen. Nach der Konfiguration verhält sich jede VM so, als würde sie die Netzwerkkarte direkt verwenden, wodurch der Verarbeitungsaufwand reduziert und die Leistung verbessert wird.

Vorteile von SR-IOV

Ein SR-IOV VF hat eine bessere Leistung als VIF. Es kann die hardwarebasierte Trennung zwischen Datenverkehr von verschiedenen VMs über dieselbe Netzwerkkarte sicherstellen (unter Umgehung des Citrix Hypervisor-Netzwerkstapels).

Mit dieser Funktion können Sie:

• Aktivieren Sie SR-IOV auf Netzwerkkarten, die SR-IOV unterstützen.

• Deaktivieren Sie SR-IOV auf Netzwerkkarten, die SR-IOV unterstützen.

• Verwalten Sie SR-IOV-VFs als VF-Ressourcenpool.

• Weisen Sie einer VM SR-IOV-VFs zu.

• Konfigurieren Sie SR-IOV-VFs (z. B. MAC-Adresse, VLAN, Rate).

• Führen Sie Tests durch, um zu bestätigen, ob SR-IOV als Teil des Automated Certification Kit unterstützt wird.

Systemkonfiguration

Konfigurieren Sie die Hardwareplattform korrekt, um SR-IOV zu unterstützen. Folgende Technologien werden benötigt:

• I/O-MMU-Virtualisierung (AMD-Vi und Intel VT-d)

• Alternative Routing-ID-Interpretation (ARI)

• Adressübersetzungsdienste (ATS)

• Zugriffskontrolldienste (ACS)

In der Dokumentation Ihres Systems finden Sie Informationen zur Konfiguration des BIOS, um die genannten Technologien zu aktivieren.

Aktivieren eines SR-IOV-Netzwerks auf einer Netzwerkkarte

Verwenden Sie in XenCenter die Neues Netzwerk Assistent im Feld Vernetzung , um ein SR-IOV-Netzwerk auf einer Netzwerkkarte zu erstellen und zu aktivieren.

Zuweisen eines SR-IOV-Netzwerks zur virtuellen Schnittstelle (VM-Ebene)

Verwenden Sie in XenCenter auf VM-Ebene die Virtuelle Schnittstelle hinzufügen Assistent im Feld Vernetzung , um ein SR-IOV-fähiges Netzwerk als virtuelle Schnittstelle für diese VM hinzuzufügen. Weitere Informationen finden Sie unter Hinzufügen eines neuen Netzwerks.

Unterstützte Netzwerkkarten und Gäste

Eine Liste der unterstützten Hardwareplattformen und Netzwerkkarten finden Sie unter Hardware-Kompatibilitätsliste. In der vom Anbieter für einen bestimmten Gast bereitgestellten Dokumentation finden Sie Informationen dazu, ob SR-IOV unterstützt wird.

Begrenzungen

• Bei bestimmten Netzwerkkarten, die Legacy-Treiber verwenden (z. B. Intel I350-Familie), muss der Host neu gestartet werden, um SR-IOV auf diesen Geräten zu aktivieren oder zu deaktivieren.

• Nur HVM-Gäste werden mit SR-IOV unterstützt.

• Ein SR-IOV-Netzwerk auf Poolebene mit unterschiedlichen Arten von Netzwerkkarten wird nicht unterstützt.

• Ein SR-IOV-VF und ein normaler VIF von derselben Netzwerkkarte können aufgrund der Hardwareeinschränkungen der Netzwerkkarte möglicherweise nicht miteinander kommunizieren. Damit diese Hosts kommunizieren können, stellen Sie sicher, dass die Kommunikation das Muster VF zu VF oder VIF zu VIF und nicht VF zu VIF verwendet.

• Die Quality of Service-Einstellungen für einige SR-IOV-VFs werden nicht wirksam, da sie die Begrenzung der Netzwerkgeschwindigkeit nicht unterstützen.

• Das Durchführen von Livemigration, Anhalten und Prüfpunkten wird auf VMs, die eine SR-IOV-VF verwenden, nicht unterstützt.

• SR-IOV-VFs unterstützen kein Hot-Plugging.

• Bei einigen Netzwerkkarten mit älteren Netzwerkkartentreibern ist möglicherweise auch nach dem Neustart des Hosts ein Neustart erforderlich, was darauf hinweist, dass die Netzwerkkarte SR-IOV nicht aktivieren kann.

• VMs, die in früheren Versionen erstellt wurden, können diese Funktion von XenCenter nicht verwenden.

• Wenn Ihre VM über einen SR-IOV-VF verfügt, sind Funktionen, die eine Livemigration erfordern, nicht möglich. Dies liegt daran, dass die VM direkt an die physische SR-IOV-fähige Netzwerkkarte VF gebunden ist.

• Hardwareeinschränkung: Die SR-IOV-Funktion verlässt sich darauf, dass der Controller die Gerätefunktionen innerhalb von 100 ms auf einen ursprünglichen Zustand zurücksetzt, wenn dies vom Hypervisor mit Function Level Reset (FLR) angefordert wird.

• SR-IOV kann in einer Umgebung verwendet werden, die Hochverfügbarkeit nutzt. SR-IOV wird in der Kapazitätsplanung jedoch nicht berücksichtigt. VMs, denen SR-IOV-VFs zugewiesen sind, werden nach bestem Wissen und Gewissen neu gestartet, wenn ein Host im Pool vorhanden ist, der über die entsprechenden Ressourcen verfügt. Zu diesen Ressourcen gehören SR-IOV, das im richtigen Netzwerk aktiviert ist, und ein kostenloses VF.

Konfigurieren von SR-IOV-VFs für Legacy-Treiber

In der Regel kann die maximale Anzahl von VFs, die eine Netzwerkkarte unterstützen kann, automatisch bestimmt werden. Für Netzwerkkarten, die Legacy-Treiber verwenden (z. B. Intel I350-Familie), wird der Grenzwert in der Konfigurationsdatei des Treibermoduls definiert. Das Limit muss möglicherweise manuell angepasst werden. Um es auf das Maximum einzustellen, öffnen Sie die Datei mit einem Editor und ändern Sie den Zeilenanfang:

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

Um beispielsweise die maximalen VFs auf 4 für die IGB Treiber bearbeiten /etc/modprobe.d/igb.conf Zu lesen:

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

Hinweise:

• Der Wert muss kleiner oder gleich dem Wert in der Zeile sein VFs-maxvfs-standardmäßig.

• Ändern Sie keine andere Zeile in diesen Dateien.

• Nehmen Sie die Änderungen vor, bevor Sie SR-IOV aktivieren.

CLI

Siehe SR-IOV-Befehle für CLI-Anweisungen zum Erstellen, Löschen, Anzeigen von SR-IOV-Netzwerken und Zuweisen eines SR-IOV VF zu einer VM.

Steuern der Rate ausgehender Daten (QoS)

Um die Menge von aufgeschlossen Daten, die eine VM pro Sekunde senden kann, legen Sie einen optionalen QoS-Wert (Quality of Service) für virtuelle VM-Schnittstellen (VIFs) fest. Mit dieser Einstellung können Sie eine maximale Übertragungsrate für ausgehende Pakete in Kilobyte pro Sekunde.

Der Quality of Service-Wert begrenzt die Übertragungsrate Von die VM. Die Einstellung “Quality of Service” schränkt die Datenmenge, die der virtuelle Computer empfangen kann, nicht ein. Wenn ein solches Limit gewünscht wird, empfehlen wir, die Rate eingehender Pakete weiter oben im Netzwerk (z. B. auf Switch-Ebene) zu begrenzen.

Abhängig vom im Pool konfigurierten Netzwerkstapel können Sie den Quality of Service-Wert für virtuelle VM-Schnittstellen (VIFs) an einer von zwei Stellen festlegen. Sie können diesen Wert entweder über die xe CLI oder in XenCenter festlegen.

• XenCenter (Englisch) Sie können den Grenzwert für die Quality of Service-Übertragungsrate im Eigenschaftendialogfeld für die virtuelle Schnittstelle festlegen.
• XE-Befehle Sie können die Quality of Service-Übertragungsrate mithilfe der CLI mit den Befehlen im folgenden Abschnitt festlegen.

Beispiel für einen CLI-Befehl für QoS

Um eine VIF mithilfe der CLI auf eine maximale Übertragungsrate von 100 Kilobyte pro Sekunde zu begrenzen, verwenden Sie die vif-param-set Befehl:

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

Hinweis:

Das Kbps Parameter bezeichnet Kilobyte pro Sekunde (kBps), nicht Kilobit pro Sekunde (kbit/s).

Ändern der Netzwerkkonfigurationsoptionen

In diesem Abschnitt wird erläutert, wie Sie die Netzwerkkonfiguration Ihres Citrix Hypervisor-Servers ändern. Es beinhaltet:

• Ändern des Hostnamens (d. h. des DNS-Namens (Domain Name System))

• Hinzufügen oder Löschen von DNS-Servern

• Ändern von IP-Adressen

• Ändern, welche Netzwerkkarte als Verwaltungsschnittstelle verwendet wird

• Hinzufügen einer neuen physischen Netzwerkkarte zum Server

• Hinzufügen eines Zwecks zu einem Netzwerk

• Aktivieren der ARP-Filterung (Switch-Port-Sperre)

Hostname

Der Systemhostname, der auch als Domänen- oder DNS-Name bezeichnet wird, wird in der poolweiten Datenbank definiert und mit dem xe host-set-hostname-live CLI-Befehl wie folgt ausführen:

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

Der Hostname der zugrunde liegenden Steuerdomäne ändert sich dynamisch, um den neuen Hostnamen widerzuspiegeln.

DNS-Server

Um DNS-Server in der IP-Adressierungskonfiguration des Citrix Hypervisor-Servers hinzuzufügen oder zu löschen, verwenden Sie die pif-reconfigure-ip Befehl. Beispiel: Für ein PIF mit einer statischen IP-Adresse:

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

Ändern der IP-Adresskonfiguration für einen eigenständigen Host

Sie können die xe CLI verwenden, um die Konfiguration der Netzwerkschnittstelle zu ändern. Ändern Sie die zugrunde liegenden Netzwerkkonfigurationsskripts nicht direkt.

Um die IP-Adresskonfiguration einer PIF zu ändern, verwenden Sie die Schaltfläche pif-reconfigure-ip CLI-Befehl. Siehe pif-reconfigure-ip Weitere Informationen zu den Parametern der pif-reconfigure-ip Befehl. Im folgenden Abschnitt finden Sie Informationen zum Ändern von Host-IP-Adressen in Ressourcenpools.

Ändern der IP-Adresskonfiguration in Ressourcenpools

Citrix Hypervisor-Server in Ressourcenpools verfügen über eine einzige Verwaltungs-IP-Adresse, die für die Verwaltung und Kommunikation mit und von anderen Hosts im Pool verwendet wird. Die Schritte, die zum Ändern der IP-Adresse der Verwaltungsschnittstelle eines Hosts erforderlich sind, unterscheiden sich für Master- und andere Hosts.

Hinweis:

Sie müssen vorsichtig sein, wenn Sie die IP-Adresse eines Servers und andere Netzwerkparameter ändern. Abhängig von der Netzwerktopologie und der vorgenommenen Änderung können Verbindungen zum Netzwerkspeicher verloren gehen. In diesem Fall muss der Speicher mit dem Befehl Speicher reparieren in XenCenter oder mit der Funktion PBD-Stecker CLI-Befehl. Aus diesem Grund wird empfohlen, VMs vom Server weg zu migrieren, bevor Sie die IP-Konfiguration ändern.

Verwenden Sie die Schaltfläche pif-reconfigure-ip CLI-Befehl, um die IP-Adresse wie gewünscht festzulegen. Siehe pif-reconfigure-ip Weitere Informationen zu den Parametern der pif-reconfigure-ip Befehl. :

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

Verwenden Sie die Schaltfläche host-liste CLI-Befehl, um zu bestätigen, dass der Mitgliedshost erfolgreich wieder mit dem Masterhost verbunden wurde, indem überprüft wird, ob alle anderen Citrix Hypervisor-Server im Pool sichtbar sind:

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

Das Ändern der IP-Adresse des Citrix Hypervisor-Masterservers erfordert zusätzliche Schritte. Dies liegt daran, dass jedes Poolmitglied die angekündigte IP-Adresse des Poolmasters für die Kommunikation verwendet. Die Poolmitglieder wissen nicht, wie sie den Master kontaktieren können, wenn sich seine IP-Adresse ändert.

Verwenden Sie nach Möglichkeit eine dedizierte IP-Adresse, die sich während der Lebensdauer des Pools für Poolmaster wahrscheinlich nicht ändert.

Verwenden Sie die Schaltfläche pif-reconfigure-ip CLI-Befehl zum Festlegen der IP-Adresse wie gewünscht:

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

Wenn sich die IP-Adresse des Poolmasters ändert, wechseln alle Mitgliedshosts in den Notfallmodus, wenn sie keine Verbindung zum Masterhost herstellen können.

Verwenden Sie auf dem Poolmaster die Schaltfläche pool-recover-slaves -Befehl, um den Master zu zwingen, jedes Pool-Mitglied zu kontaktieren und sie über die neue Master-IP-Adresse zu informieren:

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

Verwaltungsschnittstelle

Wenn Sie Citrix Hypervisor auf einem Host installieren, wird eine seiner Netzwerkkarten als Verwaltungsschnittstelle: Die Netzwerkkarte, die für den Citrix Hypervisor-Verwaltungsdatenverkehr verwendet wird. Die Verwaltungsschnittstelle wird für XenCenter- und andere Verwaltungs-API-Verbindungen mit dem Host (z. B. Citrix Virtual Apps and Desktops) und für die Host-to-Host-Kommunikation verwendet.

Verwenden Sie die Schaltfläche pif-liste , um zu bestimmen, welche PIF der Netzwerkkarte entspricht, die als Verwaltungsschnittstelle verwendet werden soll. Die UUID jedes PIF wird zurückgegeben.

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

Verwenden Sie die Schaltfläche pif-param-liste , um die IP-Adressierungskonfiguration für den PIF zu überprüfen, der für die Verwaltungsschnittstelle verwendet wird. Verwenden Sie bei Bedarf die Schaltfläche pif-reconfigure-ip , um die IP-Adressierung für den zu verwendenden PIF zu konfigurieren.

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

Verwenden Sie die Schaltfläche host-management-neu konfigurieren CLI-Befehl zum Ändern des PIF, der für die Verwaltungsschnittstelle verwendet wird. Wenn dieser Host Teil eines Ressourcenpools ist, Dieser Befehl muss in der Hostkonsole des Mitglieds ausgegeben werden:

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

Verwenden Sie die Schaltfläche Netzwerk-Liste , um zu bestimmen, welche PIF der Netzwerkkarte entspricht, die als Verwaltungsschnittstelle für alle Hosts im Pool verwendet werden soll. Die UUID des poolweiten Netzwerks wird zurückgegeben.

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

Verwenden Sie die Schaltfläche network-param-list , um die PIF-UUIDs aller Hosts im Pool abzurufen. Verwenden Sie die Schaltfläche pif-param-liste , um die IP-Adressierungskonfiguration für den PIF für die Verwaltungsschnittstelle zu überprüfen. Verwenden Sie bei Bedarf die Schaltfläche pif-reconfigure-ip , um die IP-Adressierung für den zu verwendenden PIF zu konfigurieren.

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

Verwenden Sie die Schaltfläche pool-management-neu konfigurieren CLI-Befehl, um den PIF zu ändern, der für die Verwaltungsschnittstelle verwendet wird, die in der Liste Netzwerke aufgeführt ist.

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

Einschränken der Verwendung von Port 80

Sie können entweder HTTPS über Port 443 oder HTTP über Port 80 verwenden, um mit Citrix Hypervisor zu kommunizieren. Aus Sicherheitsgründen können Sie den TCP-Port 80 auf der Verwaltungsschnittstelle schließen. Standardmäßig ist Port 80 noch geöffnet. Wenn Sie es schließen, müssen alle externen Clients, die die Verwaltungs-API verwenden, HTTPS über Port 443 verwenden, um eine Verbindung mit Citrix Hypervisor herzustellen. Überprüfen Sie jedoch vor dem Schließen von Port 80, ob alle API-Clients (insbesondere Citrix Virtual Apps and Desktops) HTTPS über Port 443 verwenden können.

Informationen zum Schließen von Port 80 finden Sie in der Nur https xe CLI-Befehl oder Ändern der Pooleigenschaften in der XenCenter-Dokumentation.

Deaktivieren des Verwaltungszugriffs

Um den Remotezugriff auf die Verwaltungskonsole vollständig zu deaktivieren, verwenden Sie die Schaltfläche host-verwaltung-deaktivieren CLI-Befehl.

Warnung:

Wenn die Verwaltungsschnittstelle deaktiviert ist, müssen Sie sich an der physischen Hostkonsole anmelden, um Verwaltungsaufgaben ausführen zu können. Externe Schnittstellen wie XenCenter funktionieren nicht, wenn die Verwaltungsschnittstelle deaktiviert ist.

Hinzufügen einer neuen physischen Netzwerkkarte

1. Installieren Sie eine neue physische Netzwerkkarte auf Ihrem Citrix Hypervisor-Server wie gewohnt.
2. Starten Sie Ihren Citrix Hypervisor-Server neu.

3. Listen Sie alle physischen Netzwerkkarten für diesen Citrix Hypervisor-Server auf, indem Sie den folgenden Befehl verwenden:

     xe pif-list host-uuid=<host_uuid>
   

4. Wenn die zusätzliche Netzwerkkarte nicht angezeigt wird, suchen Sie mit dem folgenden Befehl nach neuen physischen Schnittstellen:

     xe pif-scan host-uuid=<host_uuid>
   

   Mit diesem Befehl wird ein neues PIF-Objekt für die neue Netzwerkkarte erstellt.

5. Listen Sie die physischen Netzwerkkarten auf dem Citrix Hypervisor-Server erneut auf, um zu überprüfen, ob die neue Netzwerkkarte sichtbar ist:

     xe pif-list host-uuid=<host_uuid>
   

6. Der neue PIF wird zunächst als getrennt aufgeführt (aktuell angehängt ( RO): falsch). Um es aufzurufen, verwenden Sie den folgenden Befehl:

     xe pif-plug uuid=<uuid_of_pif>
   

Alternativ können Sie XenCenter verwenden, um erneut nach neuen Netzwerkkarten zu suchen. Weitere Informationen finden Sie unter Konfigurieren von Netzwerkkarten in der XenCenter-Dokumentation.

Entfernen einer physischen Netzwerkkarte

Stellen Sie vor dem Entfernen der Netzwerkkarte sicher, dass Sie die UUID der entsprechenden PIF kennen. Entfernen Sie die physische Netzwerkkarte wie gewohnt von Ihrem Citrix Hypervisor-Server. Führen Sie nach dem Neustart des Servers den Befehl xe CLI aus pif-forget uuid=<UUID> , um das PIF-Objekt zu zerstören.

Hinzufügen eines Zwecks zu einem Netzwerk

Der Netzwerkzweck kann verwendet werden, um einem Netzwerk zusätzliche Funktionen hinzuzufügen. Zum Beispiel die Möglichkeit, das Netzwerk zu verwenden, um NBD-Verbindungen herzustellen.

Um einen Netzwerkzweck hinzuzufügen, verwenden Sie die Schaltflächexe network-param-add Befehl:

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

Um einen Netzwerkzweck zu löschen, verwenden Sie die Schaltflächexe netzwerk-param-entfernen Befehl:

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

Derzeit sind die verfügbaren Werte für den Netzwerkzweck nbd und insecure_nbd. Weitere Informationen finden Sie in der Citrix Hypervisor Leitfaden zur Nachverfolgung geänderter Blöcke.

Verwenden der Switch-Port-Sperre

Mit der Citrix Hypervisor-Switch-Port-Sperrfunktion können Sie den Datenverkehr steuern, der von unbekannten, nicht vertrauenswürdigen oder potenziell feindlichen VMs gesendet wird, indem Sie deren Fähigkeit einschränken, so zu tun, als hätten sie eine MAC- oder IP-Adresse, die ihnen nicht zugewiesen wurde. Sie können die Befehle zum Sperren von Ports verwenden, um den gesamten Datenverkehr in einem Netzwerk standardmäßig zu blockieren oder bestimmte IP-Adressen zu definieren, von denen eine einzelne VM Datenverkehr senden darf.

Durch die Verwendung von Switch-Port-Sperren können Sie Ihre Netzwerkkonfiguration vereinfachen, indem Sie allen Ihren Mandanten oder Gästen die Verwendung desselben Layer-2-Netzwerks ermöglichen.

Eine der wichtigsten Funktionen der Port-Locking-Befehle besteht darin, dass sie den Datenverkehr einschränken können, den ein nicht vertrauenswürdiger Gast sendet. Dies schränkt die Möglichkeit des Gastes ein, so zu tun, als hätte er eine MAC- oder IP-Adresse, die er nicht besitzt. Insbesondere können Sie diese Befehle verwenden, um zu verhindern, dass ein Gast Folgendes tut:

• Beanspruchen einer anderen IP- oder MAC-Adresse als denen, die der Citrix Hypervisor-Administrator angegeben hat, die er verwenden kann

• Abfangen, Spoofing oder Unterbrechen des Datenverkehrs anderer VMs

Anforderungen

• Die Citrix Hypervisor-Switch-Port-Sperrfunktion wird auf der Linux-Bridge und den vSwitch-Netzwerkstacks unterstützt.

• Wenn Sie die rollenbasierte Zugriffssteuerung (Role Based Access Control, RBAC) in Ihrer Umgebung aktivieren, muss der Benutzer, der die Switch-Port-Sperre konfiguriert, mit einem Konto angemeldet sein, das mindestens über die Rolle “Pool-Operator” oder “Pool-Administrator” verfügt. Wenn RBAC in Ihrer Umgebung nicht aktiviert ist, muss der Benutzer mit dem Stammkonto für den Poolmaster angemeldet sein.

• Wenn Sie die Befehle zum Sperren von switch-ports ausführen, können Netzwerke online oder offline sein.

• In Windows-Gästen wird das Symbol für das getrennte Netzwerk nur angezeigt, wenn XenServer VM Tools auf dem Gast installiert sind.

Hinweise

Ohne Switch-Port-Sperrkonfigurationen werden VIFs auf “network_default” und Netzwerke auf “entsperrt” gesetzt.

Das Konfigurieren von Switch-Port-Sperren wird nicht unterstützt, wenn Controller von Drittanbietern in der Umgebung verwendet werden.

Die Switch-Port-Sperre hindert Cloud-Mandanten nicht daran, Folgendes zu tun:

• Ausführen eines Angriffs auf IP-Ebene auf einen anderen Mandanten/Benutzer. Die Switch-Port-Sperre verhindert jedoch, dass sie den Angriff auf IP-Ebene durchführen, wenn sie versuchen, dies mit den folgenden Mitteln zu tun, und die Switch-Port-Sperre konfiguriert ist: a) sich als ein anderer Mandant oder Benutzer ausgeben oder b) ein Abfangen des Datenverkehrs initiieren, der für einen anderen Benutzer bestimmt ist.

• Erschöpfung der Netzwerkressourcen.

• Empfangen von Datenverkehr, der für andere virtuelle Maschinen bestimmt ist, durch normales Switch-Flooding-Verhalten (für Broadcast-MAC-Adressen oder unbekannte Ziel-MAC-Adressen).

Ebenso schränkt die Switch-Port-Sperre nicht ein, wohin eine VM Datenverkehr senden kann.

Hinweise zur Implementierung

Sie können die Switch-Port-Sperrfunktion entweder über die Befehlszeile oder die Citrix Hypervisor-API implementieren. In großen Umgebungen, in denen die Automatisierung ein Hauptanliegen ist, ist die typischste Implementierungsmethode jedoch die Verwendung der API.

Beispiele

In diesem Abschnitt finden Sie Beispiele dafür, wie die Switch-Port-Sperre bestimmte Arten von Angriffen verhindern kann. In diesen Beispielen handelt es sich bei VM-c um einen virtuellen Computer, den ein feindlicher Mandant (Mandant C) mietet und für Angriffe verwendet. VM-a und VM-b sind virtuelle Maschinen, die von nicht angreifenden Mandanten geleast werden.

Beispiel 1: Wie die Switch-Port-Sperre die Verhinderung von ARP-Spoofing verhindern kann:

ARP-Spoofing wird verwendet, um die Versuche eines Angreifers anzuzeigen, seine MAC-Adresse mit der IP-Adresse eines anderen Knotens zu verknüpfen. ARP-Spoofing kann möglicherweise dazu führen, dass der Datenverkehr des Knotens stattdessen an den Angreifer gesendet wird. Um dieses Ziel zu erreichen, sendet der Angreifer gefälschte (gefälschte) ARP-Nachrichten an ein Ethernet-LAN.

Szenario:

Virtueller Computer A (VM-a) möchte IP-Datenverkehr von VM-a an Virtual Machine B (VM-b) senden, indem er an die IP-Adresse von VM-b adressiert wird. Der Besitzer von Virtual Machine C möchte ARP-Spoofing verwenden, um so zu tun, als wäre seine VM VM-c tatsächlich VM-b.

1. VM-c sendet einen spekulativen Strom von ARP-Antworten an VM-a. In den ARP-Antworten wird behauptet, dass die MAC-Adresse in der Antwort (c_MAC) mit der IP-Adresse verknüpft ist, b_IP

   Ergebnis: Da der Administrator die Switch-Port-Sperre aktiviert hat, werden alle diese Pakete verworfen, da durch die Aktivierung der Switch-Port-Sperre ein Identitätswechsel verhindert wird.

2. VM-b sendet eine ARP-Antwort an VM-a und behauptet, dass die MAC-Adresse in der Antwort (b_MAC) mit der IP-Adresse verknüpft ist, b_IP.

   Ergebnis: VM-a erhält die ARP-Antwort von VM-b.

Beispiel 2: Verhinderung von IP-Spoofing:

IP-Adressen-Spoofing ist ein Prozess, bei dem die Identität von Paketen verschleiert wird, indem IP-Pakete (Internet Protocol) mit einer gefälschten Quell-IP-Adresse erstellt werden.

Szenario:

Mandant C versucht, einen Denial-of-Service-Angriff mit seinem Host Host-C auf einem Remotesystem durchzuführen, um seine Identität zu verschleiern.

Versuch 1:

Mandant C legt die IP-Adresse und MAC-Adresse von Host-C auf die IP- und MAC-Adressen von VM-a (a_IP und a_MAC) fest. Mandant C weist Host-C an, IP-Datenverkehr an ein Remotesystem zu senden.

Ergebnis: Die Host-C-Pakete werden verworfen. Dies liegt daran, dass der Administrator die Switch-Port-Sperre aktiviert hat. Die Host-C-Pakete werden verworfen, da durch das Aktivieren der Switch-Port-Sperre ein Identitätswechsel verhindert wird.

Versuch 2:

Mandant C legt die IP-Adresse von Host-C auf die IP-Adresse (a_IP) von VM-a fest und behält die ursprüngliche c_MAC bei.

Mandant C weist Host-C an, IP-Datenverkehr an ein Remotesystem zu senden.

Ergebnis: Die Host-C-Pakete werden verworfen. Dies liegt daran, dass der Administrator die Switch-Port-Sperre aktiviert hat, die den Identitätswechsel verhindert.

Beispiel 3: Webhosting:

Szenario:

Alice ist Infrastrukturadministratorin.

Einer ihrer Mandanten, Mandant B, hostet mehrere Websites von seiner VM VM-b aus. Jede Website benötigt eine eindeutige IP-Adresse, die auf derselben virtuellen Netzwerkschnittstelle (Virtual Network Interface, VIF) gehostet wird.

Alice konfiguriert die VIF von Host-B so, dass sie an eine einzige MAC-Adresse, aber viele IP-Adressen gebunden ist.

Funktionsweise der Switch-Port-Sperre

Mit der Switch-Port-Sperrfunktion können Sie die Paketfilterung auf einer oder mehreren von zwei Ebenen steuern:

• VIF-Stufe. Die Einstellungen, die Sie in der VIF konfigurieren, bestimmen, wie Pakete gefiltert werden. Sie können die VIF so festlegen, dass die VM keinen Datenverkehr sendet, die VIF so einschränken, dass sie nur Datenverkehr mit der zugewiesenen IP-Adresse senden kann, oder der VM erlauben, Datenverkehr an eine beliebige IP-Adresse im Netzwerk zu senden, das mit der VIF verbunden ist.

• Netzwerk-Ebene. Das Citrix Hypervisor-Netzwerk bestimmt, wie Pakete gefiltert werden. Wenn der Sperrmodus eines VIF auf network_default, bezieht sie sich auf die Sperreinstellung auf Netzwerkebene, um zu bestimmen, welcher Datenverkehr zugelassen werden soll.

Unabhängig davon, welchen Netzwerk-Stack Sie verwenden, funktioniert die Funktion auf die gleiche Weise. Wie jedoch in den folgenden Abschnitten ausführlicher beschrieben, unterstützt die Linux-Bridge die Switch-Port-Sperre in IPv6 nicht vollständig.

Zustände im VIF-Sperrmodus

Die Citrix Hypervisor-Switch-Port-Sperrfunktion bietet einen Sperrmodus, mit dem Sie VIFs in vier verschiedenen Zuständen konfigurieren können. Diese Zustände gelten nur, wenn die VIF an eine laufende virtuelle Maschine angeschlossen ist.

• Network_default. Wenn der Status des VIF auf network_defaultverwendet Citrix Hypervisor die default-locking-mode , um zu bestimmen, ob und wie Pakete gefiltert werden sollen, die durch das VIF laufen. Das Verhalten hängt davon ab, ob für das zugeordnete Netzwerk der Parameter für den Standardsperrmodus des Netzwerks auf deaktiviert oder entsperrt festgelegt ist:

  -default-locking-mode=arbeitsunfähigwendet Citrix Hypervisor eine Filterregel an, sodass die VIF den gesamten Datenverkehr verwirft.

  -default-locking-mode=entsperrt, entfernt Citrix Hypervisor alle Filterregeln, die dem VIF zugeordnet sind. Standardmäßig ist der Standardparameter für den Sperrmodus auf unverschlossen.

  Für Informationen über die default-locking-mode , siehe Netzwerk-Befehle.

  Der standardmäßige Sperrmodus des Netzwerks hat keine Auswirkungen auf angehängte VIFs, deren Sperrstatus etwas anderes ist als network_default.

  Hinweis:

  Sie können die default-locking-mode eines Netzwerks, an das aktive VIFs angehängt sind.

• Verschlossen. Citrix Hypervisor wendet Filterregeln an, sodass nur Datenverkehr, der an / von den angegebenen MAC- und IP-Adressen gesendet wird, über das VIF gesendet werden darf. Wenn in diesem Modus keine IP-Adressen angegeben sind, kann die VM keinen Datenverkehr über dieses VIF in diesem Netzwerk senden.

  Um die IP-Adressen anzugeben, von denen die VIF Datenverkehr akzeptiert, verwenden Sie die IPv4- oder IPv6-IP-Adressen, indem Sie die ipv4_allowed oder ipv6_allowed Parameter. Wenn Sie jedoch die Linux-Bridge konfiguriert haben, geben Sie keine IPv6-Adressen ein.

  Mit Citrix Hypervisor können Sie IPv6-Adressen eingeben, wenn die Linux-Bridge aktiv ist. Citrix Hypervisor kann jedoch nicht basierend auf den eingegebenen IPv6-Adressen filtern. Der Grund dafür ist, dass die Linux-Bridge nicht über Module zum Filtern von NDP-Paketen (Neighbor Discovery Protocol) verfügt. Daher kann kein vollständiger Schutz implementiert werden, und Gäste könnten sich durch Fälschen von NDP-Paketen als ein anderer Gast ausgeben. Wenn Sie also auch nur eine IPv6-Adresse angeben, lässt Citrix Hypervisor den gesamten IPv6-Datenverkehr durch das VIF leiten. Wenn Sie keine IPv6-Adressen angeben, lässt Citrix Hypervisor keinen IPv6-Datenverkehr an das VIF weiter.

• Unverschlossen. Der gesamte Netzwerkverkehr kann über das VIF geleitet werden. Das heißt, es werden keine Filter auf den Datenverkehr angewendet, der zum oder vom VIF geht.

• Arbeitsunfähig. Es darf kein Verkehr durch das VIF geleitet werden. (Das heißt, Citrix Hypervisor wendet eine Filterregel an, sodass die VIF den gesamten Datenverkehr verwirft.)

Konfigurieren der Switch-Port-Sperre

In diesem Abschnitt werden drei verschiedene Verfahren beschrieben:

• Beschränken Sie VIFs auf die Verwendung einer bestimmten IP-Adresse

• Fügen Sie einer vorhandenen eingeschränkten Liste eine IP-Adresse hinzu. Zum Beispiel, um einer VIF eine IP-Adresse hinzuzufügen, wenn die VM ausgeführt wird und mit dem Netzwerk verbunden ist (z. B. wenn Sie ein Netzwerk vorübergehend offline schalten).

• Entfernen einer IP-Adresse aus einer vorhandenen eingeschränkten Liste

Wenn der Sperrmodus eines VIF auf verschlossenkönnen nur die Adressen verwendet werden, die in der IPv4-zugelassen oder IPv6-zugelassen Parameter.

Da VIFs in einigen relativ seltenen Fällen mehr als eine IP-Adresse haben können, ist es möglich, mehrere IP-Adressen für ein VIF anzugeben.

Sie können diese Verfahren vor oder nach dem Einstecken der VIF (oder dem Starten des virtuellen Computers) ausführen.

Ändern Sie den Standardsperrmodus in gesperrt, wenn dieser Modus noch nicht verwendet wird, indem Sie den folgenden Befehl ausführen:

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

Das vif-uuid stellt die UUID der VIF dar, die Sie zum Senden von Datenverkehr zulassen möchten. Um die UUID zu erhalten, führen Sie die xe vif-liste auf dem Host. vm-uuid Gibt den virtuellen Computer an, für den die Informationen angezeigt werden. Die Geräte-ID gibt die Gerätenummer des VIF an.

Führen Sie die Option vif-param-set , um die IP-Adressen anzugeben, von denen die virtuelle Maschine Datenverkehr senden kann. Führen Sie einen oder mehrere der folgenden Schritte aus:

• Geben Sie ein oder mehrere IPv4-IP-Adressziele an. Beispiel:

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

• Geben Sie ein oder mehrere IPv6-IP-Adressziele an. Beispiel:

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

Sie können mehrere IP-Adressen angeben, indem Sie sie durch ein Komma trennen, wie im vorherigen Beispiel gezeigt.

Nachdem Sie das Verfahren zum Einschränken einer VIF auf die Verwendung einer bestimmten IP-Adresse ausgeführt haben, können Sie eine oder mehrere IP-Adressen hinzufügen, die von der VIF verwendet werden können.

Führen Sie die Option vif-param-hinzufügen , um die IP-Adressen zur vorhandenen Liste hinzuzufügen. Führen Sie einen oder mehrere der folgenden Schritte aus:

• Geben Sie die IPv4-IP-Adresse an. Beispiel:

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

• Geben Sie die IPv6-IP-Adresse an. Beispiel:

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

Wenn Sie eine VIF auf die Verwendung von zwei oder mehr IP-Adressen beschränken, können Sie eine dieser IP-Adressen aus der Liste löschen.

Führen Sie die Option vif-param-entfernen , um die IP-Adressen aus der vorhandenen Liste zu löschen. Führen Sie einen oder mehrere der folgenden Schritte aus:

• Geben Sie die zu löschende IPv4-IP-Adresse an. Beispiel:

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

• Geben Sie die zu löschende IPv6-IP-Adresse an. Beispiel:

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

Verhindern, dass ein virtueller Computer Datenverkehr aus einem bestimmten Netzwerk sendet oder empfängt

Das folgende Verfahren verhindert, dass eine virtuelle Maschine über ein bestimmtes VIF kommuniziert. Wenn eine VIF eine Verbindung zu einem bestimmten Citrix Hypervisor-Netzwerk herstellt, können Sie dieses Verfahren verwenden, um zu verhindern, dass eine virtuelle Maschine Datenverkehr von einem bestimmten Netzwerk sendet oder empfängt. Dies bietet ein detaillierteres Maß an Kontrolle als das Deaktivieren eines gesamten Netzwerks.

Wenn Sie den CLI-Befehl verwenden, müssen Sie die VIF nicht vom Stromnetz trennen, um den Sperrmodus der VIF festzulegen. Der Befehl ändert die Filterregeln, während die VIF ausgeführt wird. In diesem Fall scheint die Netzwerkverbindung weiterhin vorhanden zu sein, die VIF verwirft jedoch alle Pakete, die die VM zu senden versucht.

Tipp:

Um die UUID eines VIF zu finden, führen Sie die xe vif-liste auf dem Host. Die Geräte-ID gibt die Gerätenummer des VIF an.

Um zu verhindern, dass eine VIF Datenverkehr empfängt, deaktivieren Sie die VIF, die mit dem Netzwerk verbunden ist, von dem aus Sie verhindern möchten, dass die VM Datenverkehr empfängt:

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

Sie können die VIF auch in XenCenter deaktivieren, indem Sie die virtuelle Netzwerkschnittstelle auf der Registerkarte Netzwerk der VM auswählen und auf Deaktivieren klicken.

Entfernen der Beschränkung eines VIF auf eine IP-Adresse

Gehen Sie folgendermaßen vor, um den standardmäßigen (ursprünglichen) Zustand des Sperrmodus wiederherzustellen. Wenn Sie ein VIF erstellen, konfiguriert Citrix Hypervisor es standardmäßig so, dass es nicht auf die Verwendung einer bestimmten IP-Adresse beschränkt ist.

Um eine VIF wieder in den gesperrten Zustand zu versetzen, ändern Sie den VIF-Standardsperrmodus in entsperrt. Wenn dieser Modus noch nicht verwendet wird, führen Sie den folgenden Befehl aus:

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

Vereinfachen Sie die Konfiguration des VIF-Sperrmodus in der Cloud

Anstatt die Befehle für den VIF-Sperrmodus für jedes VIF auszuführen, können Sie sicherstellen, dass alle VIFs standardmäßig deaktiviert sind. Dazu müssen Sie die Paketfilterung auf Netzwerkebene ändern. Wenn Sie die Paketfilterung ändern, bestimmt das Citrix Hypervisor-Netzwerk, wie Pakete gefiltert werden, wie im vorherigen Abschnitt beschrieben Funktionsweise der Switch-Port-Sperre.

Konkret wird die default-locking-mode bestimmt, wie sich neue VIFs mit Standardeinstellungen verhalten. Wann immer ein VIF Locking-Modus ist auf Vorgabebezieht sich die VIF auf den Netzwerksperrmodus (default-locking-mode), um zu bestimmen, ob und wie Pakete, die durch das VIF laufen, gefiltert werden sollen:

• Unverschlossen. Wenn das Netzwerk default-locking-mode ist auf unverschlossenermöglicht Citrix Hypervisor der VM, Datenverkehr an eine beliebige IP-Adresse im Netzwerk zu senden, mit dem die VIF eine Verbindung herstellt.

• Arbeitsunfähig. Wenn die Option default-locking-mode ist auf arbeitsunfähigwendet Citrix Hypervisor eine Filterregel an, sodass die VIF den gesamten Datenverkehr verwirft.

Standardmäßig wird die default-locking-mode für alle Netzwerke, die in XenCenter erstellt wurden und die CLI verwenden, auf unverschlossen.

Indem Sie den Sperrmodus des VIF auf den Standardmodus (network_default) können Sie eine grundlegende Standardkonfiguration (auf Netzwerkebene) für alle neu erstellten VIFs erstellen, die eine Verbindung zu einem bestimmten Netzwerk herstellen.

Diese Abbildung zeigt, wie und wie ein VIF Locking-Modus auf die Standardeinstellung (network_default) verwendet die VIF das Netzwerk default-locking-mode um sein Verhalten zu bestimmen.

Standardmäßig werden VIFs beispielsweise mit ihren Locking-Modus auf network_default. Wenn Sie die default-locking-mode=arbeitsunfähig, werden alle neuen VIFs, für die Sie den Sperrmodus nicht konfiguriert haben, deaktiviert. Die VIFs bleiben deaktiviert, bis Sie entweder (a) die einzelnen VIFs ändern Locking-Modus oder (b) die VIF explizit Locking-Modus auf ‘entsperrt. Dies ist hilfreich, wenn Sie einer bestimmten VM ausreichend vertrauen und den Datenverkehr überhaupt nicht filtern möchten.

So ändern Sie die Standardeinstellung für den Sperrmodus eines Netzwerks:

Ändern Sie nach dem Erstellen des Netzwerks den Standardsperrmodus, indem Sie den folgenden Befehl ausführen:

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

Hinweis:

Um die UUID für ein Netzwerk abzurufen, führen Sie die Datei xe Netzwerk-Liste Befehl. Mit diesem Befehl werden die UUIDs für alle Netzwerke auf dem Host angezeigt, auf dem Sie den Befehl ausgeführt haben.

So überprüfen Sie die Standardeinstellung für den Sperrmodus eines Netzwerks:

Führen Sie einen der folgenden Befehle aus:

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

ODER

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

Verwenden der Netzwerkeinstellungen für die Filterung des VIF-Datenverkehrs

Das folgende Verfahren weist eine VIF auf einer virtuellen Maschine an, das Citrix Hypervisor-Netzwerk zu verwenden default-locking-mode Einstellungen im Netzwerk selbst, um zu bestimmen, wie der Datenverkehr gefiltert werden soll.

1. Ändern Sie den VIF-Sperrstatus in network_default, wenn dieser Modus noch nicht verwendet wird, indem Sie den folgenden Befehl ausführen:

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

2. Ändern Sie den Standardsperrmodus in unverschlossen, wenn dieser Modus noch nicht verwendet wird, indem Sie den folgenden Befehl ausführen:

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