Mehrere Netzwerkschnittstellen

Diese Seite enthält eine Übersicht über VM-Instanzen mit mehreren Netzwerkschnittstellen sowie Beschreibungen ihrer Funktionsweise und Konfigurationsbeispiele. Informationen zum Erstellen von Konfigurationen mit mehreren Schnittstellen finden Sie unter VMs mit mehreren Netzwerkschnittstellen erstellen.

Google Cloud Virtual Private Cloud-Netzwerke sind standardmäßig isolierte private Netzwerk-Domains. Netzwerke haben einen globalen Geltungsbereich und enthalten regionale Subnetze. VM-Instanzen innerhalb eines VPC-Netzwerks können über interne IP-Adressen untereinander kommunizieren, sofern die Firewallregeln dies zulassen. Die Kommunikation zwischen Netzwerken über interne IP-Adressen ist allerdings nur zulässig, wenn Sie Funktionen wie VPC Network Peering oder Cloud VPN einrichten.

Jede Instanz in einem VPC-Netzwerk hat eine Standardnetzwerkschnittstelle. Wenn Sie eine Netzwerkschnittstelle konfigurieren, wählen Sie ein VPC-Netzwerk und ein Subnetz innerhalb dieses VPC-Netzwerks aus, mit dem die Schnittstelle verbunden werden soll. Sie können zusätzliche Netzwerkschnittstellen erstellen, die an Ihre VMs angehängt sind, aber jede Schnittstelle muss an ein anderes VPC-Netzwerk angehängt werden. Mit mehreren Netzwerkschnittstellen sind Konfigurationen möglich, bei denen eine Instanz eine direkte Verbindung zu mehreren VPC-Netzwerken herstellt.

Jede Instanz kann je nach Instanztyp bis zu acht Schnittstellen haben. Weitere Informationen finden Sie unter Maximale Anzahl von Netzwerkschnittstellen.

Für jede Schnittstelle können die folgenden IP-Adressen konfiguriert sein:

  • Eine interne IPv4-Adresse (erforderlich)
  • Eine externe IPv4-Adresse
  • Eine IPv6-Adresse, entweder intern oder extern, aber nicht beides

    Zum Konfigurieren einer IPv6-Adresse müssen Sie die Schnittstelle mit einem Subnetz verbinden, für das ein IPv6-Bereich konfiguriert ist.

In der Regel benötigen Sie mehrere Schnittstellen, wenn Sie eine Instanz als Netzwerk-Appliance konfigurieren möchten, die Funktionen wie Load-Balancing, Einbruchserkennung und -prävention (IDS/IPS), Web Application Firewall (WAF) oder die WAN-Optimierung zwischen Netzwerken umfasst. Mehrere Netzwerkschnittstellen sind auch nützlich, wenn Anwendungen, die auf einer Instanz ausgeführt werden, eine Traffictrennung wie die Trennung des Traffics auf Daten- und Verwaltungsebene erfordern.

Jede Schnittstelle einer VM ist von der MTU des zugehörigen Netzwerks betroffen. Weitere Informationen zur Schnittstellen-MTU finden Sie unter Maximale Übertragungseinheit.

Anwendungsfälle

Verwenden Sie mehrere Netzwerkschnittstellen, wenn eine einzelne Instanz Zugriff auf mehr als ein VPC-Netzwerk benötigt, Sie aber nicht beide Netzwerke direkt verbinden möchten.

  • Netzwerk- und Sicherheitsfunktion: Mehrere Netzwerkschnittstellen ermöglichen virtualisierte Netzwerk-Appliance-Funktionen wie Lastenausgleich, NAT-Server (Network Address Translation) und Proxyserver, die mit mehreren Netzwerkschnittstellen konfiguriert sind. Weitere Informationen finden Sie unter Beispiel 1: Virtual Appliances für Netzwerke und Sicherheit.

  • Perimeter-Isolierung (auch DMZ-Isolation genannt): Eine wichtige Best Practice in mehrstufigen Netzwerkarchitekturen ist die Isolation der öffentlichen Dienste von einem internen Netzwerk und dessen Diensten. Verwenden Sie mehrere Netzwerkschnittstellen für Konfigurationen mit separaten Netzwerkschnittstellen auf der Instanz, von denen eine den öffentlichen Traffic und die andere den privaten Backend-Traffic mit restriktiverer Zugriffssteuerung verarbeitet.

    Alle Ressourcen, auf die aus dem Internet zugegriffen werden kann, sollten von Ihrem internen Netzwerk und dessen Diensten getrennt sein. Auf diese Weise reduzieren Sie den Zugriffsbereich und die Gefahr von Schäden, die eine Sicherheitsverletzung verursachen kann, erheblich. Beispielsweise können Sie eine zweite Netzwerkschnittstelle auf jedem Webserver einrichten, der mit einem Netzwerk mittlerer Ebene verbunden ist, in dem ein Anwendungsserver ausgeführt wird. Der Anwendungsserver kann gleichzeitig in einem Backend-Netzwerk vorhanden sein (Dual Homing), in dem sich der Datenbankserver befindet. Jede Dual-Homed-Instanz empfängt und verarbeitet Anfragen auf dem Frontend, baut die Verbindung zum Backend auf und sendet dann die Anfragen zu den Servern im Backend-Netzwerk.

    Durch separate Konfiguration der öffentlichen und privaten Schnittstellen können Sie auf jede Schnittstelle eigene Firewallregeln und Zugriffskontrollen anwenden sowie Sicherheitsfunktionen für die Kommunikation der öffentlichen Domain mit der privaten Domain einrichten. Weitere Informationen finden Sie unter Beispiel 2: Drittanbieter-Appliances in einem Szenario mit einem freigegebenen VPC-Netzwerk verwenden.

Konfigurationsbeispiele

In diesem Abschnitt finden Sie verschiedene allgemeine Beispiele für den Einsatz mehrerer Netzwerkschnittstellen.

Beispiel 1: Virtual Appliances für Netzwerke und Sicherheit

Virtual Appliances für Netzwerke und Sicherheit, wie Web Application Firewall (WAF), Firewalls auf Sicherheitsanwendungsebene und WAN-Beschleuniger, werden in der Regel mit mehreren virtuellen Schnittstellen konfiguriert. Jede dieser Schnittstellen hat ihre eigene interne IP-Adresse sowie optional eine eigene externen IP-Adresse.

Abbildung 1 beschreibt eine Beispielkonfiguration einer Firewall auf Anwendungsebene, die den Traffic aus dem Internet zu einem VPC-Netzwerk steuert. Die Firewall auf Anwendungsebene ist in Compute Engine-VMs implementiert.

In diesem Beispiel wurde die Standardroute der Appliance-VM für die Verwendung von nic1 konfiguriert.

Abbildung 1. Eine Instanz mit einer VM-Appliance hat drei Netzwerkschnittstellen. Jede Schnittstelle ist mit einem Subnetz verbunden, das sich in einem anderen VPC-Netzwerk befindet (zum Vergrößern klicken).

Instanzen für Beispiel 1 bereitstellen und konfigurieren

Im Folgenden wird davon ausgegangen, dass subnet0, subnet1 und subnet2 bereits vorhanden sind und sich keine Bereiche überschneiden.

Erstellen Sie die VM und die Netzwerkschnittstellen in diesem Beispiel mit dem folgenden Befehl:

gcloud compute instances create vm-appliance \
    --network-interface subnet=subnet0,no-address \
    --network-interface subnet=subnet1 \
    --network-interface subnet=subnet2,no-address \
    --machine-type n1-standard-4

Mit diesem Befehl erstellen Sie eine Instanz mit drei Netzwerkschnittstellen:

  • nic0 ist an subnet0 gebunden und hat keine externe IP-Adresse.
  • nic1 ist an subnet1 gebunden und hat eine sitzungsspezifische externe IP-Adresse.
  • nic2 ist an subnet2 gebunden und hat keine externe IP-Adresse.

Beispiel 2: Drittanbieter-Appliances in einem Szenario mit einem freigegebenen VPC-Netzwerk verwenden

