Log di flusso VPC

Log di flusso VPC registra un campione di flussi di rete inviati e ricevuti dalle istanze VM, incluse le istanze utilizzate come nodi di Google Kubernetes Engine. Questi log possono essere utilizzati per monitoraggio della rete, analisi forense, analisi della sicurezza in tempo reale e ottimizzazione delle spese.

Puoi visualizzare i log di flusso in Cloud Logging ed esportarli in qualsiasi destinazione supportata dalle funzionalità di esportazione di Cloud Logging.

I log di flusso vengono aggregati per connessione dalle VM di Compute Engine ed esportati in tempo reale. Sottoscrivendo Pub/Sub, puoi analizzare i log di flusso utilizzando le API per i flussi di dati in tempo reale.

Proprietà chiave

• I log di flusso VPC fanno parte di Andromeda, il software alla base delle reti VPC. I log di flusso VPC non introducono ritardi o penalizzazioni in termini di prestazioni se abilitate.
• I log di flusso VPC funzionano con le reti VPC, non con le reti legacy. Puoi abilitare o disabilitare i log di flusso VPC per subnet. Se l'opzione è abilitata per una subnet, Log di flusso VPC raccoglie i dati da tutte le istanze VM in quella subnet.
• I log di flusso VPC campionano i flussi TCP, UDP, ICMP, ESP e GRE di ogni VM. Vengono campionati sia i flussi in entrata che in uscita. Questi flussi possono essere tra la VM e un'altra VM, un host nel tuo data center on-premise, un servizio Google o un host su internet. Se un flusso viene acquisito tramite campionamento, Log di flusso VPC genera un log per il flusso. Ogni record di flusso include le informazioni descritte nella sezione Formato record.
• I log di flusso VPC interagiscono con le regole firewall nei seguenti modi:
  • I pacchetti in uscita vengono campionati prima delle regole firewall in uscita. Anche se una regola firewall in uscita nega i pacchetti, questi possono essere campionati dai log di flusso VPC.
  • I pacchetti in entrata vengono campionati dopo le regole firewall in entrata. Se una regola firewall in entrata nega i pacchetti in entrata, questi non vengono campionati dai log di flusso VPC.
• Puoi utilizzare i filtri nei log di flusso VPC per generare solo determinati log.
• I log di flusso VPC supportano VM con più interfacce di rete. Devi abilitare i log di flusso VPC per ogni subnet, in ogni VPC che contiene un'interfaccia di rete.
• Per registrare i flussi tra i pod sullo stesso nodo Google Kubernetes Engine (GKE), devi abilitare la visibilità tra nodi per il cluster.

Casi d'uso

Monitoraggio della rete

I log di flusso VPC forniscono visibilità in tempo reale sulla velocità effettiva e sulle prestazioni di rete. Puoi:

• Monitorare la rete VPC
• Esegui diagnostica rete
• Filtra i log di flusso per VM e applicazioni per comprendere le variazioni del traffico
• Comprendere la crescita del traffico per la previsione della capacità

Informazioni sull'utilizzo della rete e sull'ottimizzazione delle spese legate al traffico di rete

Puoi analizzare l'utilizzo della rete con i log di flusso VPC. Puoi analizzare i flussi di rete per:

• Traffico tra regioni e zone
• Traffico verso paesi specifici su internet
• Persone che parlano più spesso

In base all'analisi, puoi ottimizzare le spese legate al traffico di rete.

Analisi forensi della rete

Puoi utilizzare i log di flusso VPC per la network forensics. Ad esempio, se si verifica un incidente, puoi esaminare quanto segue:

• Quali IP hanno parlato con chi e quando
• Eventuali IP compromessi analizzando tutti i flussi di rete in entrata e in uscita

Analisi della sicurezza in tempo reale

Puoi sfruttare le API per i flussi di dati in tempo reale (tramite Pub/Sub) e l'integrazione con sistemi SIEM (informazioni di sicurezza e gestione degli eventi). Ciò può fornire monitoraggio in tempo reale, correlazione di eventi, analisi e avvisi di sicurezza.

Raccolta di log

I log di flusso vengono raccolti per ogni connessione VM a intervalli specifici. Tutti i pacchetti raccolti per un determinato intervallo per una determinata connessione vengono aggregati per un periodo di tempo (intervallo di aggregazione) in una singola voce di log dei flussi. Questi dati vengono quindi inviati a Logging.

Per impostazione predefinita, i log vengono archiviati in Logging per 30 giorni. Se vuoi conservare i log per un periodo più lungo, puoi impostare un periodo di conservazione personalizzato o esportarli in una destinazione supportata.

Campionamento ed elaborazione dei log

Google Cloud campiona i pacchetti che escono da una VM e li inseriscono per generare log di flusso. Non tutti i pacchetti vengono acquisiti nel proprio record di log. Viene acquisito circa 1 pacchetto su 30, ma la frequenza di campionamento potrebbe essere inferiore a seconda del carico della VM. Non puoi modificare questa frequenza.

Dopo aver generato i log di flusso, Google Cloud li elabora in base alla seguente procedura:

