Informazioni sui flussi di traffico

Questa pagina descrive come i log di flusso VPC generano log di flusso per casi d'uso comuni. Consulta le sezioni seguenti per esempi di flussi di traffico campionati da VPC Flow Logs.

Flussi VM

Le seguenti sezioni includono esempi di come i log di flusso VPC campionatano il traffico inviato e ricevuto dalle istanze di macchine virtuali (VM). Per informazioni su come VPC Flow Logs genera log dei flussi per i pod Google Kubernetes Engine (GKE), consulta Flussi GKE.

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, i log di flusso vengono registrati sia dalle VM che effettuano la richiesta sia da quelle che rispondono, a condizione che entrambe le VM si trovino in subnet 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, 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 sia la risposta vengono registrate sia dalla VM che effettua la richiesta sia da quella che risponde.

Come segnalato dalla VM che effettua la richiesta (10.10.0.2)
request/reply	connection.src_ip	connection.dest_ip	bytes_sent	Annotazioni
richiesta	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	5342	src_instance.* dest_instance.* src_vpc.* dest_vpc.*

Come segnalato dalla VM che risponde (10.50.0.2)
request/reply	connection.src_ip	connection.dest_ip	byte	Annotazioni
richiesta	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	5342	src_instance.* dest_instance.* src_vpc.* dest_vpc.*

Flussi dall'indirizzo IP della VM a quello esterno

