Sobre os fluxos de tráfego

Nesta página, descrevemos como os registros de fluxo de VPC informam os registros de fluxo para casos de uso comum. Consulte as seções a seguir para ver exemplos de fluxos de tráfego de amostra pelos registros de fluxo de VPC.

Fluxos de VM

As seções a seguir incluem exemplos de como os registros de fluxo de VPC faz uma amostragem do tráfego enviado e recebido por instâncias de máquina virtual (VM). Para informações sobre como os registros de fluxo de VPC relatam os registros de fluxo pods do Google Kubernetes Engine, consulte Fluxos do GKE.

Fluxos de VM para VM na mesma rede VPC

Para os fluxos de VM para VM na mesma rede VPC, os registros de fluxo são informados tanto pela VM solicitante quanto pela que VM que responde, desde que ambas estejam em sub-redes com os registros de fluxo de VPC ativados. Neste exemplo, a VM 10.10.0.2 envia uma solicitação com 1.224 bytes para a VM 10.50.0.2, que também está em uma sub-rede com o registro ativado. Por sua vez, 10.50.0.2 responde ao pedido com uma réplica com 5.342 bytes. Tanto a solicitação quanto a resposta são registradas nas duas VMs, a que solicitou e a que respondeu.

Conforme informado pela VM solicitante (10.10.0.2)
solicitação/resposta	connection.src_ip	connection.dest_ip	bytes_sent	Anotações
solicitação	10.10.0.2	10.50.0.2	1.224	src_instance.* dest_instance.* src_vpc.* dest_vpc.*
resposta	10.50.0.2	10.10.0.2	5.342	src_instance.* dest_instance.* src_vpc.* dest_vpc.*

Conforme informado pela VM respondente (10.50.0.2)
solicitação/resposta	connection.src_ip	connection.dest_ip	bytes	Anotações
solicitação	10.10.0.2	10.50.0.2	1.224	src_instance.* dest_instance.* src_vpc.* dest_vpc.*
resposta	10.50.0.2	10.10.0.2	5.342	src_instance.* dest_instance.* src_vpc.* dest_vpc.*

Fluxos de VM para endereço IP externo

Para fluxos que atravessam a Internet entre uma VM que está em uma rede VPC e um endpoint com um endereço IP externo, os registros de fluxo são informados da VM que está apenas na rede VPC:

• Para fluxos de saída, os registros são informados pela VM da rede VPC que é a origem do tráfego.
• Para fluxos de entrada, os registros são informados pela VM da rede VPC que é o destino do tráfego.

Neste exemplo, a VM 10.10.0.2 troca pacotes pela Internet com um endpoint que tem o endereço IP externo 203.0.113.5. O tráfego de saída de 1.224 bytes enviados de 10.10.0.2 para 203.0.113.5 é relatado a partir da VM de origem, 10.10.0.2. O tráfego de entrada de 5.342 bytes enviados de 203.0.113.5 para 10.10.0.2 é informado a partir do destino do tráfego, a VM 10.10.0.2.

solicitação/resposta	connection.src_ip	connection.dest_ip	bytes_sent	Anotações
solicitação	10.10.0.2	203.0.113.5	1.224	src_instance.* src_vpc.* dest_location.* internet_routing_details.*
resposta	203.0.113.5	10.10.0.2	5.342	dest_instance.* dest_vpc.* src_location.*

Fluxos de VM para local

Para fluxos entre uma VM que está em uma rede VPC e um endpoint local com um endereço IP interno, os registros de fluxo são informados a partir da VM que está apenas na rede VPC:

• Para fluxos de saída, os registros são informados pela VM da rede VPC que é a origem do tráfego.
• Para fluxos de entrada, os registros são informados pela VM da rede VPC que é o destino do tráfego.

Neste exemplo, a VM 10.10.0.2 e o endpoint no local 10.30.0.2 estão conectados por meio de um gateway de VPN ou do Cloud Interconnect. O tráfego de saída de 1.224 bytes enviados de 10.10.0.2 para 10.30.0.2 é relatado a partir da VM de origem, 10.10.0.2. O tráfego de entrada de 5.342 bytes enviados de 10.30.0.2 para 10.10.0.2 é informado a partir do destino do tráfego, a VM 10.10.0.2.

