Interfacce di rete multiple

Questa pagina fornisce una panoramica di più interfacce di rete in un'istanza di macchina virtuale (VM), incluse le relative modalità di funzionamento e configurazioni di esempio. Per informazioni sulla creazione di configurazioni che utilizzano più interfacce, consulta Creare VM con più interfacce di rete.

Le VM con più controller di interfaccia di rete sono definite VM multi-NIC.

Per impostazione predefinita, le reti Virtual Private Cloud (VPC) di Google Cloud sono domini di rete privati isolati. Le reti hanno un ambito globale e contengono subnet a livello di regione. Le istanze VM in una rete VPC possono comunicare tra loro tramite indirizzi IP interni, purché le regole firewall lo consentano. Tuttavia, le comunicazioni verso gli indirizzi IP interni non sono consentite tra le reti, a meno che non vengano configurati meccanismi come il peering di rete VPC o Cloud VPN.

Ogni istanza in una rete VPC ha un'interfaccia di rete predefinita. Quando configuri un'interfaccia di rete, selezioni una rete VPC e una subnet al suo interno a cui connettere l'interfaccia. Puoi creare interfacce di rete aggiuntive collegate alle tue VM, ma ogni interfaccia deve essere collegata a una rete VPC diversa. Con più interfacce di rete puoi creare configurazioni in cui un'istanza si connette direttamente a diverse reti VPC.

Ogni istanza può avere fino a otto interfacce, a seconda del tipo di istanza. Per ulteriori informazioni, consulta Numero massimo di interfacce di rete.

Per ogni interfaccia possono essere configurati i seguenti indirizzi IP:

  • Un indirizzo IPv4 interno (obbligatorio)
  • Un indirizzo IPv4 esterno
  • Un indirizzo IPv6, interno o esterno, ma non entrambi

    Per configurare un indirizzo IPv6, devi connettere l'interfaccia a una subnet che abbia un intervallo IPv6 configurato.

In genere, potrebbero essere necessarie più interfacce se vuoi configurare un'istanza come appliance di rete che esegue il bilanciamento del carico, il rilevamento e la prevenzione delle intrusioni (IDS/IPS), un web application firewall (WAF) o l'ottimizzazione della rete WAN tra le reti. Più interfacce di rete sono utili anche quando le applicazioni eseguite in un'istanza richiedono la separazione del traffico, ad esempio la separazione del traffico del piano dati dal traffico del piano di gestione.

Ogni interfaccia su una VM è influenzata dalla MTU della rete collegata. Per ulteriori informazioni sulla MTU dell'interfaccia, consulta Unità massima di trasmissione.

Casi d'uso

Utilizza più interfacce di rete quando una singola istanza deve accedere a più di una rete VPC, ma non vuoi connettere entrambe le reti direttamente.

  • Funzione di rete e sicurezza: più interfacce di rete abilitano funzioni dell'appliance di rete virtualizzata, come bilanciatori del carico, server NAT (Network Address Translation) e server proxy configurati con più interfacce di rete. Per maggiori dettagli, consulta Esempio 1: appliance virtuali di Networking e sicurezza.

  • Isolamento del perimetro (noto anche come isolamento DMZ): una best practice importante nelle architetture di networking a più livelli consiste nell'isolare i servizi rivolti al pubblico da una rete interna e dai relativi servizi. Utilizza più interfacce di rete per creare configurazioni in cui sono presenti interfacce di rete separate sull'istanza, una delle quali accetta il traffico rivolto al pubblico e un'altra per la gestione del traffico privato del backend con controlli di accesso più restrittivi.

    Tutte le risorse raggiungibili da internet devono essere separate dalla rete interna e dai relativi servizi. Questo limita drasticamente l'ambito e i danni che una violazione della sicurezza può causare. Ad esempio, puoi inserire una seconda interfaccia di rete su ogni server web che si connette a una rete di livello medio in cui risiede un server applicazioni. Il server delle applicazioni può anche essere localizzato in modalità dual-homed su una rete di backend in cui risiede il server di database. Ogni istanza dual-homed riceve ed elabora le richieste sul frontend, avvia una connessione al backend e invia le richieste ai server sulla rete di backend.

    Configurando interfacce separate, una per il pubblico e l'altra per il privato, puoi applicare separatamente regole firewall e controlli di accesso separati a ogni interfaccia e applicare funzioni di sicurezza nelle comunicazioni dal dominio pubblico a quello privato. Per maggiori informazioni, consulta Esempio 2: utilizzo di appliance di terze parti in uno scenario di rete VPC condivisa.

Esempi di configurazione

Questa sezione esamina diversi esempi comuni di utilizzo di più interfacce di rete.

Esempio 1: appliance virtuali di Networking e di sicurezza

Le appliance virtuali di Networking e di sicurezza, come i web application firewall (WAF), i firewall a livello di applicazione di sicurezza e gli acceleratori WAN, sono generalmente configurate con più interfacce virtuali. Ognuna delle diverse interfacce è configurata con un proprio indirizzo IP interno e, facoltativamente, con un proprio indirizzo IP esterno.