Diese Konfiguration ist hilfreich, wenn Sie eine einzelne Gruppe zentraler Drittanbieter-Appliances für Arbeitslasten oder Anwendungen gemeinsam nutzen möchten, die in verschiedenen Projekten gehostet werden. In Abbildung 2 gibt es vier verschiedene Anwendungen – App1, App2, App3 und App4 –, die in verschiedenen Dienstprojekten gehostet werden. Diese Anwendungen sollen vor eingehendem Internettraffic geschützt werden. Außerdem soll der ausgehende Traffic von einer Drittanbieter-Appliance geprüft und gefiltert werden, die sich zentral im Hostprojekt der freigegebenen VPC befindet.

Abbildung 2. Eine Instanz in einem freigegebenen VPC-Hostprojekt hostet eine VM-Appliance. Die Instanz hat für jedes der vier Dienstprojekte eine Netzwerkschnittstelle und für das VPC-Netzwerk des Netzwerkperimeters eine weitere Schnittstelle (zum Vergrößern klicken).

VM und Netzwerkschnittstellen für Beispiel 2 bereitstellen und konfigurieren

Erstellen Sie die VM und die Netzwerkschnittstellen in diesem Beispiel mit dem folgenden Befehl:

gcloud compute instances create VM-appliance \
    --network-interface subnet=subnet-perimeter,address='reserved-address' \
    --network-interface subnet=subnet-1,no-address \
    --network-interface subnet=subnet-2,no-address \
    --network-interface subnet=subnet-3,no-address \
    --network-interface subnet=subnet-4,no-address \
    --machine-type=n1-standard-4

So wird eine Instanz mit fünf Netzwerkschnittstellen erstellt:

  • nic0 ist mit einer statischen Adresse reserved-address an subnet-perimeter angehängt, das wiederum Teil von network-perimeter ist.
  • nic1 ist ohne externe IP-Adresse an subnet-1 angehängt, das wiederum Teil von network-1 ist.
  • nic2 ist ohne externe IP-Adresse an subnet-2 angehängt, das wiederum Teil von network-2 ist.
  • nic3 ist ohne externe IP-Adresse an subnet-3 angehängt, das wiederum Teil von network-3 ist.
  • nic4 ist ohne externe IP-Adresse an subnet-4 angehängt, das wiederum Teil von network-4 ist.

Weitere operative Details

Mehrere Netzwerkschnittstellen in einer Umgebung mit freigegebener VPC

Mit einer freigegebenen VPC können Sie VPC-Netzwerke projektübergreifend für Ihre Google Cloud-Organisation freigeben.

Sie haben damit die Möglichkeit, Instanzen zu erstellen und einem freigegebenen VPC-Netzwerk zuzuordnen, das in einem zentralen Hostprojekt mit freigegebener VPC gehostet ist. Informationen zum Konfigurieren von freigegebenen VPC-Netzwerken finden Sie unter Freigegebene VPC bereitstellen.

Sie müssen am freigegebenen VPC-Hostprojekt die Rolle Compute Network-Nutzerrolle (roles/compute.networkUser) haben, um Instanzen mit einer oder mehreren Schnittstellen zu erstellen, die freigegebenen VPC-Netzwerken zugeordnet sind.

DNS-Auflösung mit mehreren Netzwerkschnittstellen

Bei einer internen DNS-Abfrage mit dem Hostnamen der Instanz wird der Name in die primäre Schnittstelle (nic0) der Instanz aufgelöst. Wenn die Schnittstelle nic0 der Instanz mit einem Subnetz in einem VPC-Netzwerk verknüpft ist, das sich vom VPC-Netzwerk der Instanz unterscheidet, die die interne DNS-Abfrage sendet, schlägt die Abfrage fehl.

Private Compute Engine DNS-Datensätze werden nicht pro Schnittstelle generiert.

DHCP-Verhalten mit mehreren Netzwerkschnittstellen