1. Filtro: puoi specificare che vengano generati solo i log che corrispondono ai criteri specificati. Ad esempio, puoi filtrare in modo che vengano generati solo i log per una determinata VM o solo i log con un determinato valore dei metadati e il resto venga eliminato. Per ulteriori informazioni, consulta Filtro dei log.
2. Aggregazione: le informazioni sui pacchetti campionati vengono aggregate in un intervallo di aggregazione configurabile per produrre una voce di log del flusso.
3. Campionamento dei log di flusso: si tratta di un secondo processo di campionamento. Le voci del log di flusso vengono ulteriormente campionate in base a un parametro configurabile della frequenza di campionamento.
4. Metadati: se questa opzione è disattivata, tutte le annotazioni di metadati vengono ignorate. Se vuoi conservare i metadati, puoi specificare che vengano conservati tutti i campi o un insieme specificato di campi. Per ulteriori informazioni, consulta la sezione Annotazioni dei metadati.
5. Scrivi in Logging: le voci finali di log vengono scritte in Cloud Logging.

Nota: non è possibile modificare il modo in cui Log di flusso VPC raccoglie gli esempi. Tuttavia, puoi controllare il campionamento dei log di flusso secondario con il parametro Campionamento dei log. Anche con un campionamento dei log di flusso pari a 1.0 o al 100%, in media viene elaborato circa il 3% dei pacchetti a livello di VM a causa della frequenza di campionamento iniziale. Se devi analizzare tutti i pacchetti, puoi utilizzare il Mirroring pacchetto e le istanze del raccoglitore che eseguono software di terze parti.

Poiché i log di flusso VPC non acquisisce tutti i pacchetti, compensa i pacchetti persi interpolando dai pacchetti acquisiti. Questo accade per i pacchetti persi a causa delle impostazioni di campionamento iniziali e configurabili dall'utente.

Anche se Google Cloud non acquisisce tutti i pacchetti, le acquisizioni dei record dei log possono essere molto grandi. Puoi bilanciare le esigenze di visibilità del traffico e costi di archiviazione modificando i seguenti aspetti della raccolta dei log:

• Intervallo di aggregazione: i pacchetti campionati per un intervallo di tempo vengono aggregati in una singola voce di log. Questo intervallo di tempo può essere 5 secondi (valore predefinito), 30 secondi, 1 minuto, 5 minuti, 10 minuti o 15 minuti.
• Frequenza di campionamento: prima di essere scritti in Logging, il numero di log può essere campionato per ridurne il numero. Per impostazione predefinita, il volume voce di log viene scalato di 0,5 (50%), il che significa che viene mantenuta metà delle voci. Puoi impostare questo valore da 1.0 (100%, tutte le voci di log vengono conservate) a 0.0 (0%, nessun log viene conservato).
• Annotazioni dei metadati: per impostazione predefinita, le voci di log del flusso sono annotate con informazioni sui metadati, come i nomi delle VM di origine e di destinazione o la regione geografica di origini e destinazioni esterne. Le annotazioni dei metadati possono essere disattivate oppure puoi specificare solo determinate annotazioni per risparmiare spazio di archiviazione.
• Filtro: per impostazione predefinita, i log vengono generati per ogni flusso nella subnet. Puoi impostare i filtri in modo da generare solo i log che corrispondono a determinati criteri.

Annotazioni dei metadati

I record di log contengono campi di base e campi di metadati. La sezione Formato record elenca quali campi sono metadati di tipo e quali sono base tipo. Tutti i campi di base sono sempre inclusi. Puoi personalizzare i campi di metadati da conservare.

• Se selezioni tutti i metadati, tutti i campi di metadati nel formato di record dei log di flusso VPC vengono inclusi nei log di flusso. Quando nel formato record vengono aggiunti nuovi campi di metadati, i log di flusso includono automaticamente i nuovi campi.

• Se non selezioni alcun metadati, tutti i campi dei metadati vengono omessi.

• Se selezioni metadati personalizzati, puoi specificare i campi di metadati che vuoi includere dal campo principale, come src_vpc, o con il loro nome completo, ad esempio src_vpc.project_id

  Quando vengono aggiunti nuovi campi di metadati al formato record, i log di flusso non includono questi campi, a meno che non siano un nuovo campo all'interno di un campo principale che hai specificato di includere.

  • Se specifichi metadati personalizzati utilizzando campi principali, quando nuovi campi di metadati vengono aggiunti al formato del record all'interno di quel campo principale, i log di flusso includeranno automaticamente i nuovi campi.

  • Se specifichi metadati personalizzati utilizzando il nome completo del campo, quando vengono aggiunti nuovi campi di metadati al campo principale, i log di flusso non includeranno i nuovi campi.

Per informazioni sulla personalizzazione dei campi di metadati, consulta le istruzioni dell'API o dell'interfaccia a riga di comando gcloud CLI per abilitare il logging dei flussi VPC quando crei una subnet.

Annotazioni GKE

I flussi che hanno un endpoint in un cluster GKE possono essere annotati con annotazioni GKE, che possono includere dettagli su cluster, pod e servizio dell'endpoint.

