Informazioni sui flussi di traffico

Questa pagina descrive in che modo i log di flusso dei report di log di flusso VPC sono di uso comune d'uso diversi. Consulta le seguenti sezioni per esempi di flussi di traffico campionati per log di flusso VPC.

Flussi da VM a VM nella stessa rete VPC

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

Per i flussi da VM a VM nella stessa rete VPC, i log di flusso vengono sia dalla VM richiedente che da quella che risponde, purché entrambe le VM siano in in cui sono abilitati i log di flusso VPC. In questo esempio, la VM 10.10.0.2 invia una richiesta con 1224 byte alla VM 10.50.0.2, anch'essa in una subnet con il logging abilitato. A sua volta, 10.50.0.2 risponde alla richiesta con un contenente 5342 byte. Sia la richiesta che la risposta vengono registrate le VM che effettuano richieste e quelle che rispondono.

Come segnalato richiedendo la VM (10.10.0.2)
richiesta/risposta	connection.src_ip	connection.dest_ip	bytes_sent	Annotazioni
richiesta	10.10.0.2	10.50.0.2	1.224	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 VM (10.50.0.2)
richiesta/risposta	connection.src_ip	connection.dest_ip	byte	Annotazioni
richiesta	10.10.0.2	10.50.0.2	1.224	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 la rete internet tra una VM all'interno di un VPC e un endpoint con un indirizzo IP esterno, I log vengono riportati solo dalla VM che si trova nella rete VPC:

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

In questo esempio, la VM 10.10.0.2 scambia pacchetti su internet con una endpoint con 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 dal VM di origine, 10.10.0.2. Il traffico in entrata di 5342 byte inviati 203.0.113.5 a 10.10.0.2 è segnalata dalla destinazione del traffico, VM 10.10.0.2.

richiesta/risposta	connection.src_ip	connection.dest_ip	bytes_sent	Annotazioni
richiesta	10.10.0.2	203.0.113.5	1.224	src_instance.* src_vpc.* località_destinazione.* 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

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

Per i flussi tra una VM in una rete VPC e una VM on-premise con un indirizzo IP interno, i log di flusso sono riportati dalla VM solo nella rete VPC:

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

In questo esempio, la VM 10.10.0.2 e l'endpoint on-premise 10.30.0.2 sono connesse 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 dal VM di origine, 10.10.0.2. Il traffico in entrata di 5342 byte inviati 10.30.0.2 a 10.10.0.2 è segnalata dalla destinazione del traffico, VM 10.10.0.2.

richiesta/risposta	connection.src_ip	connection.dest_ip	bytes_sent	Annotazioni
richiesta	10.10.0.2	10.30.0.2	1.224	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 nella subnet nel progetto host. Ad esempio, la subnet 10.10.0.0/20 appartiene a un Rete VPC condiviso condivisa definita in un progetto host. Puoi visualizzare i log di flusso VM appartenenti a questa subnet, incluse quelle create dai progetti di servizio. Nel In questo esempio, i progetti di servizio sono chiamati "web server", "recommendation", "database".

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

La tabella seguente 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 perché la subnet VPC appartiene al progetto host.
• src_instance.project_id e dest_instance.project_id sono per il 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	server web	host_project	10.10.0.20	suggerimento	host_project

I progetti di servizio non possiedono la rete VPC condiviso e non hanno ai log di flusso della rete VPC condiviso.

Flussi da VM a VM per il 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 reti VPC in peering sono segnalate come per gli utenti esterni endpoint: il progetto e altre informazioni di annotazione per l'altra VM vengono non specificato. Se entrambe le VM si trovano nello stesso progetto, anche se in diversi reti, quindi vengono fornite informazioni sul progetto e su altre annotazioni relative a un'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 test server web del progetto è connessa tramite peering di rete VPC. Se i log di flusso VPC sono abilitati in analytics-prod del progetto, il traffico (1224 byte) inviati da 10.10.0.2 a 10.50.0.2 sono registrati da VM 10.10.0.2, che è l'origine del flusso. Il traffico (5342 byte) inviati da 10.50.0.2 a 10.10.0.2 sono segnalati anche da VM 10.10.0.2, che è la destinazione del flusso.

In questo esempio, Log di flusso VPC non è attivato nel test server web del progetto, in modo che la VM 10.50.0.2 non registri alcun log.

autore segnalazione	connection.src_ip	connection.dest_ip	bytes_sent	Annotazioni
source	10.10.0.2	10.50.0.2	1.224	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 bilanciatore del carico di rete passthrough interno, L'ambiente guest Linux o Windows aggiunge l'indirizzo IP del bilanciatore del carico a nella tabella di routing locale della VM. Ciò consente alla VM di accettare pacchetti di richiesta con destinazioni impostate sull'indirizzo IP del bilanciatore del carico. Quando la VM risponde, invia direttamente la sua risposta; ma l'indirizzo IP di origine per di risposta predefinita è impostato sull'indirizzo IP del bilanciatore del carico, non sulla VM con bilanciamento del carico.