solicitação/resposta	connection.src_ip	connection.dest_ip	bytes_sent	Anotações
solicitação	10.10.0.2	10.30.0.2	1.224	dest_gateway.* src_instance.* src_vpc.*
resposta	10.30.0.2	10.10.0.2	5.342	dest_instance.* dest_vpc.* src_gateway.*

Fluxos de VM para VM na VPC compartilhada

Para os fluxos de VM para VM em uma VPC compartilhada, é possível ativar os registros de fluxo de VPC para a sub-rede no projeto host. Por exemplo, a sub-rede 10.10.0.0/20 pertence a uma rede VPC compartilhada definida em um projeto host. É possível visualizar os registros de fluxo das VMs pertencentes a essa sub-rede, incluindo aqueles criados por projetos de serviço. Neste exemplo, os projetos de serviço são chamados de "web server", "recommendation" e "database".

Para fluxos de VM para VM, se as duas VMs estiverem no mesmo projeto ou, no caso de uma rede compartilhada, no mesmo projeto host, as anotações para ID do projeto e similares serão fornecidas para o outro endpoint na conexão. Se a outra VM estiver em um projeto diferente, as anotações para a outra VM não serão fornecidas.

A tabela a seguir mostra um fluxo informado por 10.10.0.10 ou 10.10.0.20.

• src_vpc.project_id e dest_vpc.project_id são para o projeto host porque a sub-rede VPC pertence ao projeto host.
• src_instance.project_id e dest_instance.project_id são para os projetos de serviço porque 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 da Web	host_project	10.10.0.20	recommendation	host_project

Os projetos de serviço não são proprietários da rede VPC compartilhada e não têm aos registros de fluxo da rede VPC compartilhada.

Fluxos VM para VM para peering de VPC

A menos que ambas as VMs estejam no mesmo projeto do Google Cloud, os fluxos de VM para VM em redes VPC com peering são informados da mesma maneira que para os endpoints externos. As informações do projeto e de outras anotações da 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 serã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 conectadas por meio do peering de rede VPC. Se os registros de fluxo do VPC estiverem ativados no projeto analytics-prod, o tráfego (1.224 bytes) enviado de 10.10.0.2 para 10.50.0.2 será informado da VM 10.10.0.2, que é a origem do fluxo. O tráfego (5.342 bytes) enviado de 10.50.0.2 para 10.10.0.2 também é informado a partir da VM 10.10.0.2, que é o destino do fluxo.

Neste exemplo, os registros de fluxo de VPC não estão ativados no projeto webserver-test, portanto nenhum registro é gravado pela VM 10.50.0.2.

reporter	connection.src_ip	connection.dest_ip	bytes_sent	Anotações
source	10.10.0.2	10.50.0.2	1.224	src_instance.* src_vpc.*
destination	10.50.0.2	10.10.0.2	5.342	dest_instance.* dest_vpc.*

Fluxos de VM com o Cloud Load Balancing

Para fluxos pelo Cloud Load Balancing, Os registros de fluxo de VPC anotam o tráfego enviado por um Balanceador de carga de rede de passagem, balanceador de carga de rede de proxy ou um balanceador de carga de aplicativo. Os exemplos a seguir pressupõem que esses balanceadores de carga estão configurados como balanceadores de carga internos.

Fluxos de VM para VM por meio de um balanceador de carga de rede de passagem interna

Ao adicionar uma VM ao serviço de back-end de um balanceador de carga de rede de passagem interno, o Google Cloud adiciona o endereço IP do balanceador de carga à tabela de roteamento local da VM. Isso permite que a VM aceite pacotes de solicitação com destinos definidos para o endereço IP do balanceador de carga. Quando a VM responde, a resposta é enviada diretamente. No entanto, o endereço IP de origem dos pacotes de resposta será definido pelo endereço IP do balanceador de carga, não pela VM com balanceamento de carga.

Os fluxos de VM para VM enviados por meio de um balanceador de carga de rede de passagem interna são informados a partir da origem e do destino.

