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 trovarsi all'interno di Google Cloud o tra Google Cloud e altre reti. 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.
- I log di flusso VPC non vengono generati da risorse non VM come Cloud Run o endpoint on-premise.
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 relativo 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:
- 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.
- Aggregazione: le informazioni sui pacchetti campionati vengono aggregate in un intervallo di aggregazione configurabile per produrre una voce di log del flusso.
- 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.
- 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.
- Scrivi in Logging: le voci finali di log vengono scritte in Cloud Logging.
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) a0.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 dei tipi. 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 esempiosrc_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.
I campi dei metadati presentano le seguenti limitazioni:
- I valori dei campi di metadati non si basano sul percorso del piano dati; sono approssimative e potrebbero essere mancanti o errati. A differenza dei campi dei metadati, i valori dei campi base vengono ricavati direttamente dalle intestazioni dei pacchetti.
- Per il campo
internet_routing_details
, in alcuni casi potrebbe mancare il percorso del sistema autonomo (AS). Ad esempio, quando i pacchetti vengono instradati in un VPC, le informazioni sul percorso AS non sono incluse.
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 |
internet_routing_details |
InternetRoutingDetails
Se la connessione è tra Google Cloud e internet, questo campo viene compilato con i dettagli del routing. Disponibile solo per i flussi in uscita. |
Metadati |
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 InternetRoutingDetails
Campo | Tipo | Descrizione |
---|---|---|
egress_as_path | AsPath | Elenco di percorsi AS pertinenti. Se sono disponibili più percorsi AS per il flusso, il campo potrebbe contenere più di un percorso AS. |
Formato campo AsPath
Campo | Tipo | Descrizione |
---|---|---|
as_details | AsDetails | Elenco dei dettagli dell'AS per tutti i sistemi nel percorso AS. L'elenco inizia dal primo AS esterno alla rete di Google Cloud e termina con l'AS a cui appartiene l'indirizzo IP remoto. |
Formato del campo AsDetails
Campo | Tipo | Descrizione |
---|---|---|
asn | uint32 | Il numero di sistema autonomo (ASN) dell'AS. |
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 |
esterno | 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 | L'ASN della rete esterna a cui appartiene questo endpoint. |
city | string | Città per endpoint esterni |
continente | string | Continente per endpoint esterni |
country | 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 funzione 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 elencato in Formato record, ad eccezione dei seguenti campi:
rtt_msec
bytes_sent
packets_sent
start_time
end_time
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 | String | Concatenazione di stringhe |
"foo", 'foo', ... | String | Valore letterale stringa costante |
x.lower() | String | Restituisce il valore minuscolo della stringa |
x.upper() | String | Restituisce il valore in lettere maiuscole della stringa |
x.contains(y) | String | Restituisce true se la stringa contiene la sottostringa specificata |
x.startsWith(y) | String | Restituisce true se la stringa inizia con la sottostringa specificata |
x.endsWith(y) | String | Restituisce true se la stringa termina con la sottostringa specificata |
inIpRange(X, Y) | String | 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) | String | 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
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
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.* internet_routing_details.* |
rispondere | 203.0.113,5 | 10.10.0.2 | 5.342 |
dest_instance.* dest_vpc.* src_location.* |
Flussi da VM a on-premise
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
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
edest_vpc.project_id
sono per il progetto host poiché la subnet VPC appartiene al progetto host.src_instance.project_id
edest_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
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 |
---|---|---|---|---|
source | 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
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
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
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
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
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
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.* internet_routing_details.* |
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.