La Figura 1 descrive una configurazione di esempio di un firewall a livello di applicazione che controlla il traffico da internet a una rete VPC. Il firewall a livello di applicazione è implementato nelle VM di Compute Engine.

In questo esempio, la route predefinita della VM dell'appliance è stata configurata in modo da utilizzare nic1.

Figura 1. Un'istanza con un'appliance VM ha tre interfacce di rete. Ogni interfaccia è connessa a una subnet in una rete VPC diversa (fai clic per ingrandire).

Esegui il provisioning e la configurazione delle istanze, ad esempio 1

Quanto segue presuppone che esistano già subnet0, subnet1 e subnet2, con intervalli non sovrapposti.

Per creare la VM e le interfacce di rete in questo esempio, utilizza il seguente comando:

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

Questo comando crea un'istanza con tre interfacce di rete:

  • nic0 è collegato a subnet0 e non ha un indirizzo IP esterno.
  • nic1 è collegato a subnet1 e ha un indirizzo IP esterno temporaneo.
  • nic2 è collegato a subnet2 e non ha un indirizzo IP esterno.

Esempio 2: utilizzo di appliance di terze parti in uno scenario di rete VPC condiviso

Questa configurazione è utile quando vuoi condividere un singolo set di appliance di terze parti centralizzate per carichi di lavoro o applicazioni ospitate in progetti diversi. Nella figura 2 sono presenti quattro applicazioni distinte, App1, App2, App3 e App4, ospitate in progetti di servizio diversi. È necessario che siano protetti per tutto il traffico in entrata su internet e il traffico in uscita deve essere ispezionato e filtrato in un'appliance di terze parti situata in posizione centrale nel progetto host del VPC condiviso.

Figura 2. Un'istanza in un progetto host del VPC condiviso ospita un'appliance VM. L'istanza ha un'interfaccia di rete per ciascuno dei quattro progetti di servizio e un'altra interfaccia per la rete VPC del perimetro di rete (fai clic per ingrandire).

Esegui il provisioning e la configurazione della VM e delle interfacce di rete, ad esempio 2

Per creare la VM e le interfacce di rete in questo esempio, utilizza il seguente comando:

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

Viene creata un'istanza con cinque interfacce di rete:

  • nic0 è collegato a subnet-perimeter, che fa parte di network-perimeter, con un indirizzo statico reserved-address.
  • nic1 è collegato a subnet-1, che fa parte di network-1, senza indirizzo IP esterno.
  • nic2 è collegato a subnet-2, che fa parte di network-2, senza indirizzo IP esterno.
  • nic3 è collegato a subnet-3, che fa parte di network-3, senza indirizzo IP esterno.
  • nic4 è collegato a subnet-4, che fa parte di network-4, senza indirizzo IP esterno.

Ulteriori dettagli operativi

Più interfacce di rete in un ambiente VPC condiviso

Un VPC condiviso consente di condividere le reti VPC tra i progetti nella tua organizzazione Google Cloud.

Un VPC condiviso consente di creare istanze associate a una rete VPC condivisa ospitata in un progetto host del VPC condiviso centralizzato. Per informazioni sulla configurazione delle reti VPC condivise, consulta Provisioning del VPC condiviso.

Per creare istanze con una o più interfacce associate alle reti VPC condivise, devi disporre del ruolo Utente di rete Compute (roles/compute.networkUser) nel progetto host del VPC condiviso.

Risoluzione DNS con più interfacce di rete

Una query DNS interna eseguita con il nome host dell'istanza viene risolta nell'interfaccia principale (nic0) dell'istanza. Se l'interfaccia nic0 dell'istanza è collegata a una subnet in una rete VPC diversa dalla rete VPC dell'istanza che invia la query DNS interna, la query non riesce.

I record DNS privati di Compute Engine non vengono generati per interfaccia.

Comportamento DHCP con più interfacce di rete

In una configurazione predefinita a più interfacce, il sistema operativo è configurato per utilizzare DHCP. Il comportamento DHCP e ARP di ciascuna delle interfacce è lo stesso di DHCP e ARP in un'istanza con una singola interfaccia.

In un'istanza con più interfacce che utilizza DHCP, ogni interfaccia riceve una route per la subnet in cui si trova. Inoltre, l'istanza riceve una singola route predefinita che è associata all'interfaccia principale eth0. Se non configurato manualmente, il traffico che lascia un'istanza per qualsiasi destinazione diversa da una subnet con connessione diretta lascerà l'istanza utilizzando la route predefinita su eth0.

Il comportamento è lo stesso per le interfacce con indirizzi IPv6. L'interfaccia riceve una route per l'intervallo di subnet IPv6 in cui si trova, nonché un'unica route predefinita IPv6.

In questo esempio, l'interfaccia principale eth0 riceve la route predefinita (default via 10.138.0.1 dev eth0) ed entrambe le interfacce eth0 e eth1 ricevono le route per le rispettive subnet.

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

Per ulteriori informazioni, consulta il seguente tutorial: Configurare il routing per un'interfaccia aggiuntiva.