Conforme relatado pela VM do cliente (192.168.1.2)
solicitação/resposta	connection.src_ip	connection.dest_ip	bytes_sent	Anotações
solicitação	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.*
resposta	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.*

Conforme informado pela VM de back-end (10.240.0.3)
solicitação/resposta	connection.src_ip	connection.dest_ip	bytes	Anotações
solicitação	192.168.1.2	10.240.0.200	1.224	src_instance.* dest_instance.* src_vpc.* dest_vpc.* load_balancing.* (todos os campos, exceto url_map_name)
resposta	10.240.0.200	192.168.1.2	5.342	src_instance.* dest_instance.* src_vpc.* dest_vpc.* load_balancing.* (todos os campos, exceto url_map_name)

Como a VM de back-end conhece o endereço IP da VM cliente, ela pode fornecer informações src_instance e dest_instance sobre a VM cliente. Ao contrário do VM de back-end, a VM de cliente não saberá o endereço IP da VM de back-end e portanto, não é possível adicionar informações src_instance e dest_instance sobre o VM de back-end ao relatório.

Fluxos VM-to-internal-proxy-Network-Load-Balancer e VM-to-internal-Application-Load-Balancer

Os fluxos de tráfego que passam por um balanceador de carga de rede de proxy interno ou um balanceador de carga de aplicativo interno são informados por para as VMs do cliente, contanto que elas estejam em uma sub-rede com com os registros de fluxo de VPC ativados. Por exemplo, uma VM cliente com o endereço IP 10.10.0.2 envia uma solicitação com 1.224 bytes para o balanceador de carga endpoint: 10.10.0.3. Em seguida, a solicitação chega a um back-end. Por sua vez, o back-end responde à solicitação com uma resposta de 5.342 bytes. A solicitação e a resposta são registradas na VM do cliente. Os registros da VM cliente vão estar disponíveis no projeto do Google Cloud ao qual a VM pertence.

Conforme informado pela VM cliente (10.10.0.2)
solicitação/resposta	connection.src_ip	connection.dest_ip	bytes_sent	Anotações
solicitação	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 (for Application Load Balancer) load_balancing.forwarding_rule_name load_balancing.vpc.*
resposta	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 (for Application Load Balancer) load_balancing.forwarding_rule_name load_balancing.vpc.*

Fluxos de VM para VM por meio do Private Service Connect

Para o tráfego de VM para VM usando o Private Service Connect, Os registros de fluxo de VPC fornecem amostras de fluxos entre Os consumidores do Private Service Connect e serviços publicados.

Endpoint do Private Service Connect para um serviço publicado

Os fluxos de tráfego para serviços publicados do Private Service Connect são informados pelas VMs do produtor e do consumidor, desde que ambas estejam em sub-redes com registros de fluxo de VPC ativados. Neste exemplo, a VM do consumidor, 10.10.0.2, envia uma solicitação com 1.224 bytes para o endpoint do Private Service Connect, 10.10.0.3. No produtor VPC, o endereço IP de origem da solicitação é convertida em um endereço IP na sub-rede do anexo de serviço, que, exemplo, é 10.40.0.2. O endereço IP de destino da solicitação é convertido para o endereço IP do balanceador de carga de rede de passagem interna, 10.50.0.3. Em seguida, a solicitação chega à VM de back-end, 10.50.0.2, que também está em uma sub-rede com o registro ativado. Por sua vez, 10.50.0.2 responde ao pedido com uma réplica com 5.342 bytes. Tanto a solicitação quanto a resposta são registradas nas duas VMs, a que solicitou e a que respondeu. Os registros da VM do consumidor estarão disponíveis no no projeto do consumidor, e os registros da VM do produtor estarão disponíveis no no projeto de produtor.

Conforme informado pela VM consumidor (10.10.0.2)
solicitação/resposta	connection.src_ip	connection.dest_ip	bytes_sent	Anotações
solicitação	10.10.0.2	10.10.0.3	1.224	src_instance.* src_vpc.* psc.reporter psc.psc_endpoint.* psc.psc_attachment.*
resposta	10.10.0.3	10.10.0.2	5.342	dest_instance.* dest_vpc.* psc.reporter psc.psc_endpoint.* psc.psc_attachment.*