Annotazioni del servizio GKE

Il traffico inviato a ClusterIP, NodePort o LoadBalancer può ricevere annotazioni di servizio. Se inviato a NodePort o LoadBalancer, il flusso riceve l'annotazione del servizio in entrambi gli hop della connessione.

Il traffico inviato direttamente alla porta di servizio di un pod è annotato con un'annotazione di servizio sull'endpoint di destinazione.

Il traffico inviato alla porta di servizio di un pod, in cui il pod esegue il backup di più servizi sulla stessa porta di servizio, è annotato con più servizi sull'endpoint di destinazione. È limitato a due Servizi. Se ce ne sono di più, l'endpoint verrà annotato con un indicatore MANY_SERVICES speciale.

Annotazioni dei pod sul traffico internet

Il traffico tra un pod e internet non riceve le annotazioni dei pod per impostazione predefinita. Per i pacchetti inviati a internet, l'agente di mascheramento converte l'indirizzo IP del pod nell'indirizzo IP del nodo prima che i log di flusso VPC vedano il pacchetto,quindi i log di flusso VPC non hanno informazioni sul pod e non possono aggiungere annotazioni sui pod.

A causa dell'uso mascherato, le annotazioni dei pod sono visibili solo se le destinazioni si trovano all'interno delle destinazioni predefinite non mascherate o in un elenco nonMasqueradeCIDRs personalizzato. Se includi destinazioni internet in un elenco nonMasqueradeCIDRs personalizzato, devi fornire un modo per tradurre gli indirizzi IP dei pod interni prima che vengano recapitati su internet. Per i cluster privati e non privati, puoi utilizzare Cloud NAT. Consulta Interazione GKE per ulteriori dettagli.

Formato dei record

I record di log contengono campi di base, che sono i campi principali di ogni record di log, e campi di metadati che aggiungono informazioni aggiuntive. I campi dei metadati possono essere omessi per risparmiare sui costi di archiviazione.

Alcuni campi di log sono in un formato a più campi, con più di un dato in un determinato campo. Ad esempio, il campo connection è nel formato IpConnection, che contiene gli indirizzi IP di origine e di destinazione e la porta, oltre al protocollo, in un unico campo. Questi campi a più campi sono descritti sotto la tabella dei formati record.

Nota: i valori dei campi metadata non si basano sul percorso del piano dati, ma sono approssimative e potrebbero essere mancanti o errati. Al contrario, i valori dei campi base vengono ricavati direttamente dalle intestazioni dei pacchetti.

Campo	Formato dei campi	Tipo di campo: metadati di base o facoltativi
connessione	IpConnection 5 tuple che descrive questa connessione	Livelli
giornalista	string Il lato che ha segnalato il flusso. Può essere SRC o DEST.	Livelli
rtt_msec	int64 Latenza misurata durante l'intervallo di tempo, solo per i flussi TCP. La latenza misurata è il tempo trascorso tra l'invio di una SEQ e la ricezione di un ACK corrispondente. Il risultato della latenza è la somma dell'RTT di rete e del tempo utilizzato dall'applicazione.	Livelli
bytes_sent	int64 Quantità di byte inviati dall'origine alla destinazione	Livelli
packets_sent	int64 Numero di pacchetti inviati dall'origine alla destinazione	Livelli
start_time	string Timestamp (formato della stringa di data RFC 3339) del primo pacchetto osservato durante l'intervallo di tempo aggregato.	Livelli
end_time	stringa Timestamp (formato della stringa di data RFC 3339) dell'ultimo pacchetto osservato durante l'intervallo di tempo aggregato	Livelli
src_gke_details	GkeDetails Metadati GKE per gli endpoint di origine. Disponibile solo se l'endpoint è GKE.	Metadati
dest_gke_details	GkeDetails Metadati GKE per gli endpoint di destinazione. Disponibile solo se l'endpoint è GKE.	Metadati
src_instance	InstanceDetails Se l'origine della connessione era una VM situata sullo stesso VPC, questo campo viene compilato con i dettagli dell'istanza VM. In una configurazione di un VPC condiviso, project_id corrisponde al progetto proprietario dell'istanza, di solito il progetto di servizio.	Metadati
dest_instance	InstanceDetails Se la destinazione della connessione è una VM situata sullo stesso VPC, questo campo viene compilato con i dettagli dell'istanza VM. In una configurazione di un VPC condiviso, project_id corrisponde al progetto proprietario dell'istanza, di solito il progetto di servizio.	Metadati
src_location	GeographicDetails Se l'origine della connessione era esterna al VPC, questo campo viene compilato con i metadati sulla posizione disponibili.	Metadati
dest_location	GeographicDetails Se la destinazione della connessione era esterna al VPC, questo campo viene compilato con i metadati sulla posizione disponibili.	Metadati
src_vpc	VpcDetails Se l'origine della connessione era una VM situata sullo stesso VPC, questo campo viene compilato con i dettagli della rete VPC. In una configurazione di un VPC condiviso, project_id corrisponde a quello del progetto host.	Metadati
dest_vpc	VpcDetails Se la destinazione della connessione è una VM situata sullo stesso VPC, questo campo viene compilato con i dettagli della rete VPC. In una configurazione di un VPC condiviso, project_id corrisponde a quello del progetto host.	Metadati

