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 seguenti sezioni per esempi di flussi di traffico campionati per log di flusso VPC.
Flussi di VM
Le seguenti sezioni includono esempi di come i log di flusso VPC campiona il traffico inviato e ricevuto dalle istanze di macchine virtuali (VM). Per informazioni su come i log di flusso VPC registrano i log di flusso per i pod di Google Kubernetes Engine (GKE), vedi Flussi GKE.
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
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, 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) | ||||
|---|---|---|---|---|
| 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 indirizzi IP esterni
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 riportati 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 inviati
203.0.113.5 a 10.10.0.2 è segnalata 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 | 5.342 |
dest_instance.* dest_vpc.* src_location.* |
Flussi VM-to-VM per VPC condiviso
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 un
Rete VPC condiviso condivisa 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 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'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_idedest_vpc.project_idsono per il progetto host perché la subnet VPC appartiene al progetto host.src_instance.project_idedest_instance.project_idsono per il servizio perché le istanze appartengono ai progetti di servizio.
|
connection .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
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 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 test server web del progetto è connessa tramite
peering di rete VPC.
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 | 1.224 |
src_instance.* src_vpc.* |
| destinazione | 10.50.0.2 | 10.10.0.2 | 5.342 |
dest_instance.* dest_vpc.* |
Flussi di VM con Cloud Load Balancing
Per i flussi attraverso Cloud Load Balancing, I log di flusso VPC annotano il traffico inviato attraverso una un bilanciatore del carico di rete passthrough, un bilanciatore del carico di rete proxy o un bilanciatore del carico delle applicazioni. Gli esempi seguenti presuppongono che questi bilanciatori del carico siano configurati bilanciatori del carico interni.
Da VM a VM passa attraverso un bilanciatore del carico di rete passthrough interno
Quando aggiungi una VM al servizio di backend per bilanciatore del carico di rete passthrough interno, Google Cloud aggiunge l'IP del bilanciatore del carico 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 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 in base al carico.
I flussi da VM a VM inviati tramite un bilanciatore del carico di rete passthrough interno vengono segnalati da entrambi sorgente e 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 | 1.224 |
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 | 5.342 |
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 | 1.224 |
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 è 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 del bilanciatore del carico di rete proxy da VM a interno e del bilanciatore del carico delle applicazioni da VM a interno
Il traffico passa attraverso un bilanciatore del carico di rete proxy interno o un bilanciatore del carico delle applicazioni interno viene segnalato da
alle VM client, purché la VM client si trovi in una subnet con
Log di flusso VPC abilitati. Ad esempio, una VM client con
l'indirizzo IP 10.10.0.2 invia una richiesta con 1224 byte al bilanciatore del carico
endpoint, 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 riportato 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 | 1.224 |
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 il bilanciatore del carico delle applicazioni) load_balancing.forwarding_rule_name load_balancing.vpc.* |
| rispondere | 10.10.0.3 | 10.10.0.2 | 5.342 |
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 da VM a VM tramite Private Service Connect
Per il traffico da VM a VM tramite Private Service Connect, Gli esempi di log di flusso VPC passano tra consumer di Private Service Connect servizi pubblicati.
Endpoint Private Service Connect a un servizio pubblicato
I flussi di traffico verso i servizi pubblicati di Private Service Connect sono:
nei report da VM sia consumer che producer, purché entrambe le VM siano in subnet
con log di flusso VPC abilitati. 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
all'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
progetto consumer e i log della VM producer sono disponibili
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 | 1.224 |
src_instance.* src_vpc.* psc.reporter psc.psc_endpoint.* psc.psc_attachment.* |
| rispondere | 10.10.0.3 | 10.10.0.2 | 5.342 |
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 | 1.224 |
dest_instance.* dest_vpc.* psc.reporter psc.psc_attachment.* |
| rispondere | 10.50.0.3 | 10.40.0.2 | 5.342 |
src_instance.* src_vpc.* psc.reporter psc.psc_attachment.* |
Flussi da VM a API di Google
Per il traffico della VM verso le API di Google tramite l'indirizzo IP esterno della VM, l'accesso privato Google o un endpoint Private Service Connect, i log flussi VPC annotano i record dei log con le informazioni sulle API di Google. La sezione seguente fornisce un esempio di come i log di flusso VPC annotano i record di 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 di traffico verso un'API di Google sono segnalati dalle VM consumer, purché la VM sia
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 alla
Endpoint Private Service Connect, 10.10.110.10. La richiesta viene inoltrata al servizio Google appropriato, ad esempio Cloud Storage. Nella
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) | ||||
|---|---|---|---|---|
| request/reply | connection.src_ip | connection.dest_ip | bytes_sent | Annotazioni |
| richiesta | 10.10.0.2 | 10.10.110.10 | 1.224 |
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
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 nell'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 indirizzato
a un pod sullo stesso nodo, non esce dal nodo e non viene affatto campionato.
In questo esempio, vengono trovati i record seguenti.
| reporter | 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
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
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, vedi
Il networking all'esterno
cluster.
Il traffico viene quindi instradato dal nodo (10.0.12.2) al pod di server selezionato (10.4.0.2). Entrambi i hop vengono registrati perché tutti gli archi del nodo vengono campionati. Nella
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 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 | 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
Una connessione da un indirizzo IP esterno a una destinazione Ingress viene terminata
nel servizio di bilanciamento del carico Cloud. 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 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, 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 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.
| 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 | 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 che utilizzano il bilanciamento del carico nativo del container
Richieste da un indirizzo IP esterno a una destinazione Ingress che utilizza
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 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.* |
Flussi dai pod a esterni
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 il l'agente mascherato non deve eseguire il mascheramento degli indirizzi 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 con GKE, consulta la sezione Interazione con GKE.
In questo esempio, è stato 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, tra cui di istanze gestite come nodi GKE e on-premise tra le API di Google e quelle on-premise endpoint e il traffico in transito tra on-premise endpoint. 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.
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 registrano i log di flusso:
- La VM. Segnala i log di flusso se la subnet a cui è connessa la VM è Log di flusso VPC abilitati.
- Il gateway che connette la rete VPC all'endpoint on-premise. Genera 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. Vengono registrate sia la richiesta che la risposta
sia dal collegamento VLAN per Cloud Interconnect
che dalla VM.
| Come segnalato 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 | 5.342 |
autore della segnalazione src_instance.* src_vpc.* dest_gateway.* |
| Come riportato dalla VM (10.10.0.2) | ||||
|---|---|---|---|---|
| richiesta/risposta | 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 | 5.342 |
reporter src_instance.* src_vpc.* dest_gateway.* |