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 para pods do Google Kubernetes Engine (GKE), consulte Fluxos do GKE.

Fluxos de VM para VM na mesma rede VPC

Fluxos de VM em uma rede VPC (clique para ampliar).

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

Fluxos de VM para endereços IP externos (clique para ampliar).

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 VM na VPC compartilhada

Fluxos de VPC compartilhada (clique para ampliar).

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	recomendação	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

Fluxos de peering de rede VPC (clique para ampliar).

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 de 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á relatada pela 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 é relatado pela 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
fonte	10.10.0.2	10.50.0.2	1.224	src_instance.* src_vpc.*
destino	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

Fluxos do balanceador de carga de rede de passagem interna (clique para ampliar).

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)

Na solicitação 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 de cliente. Ou seja, a VM de back-end pode fornecer informações de src_instance e dest_instance sobre a VM de cliente. No entanto, ao contrário da VM de back-end, a VM de cliente não pode adicionar informações de src_instance e dest_instance sobre a VM de back-end ao relatório porque ela envia a solicitação ao endereço IP do balanceador de carga e recebe a resposta dele, não a VM de back-end.

Fluxos de VM para balanceador de carga de rede de proxy interno e de VM para balanceador de carga de aplicativo

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 de cliente estão 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

A VM flui pelo Private Service Connect (clique para ampliar).

Os fluxos de tráfego para serviços publicados do Private Service Connect são relatados pelas VMs consumidoras e produtoras, desde que ambas estejam em sub-redes 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.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 consumidora estão disponíveis no projeto consumidor, e os registros da VM produtora estão disponíveis no projeto 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 API do 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

Fluxos de VM para APIs do Google pelo Private Service Connect (clique para ampliar).

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 é encaminhada para o serviço do Google apropriado, 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

Fluxo do pod para o IP do cluster (clique para ampliar).

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

Fluxos do balanceador de carga externo (clique para ampliar).

O tráfego de um endereço IP externo para um serviço do GKE (35.35.35.35) é 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

Fluxos de entrada (clique para ampliar)

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 um objeto Ingress, o controlador de Ingress 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 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á 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

Fluxos de entrada que usam balanceamento de carga nativo de contêiner (clique para ampliar).

As solicitações de um endereço IP externo para um destino de Ingress 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

Fluxo de pod para externo (clique para ampliar).

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) no lugar do endereço 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 ver as anotações de pod para esse tráfego, configure o agente de mascaramento para que não mascare endereços IP de pods. 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.*

Fluxos de conectividade híbrida

Para o tráfego entre o Google Cloud e as redes locais, os Registros de fluxo de VPC anotam os fluxos entre instâncias de VM, incluindo instâncias usadas como nós do GKE, e endpoints locais, entre APIs do Google e endpoints locais e o tráfego de trânsito entre endpoints locais. O exemplo a seguir descreve como os Registros de fluxo de VPC anotam fluxos entre instâncias de VM em uma rede VPC e um endpoint local.

Fluxos de VM para local (clique para ampliar).

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 relatados apenas pelo Google Cloud. Os seguintes recursos relatam registros de fluxo:

• A VM. Relata registros de fluxo quando a sub-rede à qual a VM está conectada tem os Registros de fluxo de VPC ativados.
• O gateway que conecta a rede VPC ao endpoint local. Relata os registros de fluxo quando o gateway tem os Registros de fluxo de VPC ativados.

No diagrama anterior, o endpoint local 10.30.0.2 envia uma solicitação com 1.224 bytes para a VM 10.0.0.2 na rede VPC pelo Cloud Interconnect. Por sua vez, a VM 10.0.0.2 responde à solicitação com uma resposta contendo 5.243 bytes. A solicitação e a resposta são registradas pelo anexo da VLAN para o Cloud Interconnect e pela VM.

Conforme relatado pelo anexo da VLAN
solicitação/resposta	connection.src_ip	connection.dest_ip	bytes_sent	Anotações
solicitação	10.30.0.2	10.10.0.2	1.224	reporter src_gateway.* dest_instance.* dest_vpc.*
resposta	10.10.0.2	10.30.0.2	5.342	reporter src_instance.* src_vpc.* dest_gateway.*

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

A seguir

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