Interfacce di rete multiple
Questa pagina fornisce una panoramica di più interfacce di rete in un'istanza di macchina virtuale (VM), compreso il loro 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 con più 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 utilizzando 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 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 all'interno di quella rete VPC a cui connettere l'interfaccia. Puoi creare interfacce di rete aggiuntive collegate alle tue VM, ma ciascuna interfaccia deve essere collegata a una rete VPC diversa. Avere più interfacce di rete consentono di 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 maggiori 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 ha un intervallo IPv6 configurato.
In genere, potresti aver bisogno di più interfacce se vuoi configurare un'istanza come appliance di rete che esegue bilanciamento del carico, rilevamento e prevenzione delle intrusioni (IDS/IPS), web application firewall (WAF) o l'ottimizzazione WAN tra le reti. Più interfacce di rete sono utili anche quando le applicazioni in esecuzione in un'istanza richiedono la separazione del traffico, ad esempio quella del piano dati dal traffico del piano di gestione.
Ogni interfaccia su una VM è influenzata dalla MTU della rete collegata. Per ulteriori informazioni sull'MTU dell'interfaccia, consulta Unità massima di trasmissione.
Casi d'uso
Utilizza più interfacce di rete quando una singola istanza ha bisogno di 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 di appliance di rete virtualizzate come bilanciatori del carico, server NAT (Network Address Translation) e server proxy configurati con più interfacce di rete. Per ulteriori 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 nell'istanza sono presenti interfacce di rete separate, una che accetta il traffico rivolto al pubblico e un'altra gestisce il traffico privato del backend con controlli di accesso più restrittivi.
Tutte le risorse raggiungibili da internet devono essere separate dalla rete interna e dai servizi. Ciò limita drasticamente l'ambito e i danni causati da una violazione della sicurezza. Ad esempio, puoi inserire una seconda interfaccia di rete in ogni server web che si connette a una rete di livello medio in cui si trova un server delle applicazioni. Il server delle applicazioni può anche essere associato a una rete di backend in cui si trova il server di database. Ogni istanza in dual-homed riceve ed elabora le richieste sul frontend, avvia una connessione al backend, quindi invia le richieste ai server della rete di backend.
Configurando interfacce separate, una rivolta al pubblico e un'altra rivolta al privato, puoi applicare regole firewall e controlli di accesso separati a ciascuna interfaccia separatamente e applicare funzioni di sicurezza nelle comunicazioni dal pubblico al dominio privato. Per ulteriori 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 sicurezza
Le appliance virtuali di networking e sicurezza, come WAF (Web Application Firewall), firewall a livello di applicazione di sicurezza e acceleratori WAN, sono generalmente configurate con più interfacce virtuali. Ognuna delle interfacce è configurata con il proprio indirizzo IP interno e, facoltativamente, con il 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 per utilizzare nic1
.
Figura 1. Un'istanza con un'appliance VM ha tre interfacce di rete. Ogni interfaccia è connessa a una subnet che si trova 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 asubnet0
e non ha un indirizzo IP esterno.nic1
è collegato asubnet1
e ha un indirizzo IP esterno temporaneo.nic2
è collegato asubnet2
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 insieme di appliance centralizzate di terze parti per carichi di lavoro o applicazioni ospitati 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 internet in entrata e che il traffico in uscita venga ispezionato e filtrato in un'appliance di terze parti che si trova centralmente 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 asubnet-perimeter
, che fa parte dinetwork-perimeter
, con un indirizzo staticoreserved-address
.nic1
è collegato asubnet-1
, che fa parte dinetwork-1
, senza un indirizzo IP esterno.nic2
è collegato asubnet-2
, che fa parte dinetwork-2
, senza un indirizzo IP esterno.nic3
è collegato asubnet-3
, che fa parte dinetwork-3
, senza un indirizzo IP esterno.nic4
è collegato asubnet-4
, che fa parte dinetwork-4
, senza un indirizzo IP esterno.
Ulteriori dettagli operativi
Più interfacce di rete in un ambiente VPC condiviso
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 centralizzato del VPC condiviso. Per informazioni sulla configurazione di reti VPC condivise, consulta Provisioning di un VPC condiviso.
Per creare istanze con una o più interfacce associate a 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
Quando viene eseguita una query DNS interna 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 da DHCP con più interfacce di rete
In una configurazione predefinita con più interfacce, il sistema operativo è configurato in modo da utilizzare DHCP. Il comportamento DHCP e ARP di ciascuna delle interfacce multiple è 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 associata all'interfaccia principale eth0
. A meno che
non sia stata configurata manualmente in modo diverso, il traffico che lascia un'istanza per
qualsiasi destinazione diversa da una subnet con collegamento diretto 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é una singola route predefinita IPv6.
In questo esempio, l'interfaccia principale eth0
ottiene la route predefinita (default via 10.138.0.1 dev eth0
) e 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 tutorial seguente: 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 si trova su una rete VPC che contiene una route statica personalizzata con un tag corrispondente.
Ad esempio:
- Una VM ha due interfacce:
nic0
enic1
. L'interfaccia dinic0
è invpc-net-a
. L'interfaccia dinic1
è invpc-net-b
. La VM ha un tag di rete denominatovpn-ok
. Il tag è un attributo nell'istanza, non in un'interfaccia specifica. - La rete
vpc-net-a
ha una route statica personalizzata con un tag chiamatovpn-ok
. - La rete
vpc-net-b
ha una route statica personalizzata con un tag chiamatovpn-123
.
Questi passaggi numerati corrispondono alla figura 3:
Figura 3.
La route statica personalizzata in vpc-net-a
influisce su 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é presenta 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 nelle 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, pertanto, si applicano a tutte le interfacce di un'istanza di macchina virtuale. Se ciò non è opportuno, assicurati che i tag applicati alle route siano univoci per ciascuna rete VPC.
Bilanciatori del carico e più interfacce di rete
Ad eccezione del bilanciamento del carico TCP/UDP interno, tutti i bilanciatori del carico di Google Cloud distribuiscono il traffico solo alla prima interfaccia (nic0
) di un'istanza di backend.
Regole firewall e più interfacce di rete
Ogni rete VPC ha il proprio set di regole firewall. Se l'interfaccia di un'istanza si trova in una determinata rete VPC, le regole firewall di quella rete si applicano a quell'interfaccia.
Supponiamo, ad esempio, che un'istanza VM abbia due interfacce:
nic0
nella rete VPCnetwork-1
nic1
nella rete VPCnetwork-2
Le regole firewall che crei per la rete network-1
si applicano a nic0
.
Le regole firewall che crei per la rete network-2
si applicano a nic1
.
Per maggiori 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 entrambi.
Le regole firewall in uscita possono utilizzare tag di rete o account di servizio per identificare le destinazioni (sorgenti).
Per ulteriori informazioni, consulta la pagina relativa al filtro di origine e di destinazione in base all'account di servizio.
I tag di rete e gli account di servizio identificano istanze, non interfacce specifiche. Tieni presente che le regole firewall sono associate a una singola rete VPC e che ogni interfaccia di un'istanza con più NIC deve trovarsi in una subnet in una rete VPC univoca.
L'esempio seguente mostra come utilizzare in modo efficace i tag di origine per le regole firewall allow
in entrata. L'istanza vm1
ha due interfacce di rete:
nic0
innetwork-1
nic1
innetwork-2
Supponiamo di dover consentire il seguente traffico da vm1
:
- Traffico SSH da
vm1
a qualsiasi istanza innetwork-1
- Traffico HTTP e HTTPS da
vm1
a qualsiasi istanza innetwork-2
A questo scopo, procedi nel seguente modo:
Assegna due tag di rete a
vm1
:vm1-network1
evm1-network2
Crea una regola firewall
allow
in entrata innetwork-1
con i seguenti componenti per consentire il traffico SSH davm1
a tutte le VM innetwork-1
:- Azione:
allow
- Direzione:
ingress
- Origini: VM con tag
vm1-network1
- Destinazioni: tutte le istanze nella rete VPC
- Protocolli e porte:
tcp:22
- Azione:
Crea una regola firewall di autorizzazione in entrata in
network-2
con i seguenti componenti per consentire il traffico HTTP e HTTPS davm1
a tutte le VM innetwork-2
:- Azione:
allow
- Direzione:
ingress
- Origini: VM con tag
vm1-network2
- Destinazioni: tutte le istanze nella rete VPC
- Protocolli e porte:
tcp:80,443
- Azione:
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 alla VM1. La regola firewall 1, che si trova in network-1
, interessa solo nic0
di VM1 perché sono entrambe in network-1
. La regola firewall 2 influisce solo su nic1
della VM1 perché condivide anche una rete (fai clic per ingrandire).