Formato del campo IpConnection

Campo	Tipo	Descrizione
protocollo	int32	Il numero di protocollo IANA
src_ip	string	Indirizzo IP di origine
dest_ip	string	Indirizzo IP di destinazione
src_port	int32	Porta di origine
dest_port	int32	Porta di destinazione

Formato del campo GkeDetails

Campo	Tipo	Descrizione
cluster	ClusterDetails	Metadati del cluster GKE
pod	PodDetails	Metadati dei pod GKE, completati quando l'origine o la destinazione del traffico è un pod
servizio	ServiceDetails	Metadati del servizio GKE, compilati solo in endpoint di servizio. Il record contiene fino a due servizi. Se sono presenti più di due servizi pertinenti, questo campo contiene un singolo servizio con un indicatore MANY_SERVICES speciale.

Formato del campo ClusterDetails

Campo	Tipo	Descrizione
cluster_location	string	Località del cluster. Può essere una zona o una regione, a seconda che il cluster sia a livello di zona o di regione.
cluster_name	string	Nome del cluster GKE.

Formato del campo PodDetails

Campo	Tipo	Descrizione
pod_name	string	Nome del pod
pod_namespace	string	Spazio dei nomi del pod

Formato del campo ServiceDetails

Campo	Tipo	Descrizione
service_name	string	Nome del servizio. Se ci sono più di due servizi pertinenti, il campo viene impostato su un indicatore MANY_SERVICES speciale.
service_namespace	string	Spazio dei nomi del servizio

Esempio:

Se esistono due servizi, il campo Servizio sarà simile al seguente:

service: [
 0: {
  service_name: "my-lb-service"
  service_namespace: "default"
 }
 1: {
  service_name: "my-lb-service2"
  service_namespace: "default"
 }
]

Se sono presenti più di due servizi, il campo Servizio sarà simile al seguente:

service: [
 0: {
  service_name: "MANY_SERVICES"
 }
]

Formato del campo InstanceDetails

Campo	Tipo	Descrizione
project_id	string	ID del progetto contenente la VM
regione	string	Regione della VM
vm_name	string	Nome istanza della VM
zona	string	Zona della VM

Formato del campo GeographicDetails

Campo	Tipo	Descrizione
asn	int32	Il numero di sistema autonomo (ASN) della rete esterna a cui appartiene questo endpoint.
città	string	Città per endpoint esterni
continente	string	Continente per endpoint esterni
paese	string	Paese per gli endpoint esterni, rappresentato dai codici paese ISO 3166-1 Alpha-3
regione	string	Regione per gli endpoint esterni

Formato campo VpcDetails

Campo	Tipo	Descrizione
project_id	string	ID del progetto contenente il VPC
subnetwork_name	string	Subnet su cui è in esecuzione la VM
vpc_name	string	VPC su cui opera la VM

Filtro dei log

Quando abiliti Log di flusso VPC, puoi impostare un filtro basato sui campi di base e di metadati in modo da conservare solo i log corrispondenti al filtro. Tutti gli altri log vengono eliminati prima di essere scritti in Logging, il che ti consente di risparmiare denaro e ridurre il tempo necessario per trovare le informazioni che stai cercando.

Puoi filtrare in base a qualsiasi sottoinsieme di campi dal Formato record.

Il filtro dei log di flusso VPC utilizza CEL, un linguaggio di espressione incorporato per le espressioni logiche basate su attributi. Le espressioni di filtro per i log di flusso VPC hanno un limite di 2048 caratteri. Per maggiori informazioni, consulta Operatori logici CEL supportati.

Per ulteriori informazioni sulla tecnologia CEL, consulta l'introduzione alla CEL e la definizione della lingua. La funzionalità filtro di generazione supporta un sottoinsieme limitato di sintassi CEL.

Per informazioni sulla creazione di una subnet che utilizza i filtri dei log, consulta le istruzioni dell'API o gcloud CLI per abilitare i log di flusso VPC quando crei una subnet.

Per informazioni sulla configurazione del filtro dei log, consulta le istruzioni dell'API o dell'interfaccia a riga di comando gcloud CLI per Aggiornare i parametri dei log di flusso VPC.

Esempio 1: limita la raccolta dei log a una VM specifica denominata my-vm. In questo caso, vengono registrati solo i log in cui il campo src_instance come riportato dalla sorgente del traffico è my-vm o il campo dst_instance come riportato dalla destinazione del traffico è my-vm.

gcloud compute networks subnets update my-subnet \
    --logging-filter-expr="(src_instance.vm_name == 'my-vm' && reporter=='SRC') || (dest_instance.vm_name == 'my-vm' && reporter=='DEST')"

Esempio 2: limita la raccolta dei log ai pacchetti i cui indirizzi IP di origine si trovano nella subnet 10.0.0.0/8.