Flussi da VM ad indirizzi IP esterni (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 dei flussi vengono registrati solo dalla VM che si trova nella rete VPC:

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

In questo esempio, la VM 10.10.0.2 scambia pacchetti su internet con un endpoint che ha l'indirizzo IP esterno 203.0.113.5. Il traffico in uscita di 1224 byte inviato da 10.10.0.2 a 203.0.113.5 viene registrato 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 registrato dalla destinazione del traffico, VM 10.10.0.2.

request/reply	connection.src_ip	connection.dest_ip	bytes_sent	Annotazioni
richiesta	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	5342	dest_instance.* dest_vpc.* src_location.*

Flussi VM-to-VM per VPC condiviso

Flui VPC condivisi (fai clic per ingrandire).

Per i flussi VM-to-VM per la VPC condivisa, puoi attivare 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 dei flussi delle VM appartenenti a questa subnet, inclusi quelli creati dai progetti di servizio. In questo esempio, i progetti di servizio si chiamano "web server", "recommendation", "database".

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

La tabella seguente mostra un flusso registrato 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 sottorete 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.

connection .src_ip	src_instance .project_id	src_vpc .project_id	connection .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 sono proprietari della rete VPC condiviso e non hanno accesso ai log di flusso della rete VPC condiviso.

Flussi VM-to-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 per le reti VPC in peering vengono registrati nello stesso modo degli endpoint esterni. Le informazioni sul progetto e altre annotazioni per l'altra VM non vengono fornite. 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 della VM 10.10.0.2 nel progetto webserver-test sono collegate tramite il peering di reti VPC.10.50.0.2 Se i log di flusso VPC sono abilitati nel progetto analytics-prod, il traffico (1.224 byte) inviato da 10.10.0.2 a 10.50.0.2 viene registrato 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 registrato anche dalla VM 10.10.0.2, che è la destinazione del flusso.

In questo esempio, i log di flusso VPC non sono attivati nel progetto webserver-test, pertanto nessun log viene registrato dalla VM 10.50.0.2.

reporter	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	5342	dest_instance.* dest_vpc.*

Flussi VM con Cloud Load Balancing

Per i flussi che passano attraverso Cloud Load Balancing, i log di flusso VPC annotano il traffico inviato tramite un bilanciatore del carico di rete passthrough, un bilanciatore del carico di rete proxy o un bilanciatore del carico delle applicazioni. I seguenti esempi presuppongono che questi bilanciatori del carico siano configurati come bilanciatori del carico interni.

I flussi VM-to-VM passano attraverso un bilanciatore del carico di rete passthrough interno

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, Google Cloud aggiunge l'indirizzo IP del bilanciatore del carico alla tabella di routing locale della VM. In questo modo, la VM può accettare pacchetti di richiesta con destinazioni impostate sull'indirizzo IP del bilanciatore del carico. Quando la VM risponde, invia la risposta direttamente; tuttavia, l'indirizzo IP di origine per i pacchetti di risposta è impostato sull'indirizzo IP del bilanciatore del carico, non sulla VM su cui viene eseguito il bilanciamento del carico.

I flussi da VM a VM inviati tramite un bilanciatore del carico di rete passthrough interno vengono registrati sia dalla sorgente sia dalla destinazione.

Come segnalato dalla VM client (192.168.1.2)
request/reply	connection.src_ip	connection.dest_ip	bytes_sent	Annotazioni
richiesta	192.168.1.2	10.240.0.200	1224	src_instance.* src_vpc.* load_balancing.forwarding_rule_project_id load_balancing.reporter load_balancing.type load_balancing.scheme load_balancing.forwarding_rule_name load_balancing.backend_service_name load_balancing.vpc.*
rispondere	10.240.0.200	192.168.1.2	5342	dest_instance.* dest_vpc.* load_balancing.forwarding_rule_project_id load_balancing.reporter load_balancing.type load_balancing.scheme load_balancing.forwarding_rule_name load_balancing.backend_service_name load_balancing.vpc.*

Come segnalato dalla VM di backend (10.240.0.3)
request/reply	connection.src_ip	connection.dest_ip	byte	Annotazioni
richiesta	192.168.1.2	10.240.0.200	1224	src_instance.* dest_instance.* src_vpc.* dest_vpc.* load_balancing.* (tutti i campi tranne url_map_name)
rispondere	10.240.0.200	192.168.1.2	5342	src_instance.* dest_instance.* src_vpc.* dest_vpc.* load_balancing.* (tutti i campi tranne url_map_name)

Nella richiesta che il bilanciatore del carico distribuisce alla VM di backend, l'indirizzo IP di origine è impostato sull'indirizzo IP della VM client. Ciò significa che la VM di backend può fornire informazioni su src_instance e dest_instance relative alla VM client. Tuttavia, a differenza della VM di backend, la VM client non può aggiungere al proprio report informazioni su src_instance e dest_instance relative alla VM di backend perché invia la richiesta e riceve la risposta dall'indirizzo IP del bilanciatore del carico, non dalla VM di backend.

Flussi di bilanciatori del carico di rete proxy interno VM-to-internal e bilanciatori del carico delle applicazioni VM-to-internal

I flussi di traffico che passano attraverso un bilanciatore del carico di rete proxy interno o un bilanciatore del carico delle applicazioni interno vengono registrati dalle VM client, a condizione che la VM client si trovi in una sottorete in cui sono abilitati i log di flusso VPC. Ad esempio, una VM client con l'indirizzo IP 10.10.0.2 invia una richiesta con 1224 byte all'endpoint del bilanciatore del carico, 10.10.0.3. La richiesta raggiunge quindi un backend. A sua volta, il backend risponde alla richiesta con una risposta contenente 5342 byte. Sia la richiesta che la risposta vengono registrate sulla VM client. I log della VM client sono disponibili nel progetto Google Cloud a cui appartiene la VM.

Come segnalato dalla VM client (10.10.0.2)
request/reply	connection.src_ip	connection.dest_ip	bytes_sent	Annotazioni
richiesta	10.10.0.2	10.10.0.3	1224	src_instance.* src_vpc.* load_balancing.forwarding_rule_project_id load_balancing.reporter load_balancing.type load_balancing.scheme load_balancing.url_map_name (per bilanciatore del carico delle applicazioni) load_balancing.forwarding_rule_name load_balancing.vpc.*
rispondere	10.10.0.3	10.10.0.2	5342	dest_instance.* dest_vpc.* load_balancing.forwarding_rule_project_id load_balancing.reporter load_balancing.type load_balancing.scheme load_balancing.url_map_name (per bilanciatore del carico delle applicazioni) load_balancing.forwarding_rule_name load_balancing.vpc.*

Flussi VM-to-VM tramite Private Service Connect

Per il traffico VM-to-VM tramite Private Service Connect, i log flussi VPC acquisiscono i flussi tra i consumer di Private Service Connect e i servizi pubblicati.

Endpoint Private Service Connect a un servizio pubblicato

Il traffico VM passa attraverso Private Service Connect (fai clic per ingrandire).

I flussi di traffico verso i servizi pubblicati di Private Service Connect vengono registrati sia dalle VM consumer che da quelle producer, a condizione che entrambe le VM si trovino in subnet in cui sono abilitati i log dei flussi VPC. In questo esempio, la VM consumer,10.10.0.2, invia una richiesta con 1224 byte all'endpoint Private Service Connect, 10.10.0.3. Nella VPC del produttore, l'indirizzo IP di origine della richiesta viene tradotto in un indirizzo IP nella subnet di attacco del servizio, che in questo esempio è 10.40.0.2. L'indirizzo IP di destinazione della richiesta viene tradotto nell'indirizzo IP del bilanciatore del carico di rete passthrough interno, 10.50.0.3. La richiesta raggiunge quindi la VM di backend 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 sia la risposta vengono registrate sia dalle VM che effettuano la richiesta sia da quelle che rispondono. I log della VM consumer sono disponibili nel progetto consumer e i log della VM producer sono disponibili nel progetto producer.

Come riportato dalla VM consumer (10.10.0.2)
request/reply	connection.src_ip	connection.dest_ip	bytes_sent	Annotazioni
richiesta	10.10.0.2	10.10.0.3	1224	src_instance.* src_vpc.* psc.reporter psc.psc_endpoint.* psc.psc_attachment.*
rispondere	10.10.0.3	10.10.0.2	5342	dest_instance.* dest_vpc.* psc.reporter psc.psc_endpoint.* psc.psc_attachment.*

Come segnalato dalla VM del produttore (10.50.0.2)
request/reply	connection.src_ip	connection.dest_ip	bytes_sent	Annotazioni
richiesta	10.40.0.2	10.50.0.3	1224	dest_instance.* dest_vpc.* psc.reporter psc.psc_attachment.*
rispondere	10.50.0.3	10.40.0.2	5342	src_instance.* src_vpc.* psc.reporter psc.psc_attachment.*

Flussi API da VM a Google

Per il traffico della VM verso le API di Google tramite l'indirizzo IP esterno della VM, Accesso privato Google o un endpoint Private Service Connect, i log flussi VPC annotano i record dei log con le informazioni dell'API di Google. La sezione seguente fornisce un esempio di come i log di flusso VPC annotano i record dei log per una VM che accede a un'API di Google globale tramite un endpoint Private Service Connect.

VM a un'API di Google globale tramite Private Service Connect

I flussi della VM alle API di Google tramite Private Service Connect (fai clic per ingrandire).

I flussi di traffico verso un'API Google vengono registrati dalle VM consumer, a condizione che la VM si trovi in una subnet in cui sono abilitati i log di flusso VPC. In questo esempio, la VM consumer 10.10.0.2 invia una richiesta con 1224 byte all'endpoint Private Service Connect 10.10.110.10. La richiesta viene inoltrata al servizio Google appropriato, ad esempio Cloud Storage. A sua volta, Cloud Storage risponde alla richiesta con una risposta contenente 5342 byte. Sia la richiesta che la risposta vengono registrate dalla VM che effettua la richiesta.

Come riportato dalla VM consumer (10.10.0.2)
request/reply	connection.src_ip	connection.dest_ip	bytes_sent	Annotazioni
richiesta	10.10.0.2	10.10.110.10	1224	src_instance.* src_vpc.* psc.reporter psc.psc_endpoint.* dest_google_service.*
rispondere	10.10.110.10	10.10.0.2	5342	src_google_service.* dest_instance.* dest_vpc.* psc.reporter psc.psc_endpoint.*

Flussi GKE

Le sezioni seguenti includono esempi di come i log di flusso VPC campionati il traffico GKE da e verso i pod.

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

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

In questo esempio vengono trovati i seguenti record.

reporter	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 di LoadBalancer esterni GKE

Flui di bilanciatori del carico esterni (fai clic per ingrandire).

Il traffico da un indirizzo IP esterno a un servizio GKE (35.35.35.35) viene instradato a un nodo del 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 su cui non è in esecuzione un pod pertinente. Il traffico potrebbe richiedere hop aggiuntivi per raggiungere il pod pertinente. Per ulteriori informazioni, consulta la sezione Networking al di fuori del cluster.

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

In questo esempio vengono trovati i seguenti record.

reporter	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 GKE Ingress

Flusso in entrata (fai clic per ingrandire)

.

Una connessione da un indirizzo IP esterno a una destinazione Ingress viene terminata nel servizio di Cloud Load Balancing. La connessione viene mappata a un servizio NodePort in base all'URL. Per soddisfare 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 il NodePort del servizio. Per impostazione predefinita, quando viene creato un oggetto Ingress, il controller Ingress di GKE configura un bilanciatore del carico HTTP(S) che distribuisce il traffico su tutti i nodi del cluster, anche su quelli che non eseguono un pod pertinente. Il traffico potrebbe richiedere hop aggiuntivi per raggiungere il pod pertinente. Per ulteriori informazioni, consulta la sezione Networking al di fuori del cluster. Il traffico viene quindi instradato dal nodo (10.0.12.2) al pod del server selezionato (10.4.0.2).

Entrambi gli hop vengono registrati perché tutti gli archi dei nodi vengono campionati. Per il primo hop, identifichiamo il servizio in base alla porta Node del servizio (60000). Per il secondo hop, identifichiamo il pod di destinazione che supporta il servizio sulla porta di destinazione (8080). Il secondo hop viene registrato dai punti di campionamento di entrambi i nodi. Tuttavia, se il traffico viene indirizzato a un pod sullo stesso nodo (10.4.0.3), il secondo hop non viene registrato perché il traffico non ha lasciato il nodo.

In questo esempio vengono trovati i seguenti record.

reporter	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 GKE Ingress che utilizzano il bilanciamento del carico nativo del container

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

Le richieste da un indirizzo IP esterno a una destinazione Ingress che utilizza il bilanciamento del carico nativo del container vengono interrotte al bilanciatore del carico. In questo tipo di Ingress, i pod sono 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 sta eseguendo il backup del servizio sulla porta di destinazione (8080).

In questo esempio viene trovato il seguente record.

reporter	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.*

Pod ai flussi esterni

Flusso da pod a esterno (fai clic per ingrandire).

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

Per visualizzare le annotazioni dei pod per questo traffico, puoi configurare l'agente di mascheramento in modo che non mascheri gli indirizzi IP dei pod. In questo caso, per consentire il traffico su internet, puoi configurare Cloud NAT, che elabora gli indirizzi IP dei pod. Per ulteriori informazioni su Cloud NAT con GKE, consulta la sezione Interazione con GKE.

In questo esempio viene trovato il seguente record.

reporter	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.*

Flussi di connettività ibrida

Per il traffico tra Google Cloud e le reti on-premise, i log di flusso VPC annotano i flussi tra le istanze VM, incluse quelle utilizzate come nodi GKE, e gli endpoint on-premise, tra le API Google e gli endpoint on-premise e il traffico in transito tra gli endpoint on-premise. L'esempio seguente descrive come i log di flusso VPC annotano i flussi tra le istanze VM in una rete VPC e un endpoint 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 registrati solo da Google Cloud. Le seguenti risorse generano log di flusso:

• La VM. Genera log di flusso se nella subnet a cui è connessa la VM sono attivati i log di flusso VPC.
• Il gateway che connette la rete VPC all'endpoint on-premise. Genera report sui log di flusso se nel gateway sono abilitati i log di flusso VPC.

Nel diagramma precedente, l'endpoint on-premise 10.30.0.2 invia una richiesta con 1224 byte alla VM 10.0.0.2 nella rete VPC tramite Cloud Interconnect. A sua volta, la VM 10.0.0.2 risponde alla richiesta con una risposta contenente 5243 byte. Sia la richiesta che la risposta vengono registrate sia dal collegamento VLAN per Cloud Interconnect sia dalla VM.

Come indicato dal collegamento VLAN
request/reply	connection.src_ip	connection.dest_ip	bytes_sent	Annotazioni
richiesta	10.30.0.2	10.10.0.2	1224	reporter src_gateway.* dest_instance.* dest_vpc.*
rispondere	10.10.0.2	10.30.0.2	5342	reporter src_instance.* src_vpc.* dest_gateway.*

Come segnalato dalla VM (10.10.0.2)
request/reply	connection.src_ip	connection.dest_ip	bytes_sent	Annotazioni
richiesta	10.30.0.2	10.10.0.2	1224	reporter src_gateway.* dest_instance.* dest_vpc.*
rispondere	10.10.0.2	10.30.0.2	5342	reporter src_instance.* src_vpc.* dest_gateway.*

Passaggi successivi

• Configurare i log di flusso VPC
• Log di flusso di accesso