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.
VMs mit mehreren Netzwerkschnittstellen-Controllern werden als VMs mit mehreren NICs bezeichnet.
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.
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 ansubnet0
gebunden und hat keine externe IP-Adresse.nic1
ist ansubnet1
gebunden und hat eine sitzungsspezifische externe IP-Adresse.nic2
ist ansubnet2
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.
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 Adressereserved-address
ansubnet-perimeter
angehängt, das wiederum Teil vonnetwork-perimeter
ist.nic1
ist ohne externe IP-Adresse ansubnet-1
angehängt, das wiederum Teil vonnetwork-1
ist.nic2
ist ohne externe IP-Adresse ansubnet-2
angehängt, das wiederum Teil vonnetwork-2
ist.nic3
ist ohne externe IP-Adresse ansubnet-3
angehängt, das wiederum Teil vonnetwork-3
ist.nic4
ist ohne externe IP-Adresse ansubnet-4
angehängt, das wiederum Teil vonnetwork-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 verbunden 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 in der Anleitung Routing für eine zusätzliche Schnittstelle konfigurieren.
Benutzerdefinierte statische Routen und mehrere Netzwerkschnittstellen
Wenn eine VM-Instanz mehrere Schnittstellen und ein Netzwerk-Tag hat, wirkt sich das Netzwerk-Tag möglicherweise nicht auf alle Schnittstellen der VM aus. Das Netzwerk-Tag 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:
- Eine VM hat zwei Schnittstellen:
nic0
undnic1
. Die Schnittstellenic0
befindet sich invpc-net-a
. Die Schnittstellenic1
befindet sich invpc-net-b
. Die VM hat ein Netzwerk-Tag namensvpn-ok
. Das Tag ist ein Attribut auf der Instanz und nicht auf einer bestimmten Schnittstelle. - Das Netzwerk
vpc-net-a
hat eine benutzerdefinierte statische Route mit einem Tag namensvpn-ok
. - Das Netzwerk
vpc-net-b
hat eine benutzerdefinierte statische Route mit einem Tag namensvpn-123
.
Diese nummerierten Schritte entsprechen Abbildung 3:
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 Netzwerk-Tag 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-Netzwerknetwork-1
nic1
im VPC-Netzwerknetwork-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
innetwork-1
nic1
innetwork-2
Angenommen, Sie müssen folgenden Traffic von vm1
zulassen:
- SSH-Traffic von
vm1
zu einer beliebigen Instanz innetwork-1
- HTTP- und HTTPS-Traffic von
vm1
zu einer beliebigen Instanz innetwork-2
Gehen Sie dazu so vor:
vm1
zwei Netzwerktags zuweisen:vm1-network1
undvm1-network2
.Erstellen Sie eine
allow
-Firewallregel für eingehenden Traffic innetwork-1
mit den folgenden Komponenten, um SSH-Traffic vonvm1
an alle VMs innetwork-1
zuzulassen:- Aktion:
allow
- Richtung:
ingress
- Quellen: VMs mit
vm1-network1
-Tag - Ziele: Alle Instanzen im VPC-Netzwerk
- Protokolle und Ports:
tcp:22
- Aktion:
Erstellen Sie eine "allow-"Firewallregel für eingehenden Traffic in
network-2
mit den folgenden Komponenten, um HTTP- und HTTPS-Traffic vonvm1
an alle VMs innetwork-2
zuzulassen:- Aktion:
allow
- Richtung:
ingress
- Quellen: VMs mit
vm1-network2
-Tag - Ziele: Alle Instanzen im VPC-Netzwerk
- Protokolle und Ports:
tcp:80,443
- Aktion:
Abbildung 4 zeigt dieses Beispiel für die Firewallkonfiguration: