Acerca dos fluxos de tráfego
Esta página descreve como os registos de fluxo da VPC comunicam registos para fluxos de tráfego comuns. Consulte as secções seguintes para ver exemplos:
- Os fluxos de VMs, os fluxos do GKE e os fluxos de conetividade híbrida descrevem fluxos dentro Google Cloud e fluxos entre Google Cloud e recursos fora de Google Cloud. Os exemplos de fluxos entre diferentes Google Cloud projetos pressupõem que os registos de fluxo da VPC estão configurados ao nível do projeto.
- Fluxos entre redes VPC em projetos diferentes descreve como os fluxos entre projetos são anotados quando os registos de fluxo de VPC são configurados ao nível da organização.
Fluxos de VMs
As secções seguintes fornecem exemplos de como os registos de fluxo da VPC anotam os fluxos de tráfego de e para instâncias de máquinas virtuais (VMs).
Fluxos de VM para VM na mesma rede VPC
Para fluxos de VM para VM na mesma rede da VPC, os registos de fluxo são
comunicados a partir das VMs de pedido e de resposta, desde que ambas as VMs estejam em
sub-redes com os registos de fluxo de VPC ativados. Neste exemplo, a VM 10.10.0.2 envia um pedido com 1224 bytes para a VM 10.50.0.2, que também está numa sub-rede com o registo ativado. Por sua vez, 10.50.0.2 responde ao pedido com uma resposta que contém 5342 bytes. O pedido e a resposta são registados a partir das VMs de pedido e de resposta.
| Conforme comunicado pela VM de pedido (10.10.0.2) | ||||
|---|---|---|---|---|
| pedido/resposta | connection.src_ip | connection.dest_ip | bytes_sent | Notas |
| pedido | 10.10.0.2 | 10.50.0.2 | 1224 |
src_instance.* src_vpc.* dest_instance.* dest_vpc.* |
| resposta | 10.50.0.2 | 10.10.0.2 | 5342 |
src_instance.* src_vpc.* dest_instance.* dest_vpc.* |
| Conforme comunicado pela VM de resposta (10.50.0.2) | ||||
|---|---|---|---|---|
| pedido/resposta | connection.src_ip | connection.dest_ip | bytes_sent | Notas |
| pedido | 10.10.0.2 | 10.50.0.2 | 1224 |
src_instance.* src_vpc.* dest_instance.* dest_vpc.* |
| resposta | 10.50.0.2 | 10.10.0.2 | 5342 |
src_instance.* src_vpc.* dest_instance.* dest_vpc.* |
Fluxos de endereços IP externos para VMs
Para fluxos que atravessam a Internet entre uma VM numa rede VPC e um ponto final com um endereço IP externo, os registos de fluxo são comunicados apenas a partir da VM que está na rede VPC:
- Para fluxos de saída, os registos são comunicados a partir da VM da rede VPC que é a origem do tráfego.
- Para fluxos de entrada, os registos são comunicados a partir da VM da rede da VPC que é o destino do tráfego.
Neste exemplo, a VM 10.10.0.2 troca pacotes através da Internet com um ponto final que tem o endereço IP externo 203.0.113.5. O tráfego de saída
de 1224 bytes enviados de 10.10.0.2 para 203.0.113.5 é comunicado a partir da VM de origem, 10.10.0.2. O tráfego de entrada de 5342 bytes enviados de
203.0.113.5 para 10.10.0.2 é comunicado a partir do destino do tráfego,
VM 10.10.0.2.
| pedido/resposta | connection.src_ip | connection.dest_ip | bytes_sent | Notas |
|---|---|---|---|---|
| pedido | 10.10.0.2 | 203.0.113.5 | 1224 |
src_instance.* src_vpc.* dest_location.* internet_routing_details.* |
| resposta | 203.0.113.5 | 10.10.0.2 | 5342 |
src_location.* dest_instance.* dest_vpc.* |
Fluxos de VM para VM para VPC partilhada
Para fluxos de VM para VM para VPC partilhada, pode ativar os registos de fluxo de VPC para a sub-rede no projeto anfitrião. Por exemplo, a sub-rede 10.10.0.0/20 pertence a uma rede de VPC partilhada definida num projeto anfitrião. Pode ver registos de fluxo de VMs pertencentes a esta sub-rede, incluindo as criadas por projetos de serviço. Neste exemplo, os projetos de serviço chamam-se "servidor Web", "recomendação" e "base de dados".
Para fluxos de VM para VM, se ambas as VMs estiverem no mesmo projeto ou, no caso de uma rede partilhada, no mesmo projeto anfitrião, as anotações para o ID do projeto e semelhantes são fornecidas para o outro ponto final na ligação. Se a outra VM estiver num projeto diferente, as anotações para a outra VM não são fornecidas.
A tabela seguinte mostra um fluxo conforme comunicado por 10.10.0.10 ou 10.10.0.20.
src_vpc.project_idedest_vpc.project_iddestinam-se ao projeto anfitrião, porque a sub-rede da VPC pertence ao projeto anfitrião.src_instance.project_idedest_instance.project_iddestinam-se aos projetos de serviço, uma vez que as instâncias pertencem aos projetos de serviço.
|
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 | servidor Web | host_project | 10.10.0.20 | recomendação | host_project |
Os projetos de serviço não são proprietários da rede VPC partilhada e não têm acesso aos registos de fluxo da rede VPC partilhada.
Fluxos de VM para VM para o intercâmbio da rede da VPC
A menos que ambas as VMs estejam no mesmo Google Cloud projeto, os fluxos de VM para VM para redes da VPC com peering são comunicados da mesma forma que para pontos finais externos. As informações do projeto e outras informações de anotação para a outra VM não são fornecidas. Se ambas as VMs estiverem no mesmo projeto, mesmo que em redes diferentes, as informações do projeto e de outras anotações também são fornecidas para a outra VM.
Neste exemplo, as sub-redes da VM 10.10.0.2 no projeto analytics-prod e da VM 10.50.0.2 no projeto webserver-test estão ligadas através do intercâmbio das redes da VPC.
Se os registos de fluxo de VPC estiverem ativados no projeto analytics-prod, o tráfego (1224 bytes) enviado de 10.10.0.2 para 10.50.0.2 é comunicado a partir da VM 10.10.0.2, que é a origem do fluxo. O tráfego (5342 bytes) enviado de 10.50.0.2 para 10.10.0.2 também é comunicado a partir da VM 10.10.0.2, que é o destino do fluxo.
Neste exemplo, os registos de fluxo da VPC não estão ativados no projeto webserver-test, pelo que a VM 10.50.0.2 não regista nenhum registo.
| origem | connection.src_ip | connection.dest_ip | bytes_sent | Notas |
|---|---|---|---|---|
| fonte | 10.10.0.2 | 10.50.0.2 | 1224 |
src_instance.* src_vpc.* |
| destino | 10.50.0.2 | 10.10.0.2 | 5342 |
dest_instance.* dest_vpc.* |
Fluxos de VM para VM através do Private Service Connect
Os registos de fluxo da VPC anotam fluxos entre consumidores do Private Service Connect e serviços publicados. O exemplo seguinte descreve como os VPC Flow Logs anotam os registos para VMs de consumidor e produtor.
O fluxo de tráfego para os serviços publicados do Private Service Connect é comunicado a partir das VMs do consumidor e do produtor, desde que ambas as VMs estejam em sub-redes com os registos de fluxo da VPC ativados. Neste exemplo, a VM do consumidor, 10.10.0.2, envia um pedido com 1224 bytes para o ponto final do Private Service Connect, 10.10.0.3. Na VPC do produtor, o endereço IP de origem do pedido é traduzido para um endereço IP na sub-rede do anexo de serviço que, neste exemplo, é 10.40.0.2. O endereço IP de destino do pedido é traduzido para o endereço IP do Network Load Balancer de passagem interno, 10.50.0.3. O pedido chega então à VM de back-end, 10.50.0.2, que também está numa sub-rede com o registo ativado.
Por sua vez, 10.50.0.2 responde ao pedido com uma resposta que contém 5342 bytes. O pedido e a resposta são registados a partir das VMs que enviam e
recebem o pedido. Os registos da VM do consumidor estão disponíveis no projeto do consumidor, e os registos da VM do produtor estão disponíveis no projeto do produtor.
| Conforme comunicado pela VM do consumidor (10.10.0.2) | ||||
|---|---|---|---|---|
| pedido/resposta | connection.src_ip | connection.dest_ip | bytes_sent | Notas |
| pedido | 10.10.0.2 | 10.10.0.3 | 1224 |
src_instance.* src_vpc.* psc.reporter psc.psc_endpoint.* psc.psc_attachment.* |
| resposta | 10.10.0.3 | 10.10.0.2 | 5342 |
dest_instance.* dest_vpc.* psc.reporter psc.psc_endpoint.* psc.psc_attachment.* |
| Conforme comunicado pela VM do produtor (10.50.0.2) | ||||
|---|---|---|---|---|
| pedido/resposta | connection.src_ip | connection.dest_ip | bytes_sent | Notas |
| pedido | 10.40.0.2 | 10.50.0.3 | 1224 |
dest_instance.* dest_vpc.* psc.reporter psc.psc_attachment.* |
| resposta | 10.50.0.3 | 10.40.0.2 | 5342 |
src_instance.* src_vpc.* psc.reporter psc.psc_attachment.* |
Fluxos de API de VM para Google
Para o tráfego de VMs para APIs Google através do endereço IP externo da VM, do acesso privado à Google ou de um ponto final do Private Service Connect, os registos de fluxo da VPC anotam os registos com informações da API Google.
O exemplo seguinte descreve como os registos de fluxo da VPC anotam registos para uma VM que acede a uma API Google global através de um ponto final do Private Service Connect.
O tráfego para uma API Google é comunicado pelas VMs consumidoras, desde que a VM esteja numa sub-rede com os registos de fluxo da VPC ativados. Neste exemplo,
a VM do consumidor, 10.10.0.2, envia um pedido com 1224 bytes para o
ponto final do Private Service Connect, 10.10.110.10. O pedido é encaminhado para o serviço Google adequado, por exemplo, o Cloud Storage. Por sua vez, o Cloud Storage responde ao pedido com uma resposta que contém 5342 bytes. O pedido e a resposta são registados a partir da VM que faz o pedido.
| Conforme comunicado pela VM do consumidor (10.10.0.2) | ||||
|---|---|---|---|---|
| pedido/resposta | connection.src_ip | connection.dest_ip | bytes_sent | Notas |
| pedido | 10.10.0.2 | 10.10.110.10 | 1224 |
src_instance.* src_vpc.* dest_google_service.* psc.reporter psc.psc_endpoint.* |
| resposta | 10.10.110.10 | 10.10.0.2 | 5342 |
src_google_service.* dest_instance.* dest_vpc.* psc.reporter psc.psc_endpoint.* |
Fluxos de VMs através do Cloud Load Balancing
Os VPC Flow Logs anotam o tráfego enviado através de um balanceador de carga de rede de passagem, um balanceador de carga de rede de proxy ou um balanceador de carga de aplicações. Os exemplos seguintes partem do princípio de que estes balanceadores de carga estão configurados como balanceadores de carga internos.
Fluxos de VM para VM através de um balanceador de carga de rede de passagem interno
Quando adiciona uma VM ao serviço de back-end para um balanceador de carga de rede de encaminhamento interno, Google Cloud adiciona o endereço IP do balanceador de carga à tabela de encaminhamento local da VM. Isto permite que a VM aceite pacotes de pedidos com destinos definidos para o endereço IP do equilibrador de carga. Quando a VM responde, envia a respetiva resposta diretamente. No entanto, o endereço IP de origem dos pacotes de resposta é definido como o endereço IP do balanceador de carga e não o da VM que está a ser balanceada.
Os fluxos de VM para VM enviados através de um balanceador de carga de passagem interno são comunicados a partir da origem e do destino.
| Conforme comunicado pela VM do cliente (192.168.1.2) | ||||
|---|---|---|---|---|
| pedido/resposta | connection.src_ip | connection.dest_ip | bytes_sent | Notas |
| pedido | 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.* |
| resposta | 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.* |
| Conforme comunicado pela VM de back-end (10.240.0.3) | ||||
|---|---|---|---|---|
| pedido/resposta | connection.src_ip | connection.dest_ip | bytes_sent | Notas |
| pedido | 192.168.1.2 | 10.240.0.200 | 1224 |
src_instance.* src_vpc.* dest_instance.* dest_vpc.* load_balancing.* (todos os campos, exceto url_map_name) |
| resposta | 10.240.0.200 | 192.168.1.2 | 5342 |
src_instance.* src_vpc.* dest_instance.* dest_vpc.* load_balancing.* (todos os campos, exceto url_map_name) |
No pedido que o balanceador de carga distribui para a VM de back-end, o endereço IP de origem é definido como o endereço IP da VM do cliente. Isto significa que a VM de back-end pode fornecer informações src_instance e dest_instance sobre a VM do cliente. No entanto, ao contrário da VM de back-end, a VM do cliente não pode adicionar informações src_instancee dest_instanceacerca da VM de back-end ao respetivo relatório, porque envia o pedido para o endereço IP do balanceador de carga e recebe a resposta deste, e não da VM de back-end.
A VM flui através de um balanceador de carga de rede de proxy interno ou de um balanceador de carga de aplicações interno
O tráfego que flui através de um Network Load Balancer de proxy interno
ou de um Application Load Balancer interno é comunicado pelas VMs do cliente, desde que a VM do cliente esteja numa sub-rede com os
VPC Flow Logs ativados. Por exemplo, uma VM cliente com o endereço IP 10.10.0.2 envia um pedido com 1224 bytes para o ponto final do balanceador de carga 10.10.0.3. Em seguida, o pedido chega a um back-end. Por sua vez,
o back-end responde ao pedido com uma resposta que contém 5342 bytes.
O pedido e a resposta são registados na VM do cliente. Os registos da VM do cliente estão disponíveis no Google Cloud projeto ao qual a VM pertence.
| Conforme comunicado pela VM do cliente (10.10.0.2) | ||||
|---|---|---|---|---|
| pedido/resposta | connection.src_ip | connection.dest_ip | bytes_sent | Notas |
| pedido | 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 (para o balanceador de carga de aplicações) load_balancing.forwarding_rule_name load_balancing.vpc.* |
| resposta | 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 (para o balanceador de carga de aplicações) load_balancing.forwarding_rule_name load_balancing.vpc.* |
Fluxos do GKE
As secções seguintes fornecem exemplos de como os registos de fluxo de VPC anotam o tráfego do GKE de e para pods.
Fluxo de pod para ClusterIP
Neste exemplo, o tráfego é enviado do pod do cliente (10.4.0.2) para cluster-service
(10.0.32.2:80). O destino é resolvido para o endereço IP do pod do servidor selecionado (10.4.0.3) na porta de destino (8080).
Nas extremidades dos nós, o fluxo é amostrado duas vezes com o endereço IP e a porta traduzidos. Para ambos os pontos de amostragem, vamos identificar que o pod de destino está a executar o serviço cluster-service na porta 8080 e anotar o registo com os detalhes do serviço, bem como os detalhes do pod. Caso o tráfego seja encaminhado para um Pod no mesmo nó, o tráfego não sai do nó e não é amostrado.
Neste exemplo, são encontrados os seguintes registos.
| origem | connection.src_ip | connection.dst_ip | bytes_sent | Notas |
|---|---|---|---|---|
| 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.* |
Fluxos do LoadBalancer externo do GKE
O tráfego de um endereço IP externo para um serviço GKE (35.35.35.35) é encaminhado para um nó no cluster, 10.0.12.2 neste exemplo, para encaminhamento. Por predefinição, os balanceadores de carga de rede de encaminhamento externo distribuem o tráfego por todos os nós no cluster, mesmo os que não estão a executar um pod relevante. O tráfego pode ter de fazer mais saltos para chegar ao pod relevante. Para mais informações, consulte o artigo
Trabalhar em rede fora do
cluster.
O tráfego é, em seguida, encaminhado do nó (10.0.12.2) para o pod do servidor selecionado (10.4.0.2). Ambos os saltos são registados porque todas as extremidades dos nós são amostradas. No caso de o tráfego ser encaminhado para um pod no mesmo nó, 10.4.0.3 neste exemplo, o segundo salto não seria registado porque não sai do nó.
O segundo salto é registado pelos pontos de amostragem de ambos os nós. Para o primeiro salto, identificamos o serviço com base no IP do balanceador de carga e na porta do serviço (80). Para o segundo salto, identificamos que o pod de destino está a suportar o serviço na porta de destino (8080).
Neste exemplo, são encontrados os seguintes registos.
| origem | connection.src_ip | connection.dst_ip | bytes_sent | Notas |
|---|---|---|---|---|
| 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.* |
Fluxos de entrada do GKE
Uma ligação de um endereço IP externo a um destino de entrada é terminada no serviço Cloud Load Balancing. A ligação é mapeada para um serviço NodePort de acordo com o URL. Para processar o pedido, o equilibrador de carga (130.211.0.1) liga-se a um dos nós do cluster (10.0.12.2) para encaminhamento através da NodePort do serviço. Por predefinição, quando cria um objeto Ingress, o controlador Ingress do GKE configura um balanceador de carga HTTP(S) que distribui o tráfego por todos os nós no cluster, mesmo os que não estão a executar um pod relevante. O tráfego pode demorar mais tempo a chegar ao pod relevante. Para mais informações, consulte o artigo
Redes fora do cluster.
Em seguida, o tráfego é encaminhado do nó (10.0.12.2) para o pod do servidor selecionado (10.4.0.2).
Ambos os saltos são registados porque todas as arestas dos nós são amostradas. Para o primeiro salto, identificamos o serviço com base no NodePort do serviço (60000). Para o segundo salto, identificamos que o pod de destino está a suportar o serviço na porta de destino (8080). O segundo salto é registado pelos pontos de amostragem de ambos os nós.
No entanto, num caso em que o tráfego é encaminhado para um pod no mesmo nó (10.4.0.3), o segundo salto não é registado porque o tráfego não saiu do nó.
Neste exemplo, são encontrados os seguintes registos.
| origem | connection.src_ip | connection.dst_ip | bytes_sent | Notas |
|---|---|---|---|---|
| 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.* |
Fluxos de entrada do GKE que usam o balanceamento de carga nativa do contentor
Os pedidos de um endereço IP externo para um destino de entrada que esteja a usar o
balanceamento de carga nativo do contentor
são terminados no balanceador de carga. Neste tipo de entrada, os pods são
objetos essenciais para o balanceamento de carga.
Em seguida, é enviado um pedido do balanceador de carga (130.211.0.1) diretamente para um pod selecionado (10.4.0.2). Identificamos que o pod de destino está a suportar o serviço na porta de destino (8080).
Neste exemplo, é encontrado o seguinte registo.
| origem | connection.src_ip | connection.dst_ip | bytes_sent | Notas |
|---|---|---|---|---|
| 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.* |
Agrupamento para fluxos externos
O tráfego de um agrupamento (10.4.0.3) para um IP externo (203.0.113.1) é modificado pela
ocultação de IP para que os pacotes sejam enviados a partir do IP do nó (10.0.12.2)
em vez do endereço IP do agrupamento. Por predefinição, o cluster do GKE está configurado para ocultar o tráfego para destinos externos. Para mais informações, consulte o artigo
Agente de mascaramento de IP.
Para ver as anotações de pods para este tráfego, pode configurar o agente de ocultação para não ocultar os endereços IP dos pods. Nesse caso, para permitir o tráfego para a Internet, pode configurar o Cloud NAT, que processa os endereços IP dos pods. Para mais informações sobre o Cloud NAT com o GKE, reveja a interação do GKE.
Neste exemplo, é encontrado o seguinte registo.
| origem | connection.src_ip | connection.dst_ip | bytes_sent | Notas |
|---|---|---|---|---|
| SRC | 10.0.12.2 | 203.0.113.1 | 1224 |
src_instance.* src_vpc.* src_gke_details.cluster.* dest_location.* internet_routing_details.* |
Fluxos de conetividade híbrida
Para a conetividade híbrida através de anexos de VLAN para túneis do Cloud Interconnect e Cloud VPN, os registos de fluxo de VPC anotam os seguintes fluxos:
- Fluxos entre instâncias de VM, incluindo instâncias usadas como nós do GKE, e pontos finais nas instalações
- Fluxos entre os serviços Google e os pontos finais no local
- Trânsito de fluxos entre pontos finais no local
O exemplo seguinte descreve como os registos de fluxo da VPC anotam os fluxos entre uma instância de VM numa rede VPC e um ponto final no local. A rede está ligada ao ponto final através de uma associação de VLAN para o Cloud Interconnect.
Para fluxos entre uma VM numa rede VPC e um ponto final no local com um endereço IP interno, os registos de fluxo são comunicados apenas a partir deGoogle Cloud . Os seguintes recursos comunicam registos de fluxo:
- A VM. Os relatórios registam fluxos se a sub-rede à qual a VM está ligada tiver os registos de fluxos da VPC ativados.
- O gateway que liga a rede VPC ao ponto final no local. Comunica registos de fluxo se o gateway (neste exemplo, a associação VLAN) tiver os registos de fluxo da VPC ativados.
No diagrama anterior, o ponto final no local 10.30.0.2 envia um pedido
com 1224 bytes para a VM 10.0.0.2 na rede VPC.
Por sua vez, a VM 10.0.0.2 responde ao pedido
com uma resposta que contém 5243 bytes. O pedido e a resposta são registados a partir da associação VLAN e da VM.
| Conforme comunicado pela associação VLAN | ||||
|---|---|---|---|---|
| pedido/resposta | connection.src_ip | connection.dest_ip | bytes_sent | Notas |
| pedido | 10.30.0.2 | 10.0.0.2 | 1224 |
src_gateway.* dest_instance.* dest_vpc.* |
| resposta | 10.0.0.2 | 10.30.0.2 | 5342 |
src_instance.* src_vpc.* dest_gateway.* |
| Conforme comunicado pela VM (10.0.0.2) | ||||
|---|---|---|---|---|
| pedido/resposta | connection.src_ip | connection.dest_ip | bytes_sent | Notas |
| pedido | 10.30.0.2 | 10.0.0.2 | 1224 |
src_gateway.* dest_instance.* dest_vpc.* |
| resposta | 10.0.0.2 | 10.30.0.2 | 5342 |
src_instance.* src_vpc.* dest_gateway.* |
Fluxos entre redes VPC em projetos diferentes
Se os registos de fluxo de VPC estiverem configurados para uma organização e as anotações entre projetos estiverem ativadas (predefinição), os fluxos de tráfego entre redes VPC em projetos diferentes são anotados da mesma forma que os fluxos de tráfego entre redes VPC no mesmo projeto. Os registos destes fluxos fornecem informações sobre ambos os lados da ligação.
Se as anotações entre projetos estiverem desativadas, os registos de registo fornecem informações apenas sobre o autor do fluxo de tráfego.
Anotações entre projetos ativadas
O exemplo seguinte descreve como os registos de fluxo de VPC anotam os registos de registo para fluxos de VM para VM entre projetos quando as anotações entre projetos estão ativadas. As anotações entre projetos estão disponíveis para fluxos de tráfego através da VPC partilhada, do intercâmbio das redes da VPC e do Centro de conectividade de rede.
A VM 10.0.0.2 envia um pedido com 1224 bytes para a VM 10.0.0.1.2. Por sua vez, VM 10.0.0.1.2 responde ao pedido com uma resposta que contém 5342 bytes. O pedido e a resposta são registados nas VMs que enviam e recebem o pedido.
| Conforme comunicado pela VM que está a fazer o pedido (10.0.0.2) | ||||
|---|---|---|---|---|
| pedido/resposta | connection.src_ip | connection.dest_ip | bytes_sent | Notas |
| pedido | 10.0.0.2 | 10.0.1.2 | 1224 |
src_instance.* src_vpc.* dest_instance.* dest_vpc.* |
| resposta | 10.0.1.2 | 10.0.0.2 | 5342 |
src_instance.* src_vpc.* dest_instance.* dest_vpc.* |
| Conforme comunicado pela VM de resposta (10.0.1.2) | ||||
|---|---|---|---|---|
| pedido/resposta | connection.src_ip | connection.dest_ip | bytes_sent | Notas |
| pedido | 10.0.0.2 | 10.0.1.2 | 1224 |
src_instance.* src_vpc.* dest_instance.* dest_vpc.* |
| resposta | 10.0.1.2 | 10.0.0.2 | 5342 |
src_instance.* src_vpc.* dest_instance.* dest_vpc.* |
Anotações entre projetos desativadas
O exemplo seguinte descreve como os registos de fluxo de VPC anotam os registos de registo para fluxos de VM para VM entre projetos quando as anotações entre projetos estão desativadas.
A VM 10.0.0.2 envia um pedido com 1224 bytes para a VM 10.0.0.1.2. Por sua vez, VM 10.0.0.1.2 responde ao pedido com uma resposta que contém 5342 bytes. O pedido e a resposta são registados nas VMs que enviam e recebem o pedido. No entanto, não são fornecidas informações sobre a outra VM.
| Conforme comunicado pela VM que está a fazer o pedido (10.0.0.2) | ||||
|---|---|---|---|---|
| pedido/resposta | connection.src_ip | connection.dest_ip | bytes_sent | Notas |
| pedido | 10.0.0.2 | 10.0.1.2 | 1224 |
src_instance.* src_vpc.* |
| resposta | 10.0.1.2 | 10.0.0.2 | 5342 |
dest_instance.* dest_vpc.* |
| Conforme comunicado pela VM de resposta (10.0.1.2) | ||||
|---|---|---|---|---|
| pedido/resposta | connection.src_ip | connection.dest_ip | bytes_sent | Notas |
| pedido | 10.0.0.2 | 10.0.1.2 | 1224 |
dest_instance.* dest_vpc.* |
| resposta | 10.0.1.2 | 10.0.0.2 | 5342 |
src_instance.* src_vpc.* |