gcloud compute networks subnets update my-subnet \
    --logging-filter-expr="inIpRange(connection.src_ip, '10.0.0.0/8')"

Esempio 3: limita la raccolta dei log al traffico esterno a un VPC.

gcloud compute networks subnets update my-subnet \
    --logging-filter-expr '!(has(src_vpc.vpc_name) && has(dest_vpc.vpc_name))'

Operatori logici CEL supportati

Espressione	Tipi supportati	Descrizione
vero, falso	Booleano	Costanti booleane
x == y x != y	Valore booleano, numero intero, stringa	Operatori di confronto Esempio: connection.protocol == 6
x e & y x || y	Booleano	Operatori logici booleani Esempio: connection.protocol == 6 && src_instance.vm_name == "vm_1"
!x	Booleano	La negazione
1, 2,0, 0, ...	Int	Valori letterali numerici costanti
X+Y	Stringa	Concatenazione di stringhe
"foo", 'foo', ...	Stringa	Valore letterale stringa costante
x.lower()	Stringa	Restituisce il valore minuscolo della stringa
x.upper()	Stringa	Restituisce il valore in lettere maiuscole della stringa
x.contains(y)	Stringa	Restituisce true se la stringa contiene la sottostringa specificata
x.startsWith(y)	Stringa	Restituisce true se la stringa inizia con la sottostringa specificata
x.endsWith(y)	Stringa	Restituisce true se la stringa termina con la sottostringa specificata
inIpRange(X, Y)	Stringa	Restituisce true se X è un IP e Y è un intervallo IP che contiene X Esempio: inIpRange("1.2.3.1"; "1.2.3.0/24")
x.containsFieldValue(y)	x: elenco y: mappa(stringa, stringa)	Restituisce true se l'elenco contiene un oggetto con campi corrispondenti alle coppie chiave-valore specificate Esempio: dest_gke_details.service.containsFieldValue({'service_name': 'service1', 'service_namespace': 'namespace1'})
contiene(x)	Stringa	Restituisce true se il campo è presente.

Esempi di modelli di traffico

Questa sezione mostra come funzionano i log di flusso VPC per vari casi d'uso.

Flussi da VM a VM nella stessa rete VPC

Flussi VM all'interno di una rete VPC. (fai clic per ingrandire).

Per i flussi da VM a VM nella stessa rete VPC, vengono segnalati i log di flusso delle VM richiedente e di risposta, purché entrambe le VM si trovino in subnet in cui sono abilitati log di flusso VPC. In questo esempio, la VM 10.10.0.2 invia una richiesta di 1224 byte alla VM 10.50.0.2, che si trova anche in una subnet in cui è abilitato il logging. A sua volta, 10.50.0.2 risponde alla richiesta con una risposta contenente 5342 byte. Sia la richiesta che la risposta vengono registrate dalle VM richiedente e di risposta.

Come segnalato con la richiesta della VM (10.10.0.2)
richiedi/rispondi	connection.src_ip	connection.dest_ip	bytes_sent	Annotazioni
request	10.10.0.2	10.50.0.2	1224	src_instance.* dest_instance.* src_vpc.* dest_vpc.*
rispondere	10.50.0.2	10.10.0.2	5.342	src_instance.* dest_instance.* src_vpc.* dest_vpc.*

Come segnalato dalla risposta della VM (10.50.0.2)
richiedi/rispondi	connection.src_ip	connection.dest_ip	byte	Annotazioni
request	10.10.0.2	10.50.0.2	1224	src_instance.* dest_instance.* src_vpc.* dest_vpc.*
rispondere	10.50.0.2	10.10.0.2	5.342	src_instance.* dest_instance.* src_vpc.* dest_vpc.*

Flussi da VM a indirizzo IP esterno

Flussi da VM a indirizzo IP esterno (fai clic per ingrandire).

Per i flussi che attraversano internet tra una VM in una rete VPC e un endpoint con un indirizzo IP esterno, i log di flusso vengono segnalati solo dalla VM che si trova nella rete VPC:

• Per i flussi in uscita, i log vengono riportati dalla VM di rete VPC che è l'origine del traffico.
• Per i flussi in entrata, i log vengono segnalati dalla VM di rete VPC che è la destinazione del traffico.

In questo esempio, la VM 10.10.0.2 scambia i pacchetti su internet con un endpoint che ha l'indirizzo IP esterno 203.0.113.5. Il traffico in uscita di 1224 byte inviati da 10.10.0.2 a 203.0.113.5 viene segnalato dalla VM di origine, 10.10.0.2. Il traffico in entrata di 5342 byte inviato da 203.0.113.5 a 10.10.0.2 viene segnalato dalla destinazione del traffico, la VM 10.10.0.2.

richiedi/rispondi	connection.src_ip	connection.dest_ip	bytes_sent	Annotazioni
request	10.10.0.2	203.0.113,5	1224	src_instance.* src_vpc.* dest_location.*
rispondere	203.0.113,5	10.10.0.2	5.342	dest_instance.* dest_vpc.* src_location.*

