Informazioni sui flussi di traffico

Questa pagina descrive il modo in cui i log di flusso VPC registrano i log per i flussi di traffico comuni. Per alcuni esempi, consulta le sezioni seguenti:

• Flussi VM, flussi GKE e flussi di connettività ibrida descrivono i flussi all'interno di Trusted Cloud by S3NS e i flussi tra Trusted Cloud e le risorse al di fuori di Trusted Cloud. Gli esempi per i flussi tra progettiTrusted Cloud diversi presuppongono che i log di flusso VPC siano configurati a livello di progetto.
• Flussi tra reti VPC in progetti diversi descrive come vengono annotate le annotazioni tra progetti quando i log di flusso VPC sono configurati a livello di organizzazione.

Flussi VM

Le sezioni seguenti forniscono esempi di come i log di flusso VPC annotano i flussi di traffico da e verso le istanze di macchine virtuali (VM).

Flussi da VM a VM nella stessa rete VPC

Per i flussi da VM a VM nella stessa rete VPC, i log di flusso vengono registrati sia dalle VM richiedenti che da quelle rispondenti, 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 con il logging abilitato. 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 richiedenti e rispondenti.

Come segnalato dalla VM richiedente (10.10.0.2)
richiesta/risposta	connection.src_ip	connection.dest_ip	bytes_sent	Annotazioni
richiesta	10.10.0.2	10.50.0.2	1224	src_instance.* src_vpc.* dest_instance.* dest_vpc.*
rispondere	10.50.0.2	10.10.0.2	5342	src_instance.* src_vpc.* dest_instance.* dest_vpc.*

Come segnalato dalla VM che risponde (10.50.0.2)
richiesta/risposta	connection.src_ip	connection.dest_ip	bytes_sent	Annotazioni
richiesta	10.10.0.2	10.50.0.2	1224	src_instance.* src_vpc.* dest_instance.* dest_vpc.*
rispondere	10.50.0.2	10.10.0.2	5342	src_instance.* src_vpc.* dest_instance.* dest_vpc.*

Flussi da VM a indirizzo IP esterno

Per i flussi che attraversano internet tra una VM che si trova 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 segnalati 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 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 inviati da 203.0.113.5 a 10.10.0.2 viene segnalato dalla destinazione del traffico, la 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	1224	src_instance.* src_vpc.* dest_location.* internet_routing_details.*
rispondere	203.0.113.5	10.10.0.2	5342	src_location.* dest_instance.* dest_vpc.*

Flussi da VM a VM per VPC condiviso

Per i flussi da VM a VM per la VPC condivisa, 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, incluse quelle create dai progetti di servizio. In questo esempio, i progetti di servizio sono denominati "web server", "recommendation" e "database".

Per i flussi da VM a VM, se entrambe le VM si trovano nello stesso progetto o, nel caso di una rete condivisa, nello stesso progetto host, le annotazioni per l'ID progetto e simili vengono fornite 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 seguente tabella mostra un flusso segnalato 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 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 reteVPC condivisoa.

Flussi da VM a VM per il peering di rete VPC

A meno che entrambe le VM non si trovino nello stesso progetto Trusted Cloud by S3NS , i flussi da VM a VM per le reti VPC con peering vengono segnalati nello stesso modo degli endpoint esterni: non vengono forniti il progetto e altre informazioni di annotazione per l'altra VM. Se entrambe le VM si trovano nello stesso progetto, anche se in reti diverse, vengono fornite anche le informazioni sul progetto e altre annotazioni per l'altra VM.

In questo esempio, le subnet della VM 10.10.0.2 nel progetto analytics-prod e della VM 10.50.0.2 nel progetto webserver-test sono connesse tramite il peering di rete VPC. Se i log di flusso VPC sono abilitati in analytics-prod, 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, i log di flusso VPC non sono attivati nel progetto webserver-test, quindi non vengono registrati log 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 da VM a VM tramite Private Service Connect

I log di flusso VPC annotano i flussi tra i consumer di Private Service Connect e i servizi pubblicati. L'esempio seguente descrive in che modo i log di flusso VPC annotano i record di log per le VM consumer e producer.

I flussi di traffico verso i servizi pubblicati di Private Service Connect vengono segnalati sia dalle VM consumer che da quelle producer, a condizione che entrambe le VM si trovino in subnet in cui sono attivati i log di flusso VPC. In questo esempio, la VM consumer, 10.10.0.2, invia una richiesta di 1224 byte all'endpoint Private Service Connect, 10.10.0.3. Nel VPC del produttore, l'indirizzo IP di origine della richiesta viene convertito in un indirizzo IP nella subnet dell'allegato di servizio, che, in questo esempio, è 10.40.0.2. L'indirizzo IP di destinazione della richiesta viene convertito 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 con la registrazione abilitata. 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 richiedenti e rispondenti. I log della VM consumer sono disponibili nel progetto consumer, mentre i log della VM producer sono disponibili nel progetto producer.