Conforme informado pela VM produtor (10.50.0.2)
solicitação/resposta	connection.src_ip	connection.dest_ip	bytes_sent	Anotações
solicitação	10.40.0.2	10.50.0.3	1.224	dest_instance.* dest_vpc.* psc.reporter psc.psc_attachment.*
resposta	10.50.0.3	10.40.0.2	5.342	src_instance.* src_vpc.* psc.reporter psc.psc_attachment.*

Fluxos de VM para a API Google

Para o tráfego de VM para APIs do Google pelo IP externo da VM Acesso privado do Google ou Private Service Connect endpoint, os registros de fluxo de VPC fazem anotações nos registros com as APIs do Google informações imprecisas ou inadequadas. A seção a seguir mostra um exemplo de como os registros de fluxo VPC anotam registros de log de uma VM que acessa uma API global do Google por um endpoint do Private Service Connect.

VM para uma API global do Google pelo Private Service Connect

Os fluxos de tráfego para uma API do Google são informados por VMs do consumidor, desde que a VM esteja em uma sub-rede com os registros de fluxo de VPC ativados. Neste exemplo, a VM do consumidor, 10.10.0.2, envia uma solicitação com 1.224 bytes para o endpoint do Private Service Connect, 10.10.110.10. A solicitação é encaminhados para a API apropriada do Google, por exemplo, o Cloud Storage. Por sua vez, O Cloud Storage responde à solicitação com uma resposta com 5.342 bytes. A solicitação e a resposta são registradas na VM solicitante.

Conforme informado pela VM consumidor (10.10.0.2)
solicitação/resposta	connection.src_ip	connection.dest_ip	bytes_sent	Anotações
solicitação	10.10.0.2	10.10.110.10	1.224	src_instance.* src_vpc.* psc.reporter psc.psc_endpoint.* dest_google_service.*
resposta	10.10.110.10	10.10.0.2	5.342	src_google_service.* dest_instance.* dest_vpc.* psc.reporter psc.psc_endpoint.*

Fluxos do GKE

As seções a seguir incluem exemplos de como os registros de fluxo de VPC faz a amostragem do tráfego do GKE de e para pods.

Pod para o fluxo do ClusterIP

Neste exemplo, o tráfego é enviado do pod 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 bordas do nó, o fluxo é amostrado duas vezes com o endereço IP e a porta traduzidos. Para ambos os pontos de amostragem, identificaremos que o pod de destino está fazendo o serviço cluster-service na porta 8080 e anotaremos o registro com os detalhes do serviço e os detalhes do pod. Caso o tráfego seja roteado para um pod no mesmo nó, ele não sairá do nó e não será amostrado.

Neste exemplo, são encontrados os seguintes registros.

reporter	connection.src_ip	connection.dst_ip	bytes_sent	Anotações
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.*

Fluxos externos do LoadBalancer do GKE

O tráfego de um endereço IP externo para um serviço do GKE (35.35.35.35) será roteado para um nó no cluster, 10.0.12.2 neste exemplo, para roteamento. Por padrão, os balanceadores de carga de rede de passagem externa distribuem o tráfego entre todos os nós no cluster, mesmo aqueles que não executam um pod relevante. O tráfego pode fazer saltos extras para chegar ao pod relevante. Para mais informações, consulte Rede fora do cluster.

O tráfego será roteado do nó (10.0.12.2) para o pod do servidor selecionado (10.4.0.2). Os dois saltos serão registrados porque todas as bordas do nó são amostradas. Caso o tráfego seja roteado para um pod no mesmo nó, 10.4.0.3 neste exemplo, o segundo salto não será registrado, já que não sai do nó. O segundo salto será registrado pelos pontos de amostragem dos dois nós. No primeiro salto, identificamos o serviço com base no IP do balanceador de carga e na porta de serviço (80). Para o segundo salto, identificamos que o pod de destino está apoiando o serviço na porta de destino (8080).

Neste exemplo, são encontrados os seguintes registros.