Flussi da VM a on-premise

Flussi da VM a on-premise (fai clic per ingrandire).

Per i flussi tra una VM in una rete VPC e un endpoint on-premise con un indirizzo IP interno, i log di flusso vengono segnalati solo dalla VM che si trova nella rete VPC:

• Per i flussi in uscita, i log vengono riportati dalla VM di rete VPC che è l'origine del traffico.
• Per i flussi in entrata, i log vengono segnalati dalla VM di rete VPC che è la destinazione del traffico.

In questo esempio, la VM 10.10.0.2 e l'endpoint on-premise 10.30.0.2 sono connessi tramite un gateway VPN o Cloud Interconnect. Il traffico in uscita di 1224 byte inviati da 10.10.0.2 a 10.30.0.2 viene segnalato dalla VM di origine, 10.10.0.2. Il traffico in entrata di 5342 byte inviato da 10.30.0.2 a 10.10.0.2 viene segnalato dalla destinazione del traffico, la VM 10.10.0.2.

richiedi/rispondi	connection.src_ip	connection.dest_ip	bytes_sent	Annotazioni
request	10.10.0.2	10.30.0.2	1224	src_instance.* src_vpc.*
rispondere	10.30.0.2	10.10.0.2	5.342	dest_instance.* dest_vpc.*

Flussi da VM a VM per VPC condiviso

Flussi VPC condivisi (fai clic per ingrandire).

Per i flussi da VM a VM per VPC condiviso, puoi abilitare i log di flusso VPC per la subnet nel progetto host. Ad esempio, la subnet 10.10.0.0/20 appartiene a una rete VPC condiviso definita in un progetto host. Puoi visualizzare i log di flusso delle VM appartenenti a questa subnet, comprese quelle create dai progetti di servizio. In questo esempio, i progetti di servizio sono chiamati "webserver", "recommendation", "database".

Per i flussi da VM a VM, se entrambe le VM si trovano nello stesso progetto o, nel caso di una rete condivisa, lo stesso progetto host, le annotazioni per l'ID progetto e simili sono fornite per l'altro endpoint della connessione. Se l'altra VM si trova in un progetto diverso, non vengono fornite annotazioni per l'altra VM.

La seguente tabella mostra un flusso come riportato da 10.10.0.10 o 10.10.0.20.

• src_vpc.project_id e dest_vpc.project_id sono per il progetto host poiché la subnet VPC appartiene al progetto host.
• src_instance.project_id e dest_instance.project_id sono per i progetti di servizio perché le istanze appartengono ai progetti di servizio.

connessione .src_ip	src_instance .project_id	src_vpc .project_id	connessione .dest_ip	dest_instance .project_id	dest_vpc .project_id
10.10.0.10	webserver	host_project	10.10.0.20	suggerimento	host_project

I progetti di servizio non sono proprietari della rete VPC condiviso e non hanno accesso ai log di flusso della rete VPC condiviso.

Flussi da VM a VM per peering di rete VPC

Flussi di peering di rete VPC (fai clic per ingrandire).

A meno che entrambe le VM non si trovino nello stesso progetto Google Cloud, i flussi da VM a VM per le reti VPC in peering vengono registrati come per gli endpoint esterni: non vengono fornite informazioni sul progetto e altre annotazioni per l'altra VM. Se entrambe le VM si trovano nello stesso progetto, anche se in reti diverse, le informazioni sul progetto e su altre annotazioni vengono fornite anche per l'altra VM.

In questo esempio, le subnet della VM 10.10.0.2 nel progetto analytics-prod e la VM 10.50.0.2 nel progetto webserver-test sono connesse tramite peering di rete VPC. Se Log di flusso VPC è abilitato in analisi del progetto di produzione, il traffico (1224 byte) inviato da 10.10.0.2 a 10.50.0.2 viene segnalato dalla VM 10.10.0.2, che è l'origine del flusso. Il traffico (5342 byte) inviato da 10.50.0.2 a 10.10.0.2 viene segnalato anche dalla VM 10.10.0.2, che è la destinazione del flusso.

In questo esempio, Log di flusso VPC non è attivato nel webserver-test del progetto, quindi la VM 10.50.0.2 non registra alcun log.

giornalista	connection.src_ip	connection.dest_ip	bytes_sent	Annotazioni
origine	10.10.0.2	10.50.0.2	1224	src_instance.* src_vpc.*
destinazione	10.50.0.2	10.10.0.2	5.342	dest_instance.* dest_vpc.*

Flussi da VM a VM per bilanciatori del carico di rete passthrough interni

Flussi del bilanciatore del carico di rete passthrough interno (fai clic per ingrandire).

Quando aggiungi una VM al servizio di backend per un bilanciatore del carico di rete passthrough interno, l'ambiente guest Linux o Windows aggiunge l'indirizzo IP del bilanciatore del carico alla tabella di routing locale della VM. Ciò consente alla VM di accettare pacchetti di richieste con destinazioni impostate sull'indirizzo IP del bilanciatore del carico. Quando la VM risponde, invia direttamente la risposta. Tuttavia, l'indirizzo IP di origine per i pacchetti di risposta è impostato sull'indirizzo IP del bilanciatore del carico, non sulla VM con bilanciamento del carico.