Come riportato dalla VM consumer (10.10.0.2)
richiesta/risposta	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)
richiesta/risposta	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 VM verso le API di Google tramite l'indirizzo IP esterno della VM, l'accesso privato Google o un endpoint Private Service Connect, VPC Flow Logs annota i record di log con le informazioni sulle API di Google.

L'esempio seguente descrive in che modo i log di flusso VPC annotano i record di log per una VM che accede a un'API Google globale tramite un endpoint Private Service Connect.

Il traffico verso un'API Google viene segnalato 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 di 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 richiedente.

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

Il flusso di VM tramite 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.

Flussi da VM a VM tramite un bilanciatore del carico di rete passthrough interno

Quando aggiungi una VM al servizio di backend per un bilanciatore del carico di rete passthrough interno, Trusted Cloud 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 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 bilanciata.

I flussi da VM a VM inviati tramite un bilanciatore del carico di rete passthrough interno vengono segnalati sia dall'origine sia dalla destinazione.

Come segnalato dalla VM client (192.168.1.2)
richiesta/risposta	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)
richiesta/risposta	connection.src_ip	connection.dest_ip	bytes_sent	Annotazioni
richiesta	192.168.1.2	10.240.0.200	1224	src_instance.* src_vpc.* dest_instance.* dest_vpc.* load_balancing.* (tutti i campi tranne url_map_name)
rispondere	10.240.0.200	192.168.1.2	5342	src_instance.* src_vpc.* dest_instance.* 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 src_instance e dest_instance sulla VM client. Tuttavia, a differenza della VM di backend, la VM client non può aggiungere src_instance e dest_instance informazioni sulla VM di backend al proprio report perché invia la richiesta e riceve la risposta dall'indirizzo IP del bilanciatore del carico, non dalla VM di backend.

Il flusso di VM passa attraverso un bilanciatore del carico di rete proxy interno o un bilanciatore del carico delle applicazioni interno

Il traffico che passa attraverso un bilanciatore del carico di rete proxy interno o un bilanciatore del carico delle applicazioni interno viene segnalato dalle VM client, a condizione che la VM client si trovi in una subnet in cui sono attivi 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 Trusted Cloud a cui appartiene la VM.

Come segnalato dalla VM client (10.10.0.2)
richiesta/risposta	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 (for Application Load Balancer) 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 (for Application Load Balancer) load_balancing.forwarding_rule_name load_balancing.vpc.*

Flussi GKE

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

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

Sugli edge 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 è il servizio di backend cluster-service sulla porta 8080 e annoteremo il record con i dettagli del servizio e del pod. Se il traffico viene indirizzato a un pod sullo stesso nodo, il traffico 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 LoadBalancer esterni di GKE

Il traffico da un indirizzo IP esterno a un servizio GKE (35.35.35.35) viene indirizzato 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 su tutti i nodi del cluster, anche quelli che non eseguono un pod pertinente. Il traffico potrebbe richiedere hop aggiuntivi per raggiungere il pod pertinente. Per saperne di più, 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é vengono campionati tutti i bordi dei nodi. 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 verrà 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 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 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

Una connessione da un indirizzo IP esterno a una destinazione Ingress viene terminata nel servizio Cloud Load Balancing. La connessione viene 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, quando crei 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 quelli che non eseguono un pod pertinente. Il traffico potrebbe richiedere hop aggiuntivi per raggiungere il pod pertinente. Per saperne di più, consulta Networking all'esterno 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é vengono campionati tutti i bordi dei nodi. Per il primo hop, identifichiamo il servizio in base alla NodePort del servizio (60000). Per il secondo hop, 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 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 di GKE Ingress che utilizzano il bilanciamento del carico nativo del container

Le richieste da un indirizzo IP esterno a una destinazione Ingress che utilizza il bilanciamento del carico nativo del container vengono terminate nel 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 supporta il 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 a flussi esterni

Il traffico da un pod (10.4.0.3) a un IP esterno (203.0.113.1) viene modificato dal mascheramento 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 mascherare il traffico verso destinazioni esterne. Per saperne di più, 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 a internet, puoi configurare Cloud NAT, che elabora gli indirizzi IP dei pod. Per saperne di più su Cloud NAT con GKE, consulta la sezione Interazione 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 la connettività ibrida tramite i collegamenti VLAN per i tunnel Cloud Interconnect e Cloud VPN, i log di flusso VPC annotano i seguenti flussi:

• Flussi tra istanze VM, incluse quelle utilizzate come nodi GKE, ed endpoint on-premise
• Flussi tra i servizi Google e gli endpoint on-premise
• Flussi di transito tra gli endpoint on-premise