I flussi da VM a VM inviati tramite un bilanciatore del carico di rete passthrough interno vengono segnalati da entrambi sorgente e destinazione. Per un esempio di coppia richiesta / risposta HTTP, la seguente tabella spiega i campi delle voci di log di flusso osservate. Ai fini di questa illustrazione, consideriamo la seguente rete configurazione:

• Istanza del browser all'indirizzo 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	autore segnalazione	connection.src_ip	connection.dest_ip	connection.src_instance	connection.dest_instance
Richiesta	SRC	192.168.1.2	10,240,0,200	Istanza del browser
Richiesta	DEST	192.168.1.2	10,240,0,200	Istanza del browser	Istanza server web
Risposta	SRC	10.240.0.3	192.168.1.2	Istanza server web	Istanza del browser
Risposta	DEST	10,240,0,200	192.168.1.2		Istanza del browser

La VM richiedente non sa quale VM risponderà alla richiesta. Nel perché l'altra VM invia una risposta con il carico interno come indirizzo di origine, non sa quale VM ha risposto. Per questi motivi, la VM che ha inviato la richiesta non può aggiungere informazioni su dest_instance a proprio report, solo le informazioni src_instance. Poiché la risposta La VM conosce l'indirizzo IP dell'altra VM e può fornire sia src_instance e dest_instance.

Flusso dai 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 è risolta sull'IP del pod del server selezionato indirizzo (10.4.0.3) sulla porta di destinazione (8080).

Sui nodi perimetrale, il flusso viene campionato due volte con l'indirizzo IP tradotto e una porta. Per entrambi i punti di campionamento, identificheremo che il pod di destinazione servizio di supporto cluster-service sulla porta 8080 e annota il record con sia i dettagli del servizio che quelli dei pod. Se il traffico viene instradato a un pod sullo stesso nodo, il traffico non esce dal nodo e non è stato campionato.

In questo esempio, vengono trovati i record seguenti.

autore segnalazione	connection.src_ip	connection.dst_ip	bytes_sent	Annotazioni
SRC	10.4.0.2	10.4.0.3	1.224	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	1.224	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).

Traffico da un indirizzo IP esterno a un servizio GKE (35.35.35.35) è 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 su tutti i nodi in nel cluster, anche quelli che non eseguono un pod pertinente. Il traffico potrebbe richiedere più traffico per arrivare al pod pertinente. Per ulteriori informazioni, vedi Il networking all'esterno cluster.

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

In questo esempio, vengono trovati i record seguenti.

autore segnalazione	connection.src_ip	connection.dst_ip	bytes_sent	Annotazioni
DEST	203.0.113.1	35.35.35.35	1.224	src_location.* dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.service.*
SRC	10.0.12.2	10.4.0.2	1.224	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	1.224	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 GKE Ingress

Flussi in entrata (fai clic per ingrandire).

Viene terminata una connessione da un indirizzo IP pubblico a una destinazione Ingress per il servizio bilanciatore del carico. La connessione è mappata a una porta NodePort servizio 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, quando crei una risorsa Ingress, Il controller GKE Ingress configura Bilanciatore del carico HTTP(S) che distribuisce il traffico su tutti i nodi nel cluster, anche quelli che non eseguono un pod pertinente. Il traffico potrebbe richiedere salti extra per raggiungere al pod pertinente. Per ulteriori informazioni, vedi Networking all'esterno del cluster Il traffico viene quindi instradato dal nodo (10.0.12.2) al server selezionato Pod (10.4.0.2).

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

In questo esempio, vengono trovati i record seguenti.

autore segnalazione	connection.src_ip	connection.dst_ip	bytes_sent	Annotazioni
DEST	130.211.0.1	10.0.12.2	1.224	dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.service.*
SRC	10.0.12.2	10.4.0.2	1.224	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	1.224	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 GKE Ingress utilizzando il bilanciamento del carico nativo del container

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

Richieste da un indirizzo IP pubblico a una risorsa Ingress che sta utilizzando bilanciamento del carico nativo del container vengono terminate al bilanciatore del carico. In questo tipo di traffico, i pod vengono oggetti principali 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 Servizio sulla porta di destinazione (8080).

In questo esempio, è stato trovato il seguente record.

autore segnalazione	connection.src_ip	connection.dst_ip	bytes_sent	Annotazioni
DEST	130.211.0.1	10.4.0.2	1.224	dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.pod.* dest_gke_details.service.*

Flussi dai pod a esterni

Flusso di lavoro dal pod all'esterno (fai clic per ingrandire).

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

Per visualizzare le annotazioni dei pod per questo traffico, puoi configurare il l'agente mascherato non ha eseguito il mascheramento degli IP dei pod. In tal caso, per consentire al traffico a internet, puoi configurare Cloud NAT, che elabora l'IP del pod indirizzi IP esterni. Per ulteriori informazioni su Cloud NAT GKE, rivedi GKE un'interazione.

In questo esempio, è stato trovato il seguente record.

autore segnalazione	connection.src_ip	connection.dst_ip	bytes_sent	Annotazioni
SRC	10.0.12.2	203.0.113.1	1.224	src_instance.* src_vpc.* src_gke_details.cluster.* località_destinazione.* internet_routing_details.*

Passaggi successivi

• Configura log di flusso VPC
• Accedere ai log di flusso