I flussi da VM a VM inviati attraverso un bilanciatore del carico di rete passthrough interno vengono segnalati sia dall'origine che dalla destinazione. Per un esempio di coppia di richiesta / risposta HTTP, la tabella seguente spiega i campi delle voci di log del flusso osservate. Ai fini di questa illustrazione, considera la seguente configurazione di rete:

• Istanza del browser in 192.168.1.2
• Bilanciatore del carico di rete passthrough interno a 10.240.0.200
• Istanza server web su 10.240.0.3

Direzione del traffico	giornalista	connection.src_ip	connection.dest_ip	connection.src_instance	connection.dest_instance
Richiesta	SRC	192.168.1.2	10.240.0.200	Istanza browser
Richiesta	DEST	192.168.1.2	10.240.0.200	Istanza browser	Istanza server web
Risposta	SRC	10.240.0.3	192.168.1.2	Istanza server web	Istanza browser
Risposta	DEST	10.240.0.200	192.168.1.2		Istanza browser

La VM richiedente non sa quale VM risponderà alla richiesta. Inoltre, poiché l'altra VM invia una risposta con l'IP del bilanciatore del carico interno come indirizzo di origine, non sa quale VM ha risposto. Per questi motivi, la VM richiedente non può aggiungere informazioni dest_instance al report, ma solo informazioni src_instance. Poiché la VM rispondente conosce l'indirizzo IP dell'altra VM, può fornire le informazioni src_instance e dest_instance.

Flusso da pod a ClusterIP

Flusso IP da pod a cluster (fai clic per ingrandire).

In questo esempio, il traffico viene inviato dal pod client (10.4.0.2) a cluster-service (10.0.32.2:80). La destinazione viene risolta all'indirizzo IP del pod del server selezionato (10.4.0.3) sulla porta di destinazione (8080).

Sui bordi dei nodi, il flusso viene campionato due volte con l'indirizzo IP e la porta tradotti. Per entrambi i punti di campionamento, identificheremo che il pod di destinazione supporta il servizio cluster-service sulla porta 8080 e annulleremo il record con i dettagli del servizio e i dettagli del pod. Se il traffico viene instradato a un pod sullo stesso nodo, il traffico non lascia il nodo e non viene campionato.

In questo esempio vengono trovati i record seguenti.

giornalista	connection.src_ip	connection.dst_ip	bytes_sent	Annotazioni
SRC	10.4.0.2	10.4.0.3	1224	src_instance.* src_vpc.* src_gke_details.cluster.* src_gke_details.pod.* dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.pod.* dest_gke_details.service.*
DEST	10.4.0.2	10.4.0.3	1224	src_instance.* src_vpc.* src_gke_details.cluster.* src_gke_details.pod.* dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.pod.* dest_gke_details.service.*

Flussi LoadBalancer esterni di GKE

Flussi del bilanciatore del carico esterno (fai clic per ingrandire).

Il traffico da un indirizzo IP esterno a un servizio GKE (35.35.35.35) viene instradato a un nodo nel cluster, 10.0.12.2 in questo esempio, per il routing. Per impostazione predefinita, i bilanciatori del carico di rete passthrough esterni distribuiscono il traffico tra tutti i nodi del cluster, anche quelli che non eseguono un pod pertinente. Il traffico potrebbe richiedere hop extra per raggiungere il pod pertinente. Per maggiori informazioni, consulta Networking all'esterno del cluster.

Il traffico viene quindi instradato dal nodo (10.0.12.2) al pod di server selezionato (10.4.0.2). Entrambi gli hop vengono registrati perché tutti i bordi dei nodi sono campionati. Nel caso in cui il traffico venga instradato a un pod sullo stesso nodo, 10.4.0.3 in questo esempio, il secondo hop non viene registrato perché non lascia il nodo. Il secondo hop viene registrato dai punti di campionamento di entrambi i nodi. Il secondo hop viene registrato dai punti di campionamento di entrambi i nodi. Per il primo hop, identifichiamo il servizio in base all'IP del bilanciatore del carico e alla porta del servizio (80). Per il secondo, identifichiamo che il pod di destinazione supporta il servizio sulla porta di destinazione (8080).

In questo esempio vengono trovati i record seguenti.

giornalista	connection.src_ip	connection.dst_ip	bytes_sent	Annotazioni
DEST	203.0.113,1	35.35.35.35	1224	src_location.* dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.service.*
SRC	10.0.12.2	10.4.0.2	1224	src_instance.* src_vpc.* src_gke_details.cluster.* dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.pod.* dest_gke_details.service.*
DEST	10.0.12.2	10.4.0.2	1224	src_instance.* src_vpc.* src_gke_details.cluster.* dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.pod.* dest_gke_details.service.*

Flussi di GKE Ingress

Flussi in entrata (fai clic per ingrandire).