L'esempio seguente descrive in che modo i log di flusso VPC annotano i flussi tra un'istanza VM in una rete VPC e un endpoint on-premise. La rete è collegata all'endpoint tramite un collegamento VLAN per Cloud Interconnect.

Per i flussi tra una VM che si trova in una rete VPC e un endpoint on-premise con un indirizzo IP interno, i log dei flussi vengono segnalati solo daTrusted Cloud . Le seguenti risorse registrano i log di flusso:

• La VM. Registra i log di flusso se la subnet a cui è connessa la VM ha i log di flusso VPC abilitati.
• Il gateway che connette la rete VPC all'endpoint on-premise. Registra i log di flusso se il gateway (in questo esempio, il collegamento VLAN) ha i log di flusso VPC abilitati.

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. 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 sia dalla VM.

Come segnalato dal collegamento VLAN
richiesta/risposta	connection.src_ip	connection.dest_ip	bytes_sent	Annotazioni
richiesta	10.30.0.2	10.0.0.2	1224	src_gateway.* dest_instance.* dest_vpc.*
rispondere	10.0.0.2	10.30.0.2	5342	src_instance.* src_vpc.* dest_gateway.*

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

Flussi tra reti VPC in progetti diversi

Se i log di flusso VPC sono configurati per un'organizzazione e le annotazioni tra progetti sono abilitate (impostazione predefinita), i flussi di traffico tra le reti VPC in progetti diversi vengono annotati nello stesso modo dei flussi di traffico tra le reti VPC nello stesso progetto; i record di log per questi flussi forniscono informazioni su entrambi i lati della connessione.

Se le annotazioni tra progetti sono disattivate, i record di log forniscono informazioni solo sul reporter del flusso di traffico.

Annotazioni tra progetti abilitate

L'esempio seguente descrive in che modo i log di flusso VPC annotano i record di log per i flussi da VM a VM tra progetti quando le annotazioni tra progetti sono abilitate. Le annotazioni tra progetti sono disponibili per i flussi di traffico tramite VPC condiviso, peering di rete VPC e Network Connectivity Center.

La VM 10.0.0.2 invia una richiesta con 1224 byte alla VM 10.0.0.1.2. A sua volta, VM 10.0.0.1.2 risponde alla richiesta con una risposta contenente 5342 byte. Sia la richiesta che la risposta vengono registrate dalle VM richiedenti e rispondenti.

Come segnalato dalla VM richiedente (10.0.0.2)
richiesta/risposta	connection.src_ip	connection.dest_ip	bytes_sent	Annotazioni
richiesta	10.0.0.2	10.0.1.2	1224	src_instance.* src_vpc.* dest_instance.* dest_vpc.*
rispondere	10.0.1.2	10.0.0.2	5342	src_instance.* src_vpc.* dest_instance.* dest_vpc.*

Come segnalato dalla VM che risponde (10.0.1.2)
richiesta/risposta	connection.src_ip	connection.dest_ip	bytes_sent	Annotazioni
richiesta	10.0.0.2	10.0.1.2	1224	src_instance.* src_vpc.* dest_instance.* dest_vpc.*
rispondere	10.0.1.2	10.0.0.2	5342	src_instance.* src_vpc.* dest_instance.* dest_vpc.*

Annotazioni tra progetti disabilitate

L'esempio seguente descrive in che modo i log di flusso VPC annotano i record di log per i flussi da VM a VM tra progetti quando le annotazioni tra progetti sono disattivate.

La VM 10.0.0.2 invia una richiesta con 1224 byte alla VM 10.0.0.1.2. A sua volta, VM 10.0.0.1.2 risponde alla richiesta con una risposta contenente 5342 byte. Sia la richiesta che la risposta vengono registrate dalle VM richiedenti e rispondenti. Tuttavia, non vengono fornite informazioni sull'altra VM.

Come segnalato dalla VM richiedente (10.0.0.2)
richiesta/risposta	connection.src_ip	connection.dest_ip	bytes_sent	Annotazioni
richiesta	10.0.0.2	10.0.1.2	1224	src_instance.* src_vpc.*
rispondere	10.0.1.2	10.0.0.2	5342	dest_instance.* dest_vpc.*

Come segnalato dalla VM che risponde (10.0.1.2)
richiesta/risposta	connection.src_ip	connection.dest_ip	bytes_sent	Annotazioni
richiesta	10.0.0.2	10.0.1.2	1224	dest_instance.* dest_vpc.*
rispondere	10.0.1.2	10.0.0.2	5342	src_instance.* src_vpc.*

Passaggi successivi

• Configura log di flusso VPC
• Log di flusso di accesso