Mehrere Netzwerkschnittstellen – Übersicht und Beispiele

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 Mehrere Netzwerkschnittstellen erstellen.

Übersicht

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. 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. Alle Schnittstellen müssen sowohl eine interne als auch eine externe IP-Adresse haben. Jede Instanz kann je nach Instanztyp bis zu acht Schnittstellen haben. Weitere Informationen finden Sie unter Maximale Anzahl von Schnittstellen.

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 in der VPC-Übersicht.

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 Back-End-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 Back-End-Netzwerk vorhanden sein (Dual Homing), in dem sich der Datenbankserver befindet. Jede Dual-Homed-Instanz empfängt und verarbeitet Anfragen auf dem Front-End, baut die Verbindung zum Back-End auf und sendet dann die Anfragen zu den Servern im Back-End-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.

Die folgende Abbildung zeigt 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.

Anwendungsfall 1: Bereitstellung und Konfiguration von Instanzen mit mehreren Schnittstellen (zum Vergrößern klicken)
Anwendungsfall 1: Bereitstellung und Konfiguration von Instanzen mit mehreren Schnittstellen (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. Im unten gezeigten Beispiel 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.

Anwendungsfall 2: Beispiel für ein Shared VPC-Netzwerk mit Drittanbieter-Appliance (zum Vergrößern klicken)
Anwendungsfall 2: Beispiel für ein freigegebenes VPC-Netzwerk mit Drittanbieter-Appliance (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 an subnet-perimeter gebunden, das Bestandteil von network-perimeter ist, mit einer statischen, reservierten Adresse

  • nic1 ist an subnet-1 gebunden, das Bestandteil von network-1 ist, ohne externe IP-Adresse

  • nic2 ist an subnet-2 gebunden, das Bestandteil von network-2 ist, ohne externe IP-Adresse

  • nic3 ist an subnet-3 gebunden, das Bestandteil von network-3 ist, ohne externe IP-Adresse

  • nic4 ist an subnet-4 gebunden, das Bestandteil von network-4 ist, ohne externe IP-Adresse

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. Gehört die Schnittstelle nic0 nicht zu dem VPC-Netzwerk der Instanz, von der die interne DNS-Abfrage gesendet wurde, 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.

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 unter 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 der Zahl der Zusatzinformationen in dem folgenden Diagramm:

Grafik: Benutzerdefinierte statische Routen und mehrere Netzwerkschnittstellen (zum Vergrößern klicken)
Benutzerdefinierte statische Routen und mehrere Netzwerkschnittstellen (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 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. Ist dies nicht erwünscht, müssen die für die Routen geltenden Tags für jedes VPC-Netzwerk eindeutig sein.

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 Back-End-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 in der Übersicht über 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 hierzu 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 eindeutigen VPC-Netzwerk befinden muss.

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

Das folgende Diagramm veranschaulicht dieses Beispiel für die Firewallkonfiguration:

Firewallregeln (zum Vergrößern klicken)
Firewallregeln (zum Vergrößern klicken)

Weitere Informationen