Una connessione da un indirizzo IP pubblico a una destinazione Ingress viene terminata presso il servizio del bilanciatore del carico. La connessione è mappata a un servizio NodePort in base all'URL. Per gestire la richiesta, il bilanciatore del carico (130.211.0.1) si connette a uno dei nodi del cluster (10.0.12.2) per il routing utilizzando NodePort del servizio. Per impostazione predefinita, durante la creazione di un Ingress, il controller GKE Ingress configura un bilanciatore del carico HTTP(S) che distribuisce il traffico tra tutti i nodi del cluster, anche quelli che non eseguono un pod pertinente. Il traffico potrebbe richiedere hop extra per raggiungere il pod pertinente. Per maggiori informazioni, consulta Networking all'esterno del cluster. Il traffico viene quindi instradato dal nodo (10.0.12.2) al pod di server selezionato (10.4.0.2).

Entrambi gli hop vengono registrati perché tutti i bordi dei nodi sono campionati. Per il primo hop, identifichiamo il servizio in base alla NodePort (60000) del servizio. Per il secondo, identifichiamo che il pod di destinazione supporta il servizio sulla porta di destinazione (8080). Il secondo hop viene registrato dai punti di campionamento di entrambi i nodi. Tuttavia, nel caso in cui il traffico venga instradato a un pod sullo stesso nodo (10.4.0.3), il secondo hop non viene registrato perché il traffico non è uscito dal nodo.

In questo esempio vengono trovati i record seguenti.

giornalista	connection.src_ip	connection.dst_ip	bytes_sent	Annotazioni
DEST	130.211.0.1	10.0.12.2	1224	dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.service.*
SRC	10.0.12.2	10.4.0.2	1224	src_instance.* src_vpc.* src_gke_details.cluster.* dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.pod.* dest_gke_details.service.*
DEST	10.0.12.2	10.4.0.2	1224	src_instance.* src_vpc.* src_gke_details.cluster.* dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.pod.* dest_gke_details.service.*

Flussi di GKE Ingress che utilizzano il bilanciamento del carico nativo del container

Flussi in entrata che utilizzano il bilanciamento del carico nativo del container (fai clic per ingrandire).

Le richieste da un indirizzo IP pubblico a una risorsa Ingress che utilizza il bilanciamento del carico nativo del container vengono terminate al bilanciatore del carico. In questo tipo di Ingress, i pod sono oggetti fondamentali per il bilanciamento del carico. Una richiesta viene quindi inviata dal bilanciatore del carico (130.211.0.1) direttamente a un pod selezionato (10.4.0.2). Identifichiamo che il pod di destinazione supporta il servizio sulla porta di destinazione (8080).

In questo esempio viene trovato il record seguente.

giornalista	connection.src_ip	connection.dst_ip	bytes_sent	Annotazioni
DEST	130.211.0.1	10.4.0.2	1224	dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.pod.* dest_gke_details.service.*

Da pod a flussi esterni

Dal pod al flusso esterno (fai clic per ingrandire).

Il traffico da un pod (10.4.0.3) a un IP esterno (203.0.113.1) viene modificato mediante il mascheramento dell'IP in modo che i pacchetti vengano inviati dall'IP del nodo (10.0.12.2) anziché dall'IP del pod. Per impostazione predefinita, il cluster GKE è configurato per mascherare il traffico verso destinazioni esterne. Per maggiori informazioni, consulta Agente di mascheramento IP.

Per visualizzare le annotazioni dei pod per questo traffico, puoi configurare l'agente di mascheramento in modo da non mascherare gli IP dei pod. In tal caso, per consentire il traffico verso internet, puoi configurare Cloud NAT, che elabora gli indirizzi IP dei pod. Per ulteriori informazioni su Cloud NAT con GKE, consulta la pagina relativa all'interazione con GKE.

In questo esempio viene trovato il record seguente.

giornalista	connection.src_ip	connection.dst_ip	bytes_sent	Annotazioni
SRC	10.0.12.2	203.0.113,1	1224	src_instance.* src_vpc.* src_gke_details.cluster.* dest_location.*

Prezzi

Si applicano prezzi standard per Logging, BigQuery o Pub/Sub. I prezzi dei log di flusso VPC sono descritti nella sezione Prezzi della telemetria di rete.

Domande frequenti

• Log di flusso VPC include il traffico consentito e negato in base alle regole firewall?

  • I log di flusso VPC coprono il traffico dal punto di vista di una VM. Tutto il traffico (in uscita) da una VM viene registrato, anche se è bloccato da una regola firewall di negazione in uscita. Il traffico in entrata (in entrata) viene registrato se consentito da una regola firewall di autorizzazione in entrata. Il traffico in entrata bloccato da una regola firewall di negazione in entrata non viene registrato.

• I log di flusso VPC funzionano con istanze VM con più interfacce?

  • Sì, puoi abilitare Log di flusso VPC per tutte le interfacce su una VM con più interfacce.

• I log di flusso VPC funzionano con reti legacy?

  • No, i log di flusso VPC non sono supportati sulle reti legacy.

Passaggi successivi

• Utilizza i log di flusso VPC