Route statiche personalizzate e interfacce di rete multiple

Quando un'istanza VM ha più interfacce e un tag di rete, il tag di rete potrebbe non influire su tutte le interfacce della VM. Il tag di rete di una VM influisce su un'interfaccia se l'interfaccia si trova in una rete VPC che contiene una route statica personalizzata con un tag corrispondente.

Ad esempio:

  1. Una VM ha due interfacce: nic0 e nic1. L'interfaccia di nic0 è in vpc-net-a. L'interfaccia di nic1 è in vpc-net-b. La VM ha un tag di rete denominato vpn-ok. Il tag è un attributo dell'istanza, non di un'interfaccia specifica.
  2. La rete vpc-net-a ha una route statica personalizzata con un tag denominato vpn-ok.
  3. La rete vpc-net-b ha una route statica personalizzata con un tag denominato vpn-123.

Questi passaggi numerati corrispondono alla Figura 3:

Figura 3. La route statica personalizzata in vpc-net-a interessa nic0 perché ha un tag in comune, mentre la route statica personalizzata in vpc-net-b non influisce su nic1 (fai clic per ingrandire).

Nel caso della rete vpc-net-a, poiché ha una route con un tag in comune con la VM, il tag vpn-ok della VM si applica all'interfaccia nic0 della VM in vpc-net-a. Al contrario, poiché la rete vpc-net-b non ha una route statica con il tag vpn-ok, il tag di rete vpn-ok della VM viene ignorato nell'interfaccia nic1 della VM.

Tag in route in istanze con più interfacce di rete

Se scegli di utilizzare i tag con route, tieni presente che i tag vengono applicati a livello di istanza e, di conseguenza, a tutte le interfacce di un'istanza di macchina virtuale. Se ciò non è auspicabile, assicurati che i tag applicati alle route siano univoci per ogni rete VPC.

Bilanciatori del carico e più interfacce di rete

Ad eccezione del bilanciamento del carico TCP/UDP interno, tutti i bilanciatori del carico Google Cloud distribuiscono il traffico solo alla prima interfaccia (nic0) di un'istanza di backend.

Regole firewall e interfacce di rete multiple

Ogni rete VPC ha il proprio set di regole firewall. Se l'interfaccia di un'istanza si trova in una determinata rete VPC, all'interfaccia si applicano le regole firewall della rete.

Ad esempio, supponi che un'istanza VM abbia due interfacce:

  • nic0 nella rete VPC network-1
  • nic1 nella rete VPC network-2

Le regole firewall che crei per la rete network-1 si applicano anche a nic0. Le regole firewall che crei per la rete network-2 si applicano anche a nic1.

Per ulteriori informazioni, consulta Regole firewall VPC.

Firewall in istanze con più interfacce di rete

  • Le regole firewall in entrata possono utilizzare tag di rete o account di servizio per identificare origini, destinazioni (destinazioni) o entrambe.

  • Le regole firewall in uscita possono utilizzare tag di rete o account di servizio per identificare le destinazioni (origini).

Per maggiori informazioni, consulta la pagina relativa ai filtri di origine e destinazione in base all'account di servizio.

I tag di rete e gli account di servizio identificano le istanze, non le interfacce specifiche. Tieni presente che le regole firewall sono associate a una singola rete VPC e ogni interfaccia di un'istanza multi-NIC deve trovarsi in una subnet in una rete VPC univoca.

L'esempio seguente mostra come utilizzare in modo efficace i tag sorgente per le regole firewall allow in entrata. L'istanza vm1 ha due interfacce di rete:

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

Supponi di dover consentire il seguente traffico da vm1:

  • Traffico SSH da vm1 a qualsiasi istanza in network-1
  • Traffico HTTP e HTTPS da vm1 a qualsiasi istanza in network-2

A questo scopo, puoi procedere nel seguente modo:

  1. Assegna due tag di rete a vm1: vm1-network1 e vm1-network2

  2. Crea una regola firewall allow in entrata in network-1 con i seguenti componenti per consentire il traffico SSH da vm1 a tutte le VM in network-1:

    • Azione: allow
    • Direzione: ingress
    • Origini: VM con tag vm1-network1
    • Destinazioni: tutte le istanze nella rete VPC
    • Protocolli e porte: tcp:22
  3. Crea una regola firewall di autorizzazione in entrata in network-2 con i seguenti componenti per consentire il traffico HTTP e HTTPS da vm1 a tutte le VM in network-2:

    • Azione: allow
    • Direzione: ingress
    • Origini: VM con tag vm1-network2
    • Destinazioni: tutte le istanze nella rete VPC
    • Protocolli e porte: tcp:80,443

La Figura 4 illustra questo esempio di configurazione del firewall:

Figura 4. La regola firewall 1 e la regola firewall 2 hanno ciascuna un tag di origine associato a VM1. La regola firewall 1, che è in network-1, interessa solo nic0 di VM1 perché sono entrambe in network-1. La regola firewall 2 interessa solo nic1 di VM1 perché anche questi condividono una rete (fai clic per ingrandire).

Passaggi successivi