In einer Standardkonfiguration mit mehreren Schnittstellen ist das Betriebssystem für die Verwendung von DHCP konfiguriert. Das DHCP- und ARP-Verhalten der einzelnen Schnittstellen entspricht dem auf einer Instanz mit nur einer Schnittstelle.

Auf einer Instanz mit mehreren Schnittstellen, die DHCP verwendet, erhält jede Schnittstelle eine Route für das Subnetz, in dem es sich befindet. Zusätzlich erhält die Instanz eine einzelne Standardroute, die der primären Schnittstelle eth0 zugeordnet ist. Sofern nicht manuell anders konfiguriert, wird sämtlicher Traffic, der von der Instanz zu beliebigen Zielen mit Ausnahme eines direkt verbundenen Subnetzes verläuft, über die Standardroute auf eth0 geleitet.

Das Verhalten ist bei Schnittstellen mit IPv6-Adressen das gleiche. Die Schnittstelle erhält eine Route für den IPv6-Subnetzbereich, in dem sie sich befindet, sowie eine einzelne IPv6-Standardroute.

In diesem Beispiel erhält die primäre Schnittstelle eth0 die Standardroute (default via 10.138.0.1 dev eth0) und beide Schnittstellen eth0 und eth1 erhalten Routen für ihre jeweiligen Subnetze.

instance-1:~$ ip route
default via 10.138.0.1 dev eth0
10.137.0.0/20 via 10.137.0.1 dev eth1
10.137.0.1 dev eth1 scope link
10.138.0.0/20 via 10.138.0.1 dev eth0
10.138.0.1 dev eth0 scope link

Weitere Informationen finden Sie im Abschnitt Richtlinienrouting konfigurieren.

Benutzerdefinierte statische Routen und mehrere Netzwerkschnittstellen

Wenn eine VM-Instanz mehrere Schnittstellen und ein Netzwerktag hat, wirkt sich das Netzwerktag möglicherweise nicht auf alle Schnittstellen der VM aus. Das Netzwerktag einer VM wirkt sich nur auf eine Schnittstelle aus, wenn sich die Schnittstelle in einem VPC-Netzwerk befindet, das eine benutzerdefinierte statische Route mit einem passenden Tag enthält.

Beispiel:

  1. Eine VM hat zwei Schnittstellen: nic0 und nic1. Die Schnittstelle nic0 befindet sich in vpc-net-a. Die Schnittstelle nic1 befindet sich in vpc-net-b. Die VM hat ein Netzwerktag namens vpn-ok. Das Tag ist ein Attribut auf der Instanz und nicht auf einer bestimmten Schnittstelle.
  2. Das Netzwerk vpc-net-a hat eine benutzerdefinierte statische Route mit einem Tag namens vpn-ok.
  3. Das Netzwerk vpc-net-b hat eine benutzerdefinierte statische Route mit einem Tag namens vpn-123.

Diese nummerierten Schritte entsprechen Abbildung 3:

Abbildung 3. Die benutzerdefinierte statische Route in vpc-net-a wirkt sich auf nic0 aus, da sie ein gemeinsames Tag haben, während die benutzerdefinierte statische Route in vpc-net-b keine Auswirkungen auf nic1 hat (zum Vergrößern klicken).

Da das Netzwerk vpc-net-a eine Route mit einem Tag gemeinsam mit der VM hat, gilt das vpn-ok-Tag der VM für die nic0-Schnittstelle der VM in vpc-net-a. Da das Netzwerk vpc-net-b keine statische Route mit dem Tag vpn-ok hat, wird das Netzwerktag vpn-ok der VM auf der Schnittstelle nic1 der VM ignoriert.

Tags für Routen in Instanzen mit mehreren Netzwerkschnittstellen verwenden

Wenn Sie Tags in Routen verwenden möchten, müssen Sie beachten, dass die Tags auf Instanzebene und somit auf alle Schnittstellen einer VM-Instanz angewendet werden. Wenn dies nicht wünschenswert ist, achten Sie darauf, dass die auf die Routen angewendeten Tags für jedes VPC-Netzwerk eindeutig sind.

Load-Balancer und mehrere Netzwerkschnittstellen