reporter	connection.src_ip	connection.dst_ip	bytes_sent	Anotações
DEST	203.0.113.1	35.35.35.35	1.224	src_location.* dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.service.*
SRC	10.0.12.2	10.4.0.2	1.224	src_instance.* src_vpc.* src_gke_details.cluster.* dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.pod.* dest_gke_details.service.*
DEST	10.0.12.2	10.4.0.2	1.224	src_instance.* src_vpc.* src_gke_details.cluster.* dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.pod.* dest_gke_details.service.*

Fluxos de entrada do GKE

Uma conexão de um endereço IP externo com um destino de entrada é encerrada no serviço do Cloud Load Balancing. A conexão será mapeada para um serviço NodePort de acordo com o URL. Para atender à solicitação, o balanceador de carga (130.211.0.1) se conecta a um dos nós do cluster (10.0.12.2) para roteamento usando o NodePort do serviço. Por padrão, ao criar uma Entrada, o controlador de Entrada do GKE configura um balanceador de carga HTTP(S) que distribui o tráfego por todos os nós do cluster, mesmo aqueles que não estiverem executando um pod relevante. O tráfego pode fazer saltos extras para chegar ao pod relevante. Para mais informações, consulte Rede fora do cluster. O tráfego será então roteado do nó (10.0.12.2) para o pod de servidor selecionado (10.4.0.2).

Os dois saltos serão registrados porque todas as bordas do nó serão amostradas. No 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á fazendo o serviço na porta de destino (8080). O segundo salto será registrado pelos pontos de amostragem dos dois nós. No entanto, em um caso em que o tráfego seja roteado para um pod no mesmo nó (10.4.0.3), o segundo salto não será registrado porque o tráfego não terá saído do nó.

Neste exemplo, são encontrados os seguintes registros.

reporter	connection.src_ip	connection.dst_ip	bytes_sent	Anotações
DEST	130.211.0.1	10.0.12.2	1.224	dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.service.*
SRC	10.0.12.2	10.4.0.2	1.224	src_instance.* src_vpc.* src_gke_details.cluster.* dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.pod.* dest_gke_details.service.*
DEST	10.0.12.2	10.4.0.2	1.224	src_instance.* src_vpc.* src_gke_details.cluster.* dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.pod.* dest_gke_details.service.*

Fluxos de entrada do GKE que usam o balanceamento de carga nativo de contêiner

As solicitações de um endereço IP externo para uma entrada que usa balanceamento de carga nativo de contêiner são encerradas no balanceador de carga. Nesse tipo de entrada, os pods são objetos principais para balanceamento de carga. Uma solicitação será enviada do balanceador de carga (130.211.0.1) diretamente para um pod selecionado (10.4.0.2). Identificamos que o pod de destino está fazendo o backup do serviço na porta de destino (8080).

Neste exemplo, será encontrado o seguinte registro.

reporter	connection.src_ip	connection.dst_ip	bytes_sent	Anotações
DEST	130.211.0.1	10.4.0.2	1.224	dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.pod.* dest_gke_details.service.*

Pod para fluxos externos

O tráfego de um pod (10.4.0.3) para um IP externo (203.0.113.1) é modificado pelo mascaramento de IP de modo que os pacotes são enviados do IP do nó (10.0.12.2) em vez de do IP do pod. Por padrão, o cluster do GKE é configurado para mascarar o tráfego para destinos externos. Para mais informações, consulte Agente de mascaramento de IP.

Para visualizar as anotações de pod para esse tráfego, configure o agente de mascaramento para que não mascare IPs de pod. Nesse caso, para permitir o tráfego para a Internet, configure o Cloud NAT, que processa os endereços IP do pod. Para mais informações sobre o Cloud NAT com o GKE, consulte a Interação do GKE.

Neste exemplo, será encontrado o seguinte registro.

reporter	connection.src_ip	connection.dst_ip	bytes_sent	Anotações
SRC	10.0.12.2	203.0.113.1	1.224	src_instance.* src_vpc.* src_gke_details.cluster.* dest_location.* internet_routing_details.*

A seguir

• Configurar os registros de fluxo de VPC
• Registros de fluxo de acesso