Mit Ausnahme des internen TCP/UDP-Load-Balancing verteilen alle Google Cloud-Load-Balancer den Traffic nur auf die erste Schnittstelle einer Backend-Instanz nic0.

Firewallregeln und mehrere Netzwerkschnittstellen

Jedes VPC-Netzwerk hat eigene Firewallregeln. Wenn sich die Schnittstelle einer Instanz in einem bestimmten VPC-Netzwerk befindet, gelten die Firewallregeln dieses Netzwerks für diese Schnittstelle.

Angenommen, eine VM-Instanz verfügt über zwei Schnittstellen:

  • nic0 im VPC-Netzwerk network-1
  • nic1 im VPC-Netzwerk network-2

Firewallregeln, die Sie für das Netzwerk network-1 erstellen, gelten für nic0. Firewallregeln, die Sie für das Netzwerk network-2 erstellen, gelten für nic1.

Weitere Informationen finden Sie unter VPC-Firewallregeln.

Firewalls in Instanzen mit mehreren Netzwerkschnittstellen verwenden

  • Firewallregeln für eingehenden Traffic können entweder Netzwerktags oder Dienstkonten verwenden, um Quellen, Ziele oder beides zu identifizieren.

  • Firewallregeln für ausgehenden Traffic können zur Identifizierung von Zielen (Quellen) entweder Netzwerktags oder Dienstkonten verwenden.

Weitere Informationen finden Sie unter Quell- und Zielfilterung nach Dienstkonto.

Netzwerktags und Dienstkonten identifizieren Instanzen, keine spezifischen Schnittstellen. Beachten Sie, dass Firewallregeln mit einem einzelnen VPC-Netzwerk verknüpft sind und jede Schnittstelle einer Multi-NIC-Instanz sich in einem Subnetz befinden muss, das sich in einem eindeutigen VPC-Netzwerk befindet.

Das folgende Beispiel zeigt, wie Sie Quelltags für allow-Firewallregeln für eingehenden Traffic effektiv verwenden können. Die Instanz vm1 hat zwei Netzwerkschnittstellen:

  • nic0 in network-1
  • nic1 in network-2

Angenommen, Sie müssen folgenden Traffic von vm1 zulassen:

  • SSH-Traffic von vm1 zu einer beliebigen Instanz in network-1
  • HTTP- und HTTPS-Traffic von vm1 zu einer beliebigen Instanz in network-2

Gehen Sie dazu so vor:

  1. vm1 zwei Netzwerktags zuweisen: vm1-network1 und vm1-network2.

  2. Erstellen Sie eine allow-Firewallregel für eingehenden Traffic in network-1 mit den folgenden Komponenten, um SSH-Traffic von vm1 an alle VMs in network-1 zuzulassen:

    • Aktion: allow
    • Richtung: ingress
    • Quellen: VMs mit vm1-network1-Tag
    • Ziele: Alle Instanzen im VPC-Netzwerk
    • Protokolle und Ports: tcp:22
  3. Erstellen Sie eine "allow-"Firewallregel für eingehenden Traffic in network-2 mit den folgenden Komponenten, um HTTP- und HTTPS-Traffic von vm1 an alle VMs in network-2 zuzulassen:

    • Aktion: allow
    • Richtung: ingress
    • Quellen: VMs mit vm1-network2-Tag
    • Ziele: Alle Instanzen im VPC-Netzwerk
    • Protokolle und Ports: tcp:80,443

Abbildung 4 zeigt dieses Beispiel für die Firewallkonfiguration:

Abbildung 4. Firewall-Regel 1 und Firewall-Regel 2 haben jeweils ein Quell-Tag, das VM1 zugeordnet ist. Firewall-Regel 1, die sich in network-1 befindet, wirkt sich nur auf nic0 von VM1 aus, da sie sich beide in network-1 befinden. Die Firewall-Regel 2 wirkt sich nur auf nic1 von VM1 aus, da sie auch ein Netzwerk gemeinsam nutzen (zum Vergrößern klicken).

Nächste Schritte