Registros de fluxo de VPC

Os registros de fluxo de VPC gravam uma amostra de fluxos de rede enviada e recebida por instâncias de VM, incluindo instâncias usadas como nós do Google Kubernetes Engine. Esses registros são usados para monitoramento de rede, perícia forense, análise de segurança em tempo real e otimização de despesas.

É possível ver os registros de fluxo no Cloud Logging e exportá-los para qualquer destino compatível com a exportação do Cloud Logging.

Os registros de fluxo são agregados por conexão das VMs do Compute Engine e exportados em tempo real. Quando você assina o Pub/Sub, é possível analisar os registros de fluxo com APIs de streaming em tempo real.

Propriedades principais

• Os registros de fluxo de VPC fazem parte do Andromeda, o software que aciona redes VPC. Eles não causam atrasos ou penalidades de desempenho quando ativados.
• Os registros de fluxo de VPC funcionam com redes VPC, não com redes legadas. Eles são ativados ou desativados por sub-rede. Se forem ativados em uma sub-rede, os registros de fluxo de VPC coletam dados de todas as instâncias de VM nessa sub-rede.
• Os registros de fluxo de VPC fornecem amostras dos fluxos TCP, UDP, ICMP, ESP e GRE de cada VM. São fornecidas amostras para os fluxos de entrada e os de saída. Esses fluxos podem ser entre a VM e outra VM, um host no seu data center no local, um serviço do Google ou um host na Internet. Se um fluxo for capturado por amostragem, os registros de fluxo de VPC gerarão um registro para o fluxo. Cada registro de fluxo inclui as informações descritas na seção Formato do registro.
• Os registros de fluxo de VPC interagem com as regras de firewall das seguintes maneiras:
  • Os pacotes de saída são amostrados antes das regras de firewall de saída. Mesmo que uma regra de firewall de saída negue pacotes de saída, é possível que esses pacotes sejam amostrados por registros de fluxo de VPC.
  • Os pacotes de entrada são amostrados depois das regras de firewall de entrada. Se uma regra de firewall de entrada negar pacotes de entrada, esses pacotes não serão amostrados por registro de fluxo de VPC.
• É possível usar filtros nos registros de fluxo de VPC para gerar apenas determinados registros.
• Os registros de fluxo de VPC são compatíveis com VMs que têm várias interfaces de rede. É necessário ativar os registros de fluxo de VPC para cada sub-rede, em cada VPC, que contenha uma interface de rede.
• Para registrar fluxos entre pods no mesmo nó do Google Kubernetes Engine (GKE), ative a visibilidade intranós no cluster.

Casos de uso

Monitoramento de rede

Os registros de fluxo de VPC fornecem visibilidade em tempo real da capacidade e do desempenho da rede. Você pode:

• monitorar a rede VPC;
• realizar o diagnóstico de rede;
• filtrar os registros de fluxo por VM e por aplicativo para entender as alterações no tráfego;
• entender o crescimento do tráfego para previsão de capacidade.

Como entender o uso da rede e como otimizar as despesas de tráfego

É possível analisar o uso da rede com os registros de fluxo de VPC. Você pode analisar os fluxos de rede de:

• tráfego entre regiões e zonas;
• tráfego para países específicos na Internet;
• principais talkers.

Com base na análise, você pode otimizar as despesas de tráfego da rede.

Perícia forense da rede

É possível usar os registros de fluxo de VPC para fazer uma análise forense na rede. Por exemplo, se houver um incidente, você pode examinar:

• quais IPs conversaram com quem e quando isso aconteceu;
• todos os IPs comprometidos, pela análise de todos os fluxos de rede de entrada e de saída.

Análise de segurança em tempo real

É possível aproveitar as APIs de streaming em tempo real (usando o Pub/Sub) e integrá-las aos sistemas de gerenciamento de eventos e informações de segurança (SIEM, na sigla em inglês). Isso pode fornecer monitoramento em tempo real, correlação de eventos, análise e alertas de segurança.

Coleta de registros

Os registros de fluxo são coletados para cada conexão de VM em intervalos específicos. Todos os pacotes coletados para um determinado intervalo, em uma determinada conexão, são agregados por um período de tempo (intervalo de agregação), em uma única entrada do registro de fluxo. Esses dados são enviados para o Logging.

Os registros são armazenados no Logging por 30 dias, por padrão. Se você quiser manter os registros por mais tempo, será possível definir um período de retenção personalizado ou exportá-los para um destino compatível.

Amostragem e processamento de registros

O Google Cloud coleta amostras de pacotes de saída e entrada de VM para gerar registros de fluxo. Nem todo pacote é capturado no próprio registro. Cerca de 1 a cada 30 pacotes é capturado, mas essa taxa de amostragem pode ser menor, dependendo da carga da VM. Não é possível ajustar essa taxa.

Depois que os registros de fluxo são gerados, o Google Cloud os processa de acordo com o seguinte procedimento:

1. Filtragem: é possível especificar que apenas os registros que corresponderem a critérios especificados serão gerados. Por exemplo, é possível filtrar para que apenas os registros de uma determinada VM ou apenas os registros com um determinado valor de metadados sejam gerados, enquanto o restante é descartado. Para mais informações, consulte Filtragem de registros.
2. Agregação: as informações dos pacotes da amostragem são agregadas em um intervalo de agregação configurável para produzir uma entrada de registro de fluxo.
3. Amostragem do registro de fluxo: este é um segundo processo de amostragem. As entradas do registro de fluxo são amostradas posteriormente, de acordo com um parâmetro configurável de taxa de amostragem.
4. Metadados: se desativados, todas as anotações de metadados serão descartadas. Se quiser manter os metadados, você poderá especificar que todos os campos ou um conjunto específico de campos sejam mantidos. Para mais informações, consulte Anotações de metadados.
5. Gravar no Logging: as entradas de registro finais são gravadas no Cloud Logging.

Observação: não é possível alterar como os registros de fluxo de VPC coletam amostras. No entanto, é possível controlar a amostragem do registro de fluxo secundário com o parâmetro Amostragem de registros. Mesmo com uma amostra de registro de fluxo de 1.0 ou 100%, cerca de 3% dos pacotes no nível da VM são processados devido à taxa de amostragem inicial. Se precisar analisar todos os pacotes, use Espelhamento de pacotes e instâncias de coletor que executam software de terceiros.

Como os registros de fluxo de VPC não capturam todos os pacotes, eles compensam os pacotes ausentes por meio da interpolação dos pacotes capturados. Isso acontece com os pacotes perdidos devido a configurações de amostragem iniciais e definidas pelo usuário.

Embora o Google Cloud não capture todos os pacotes, as capturas de registros podem ser muito grandes. É possível equilibrar a visibilidade do tráfego e suas necessidades de custo de armazenamento ajustando os seguintes aspectos da coleta de registros:

• Intervalo de agregação: pacotes amostrados em um intervalo de tempo são agregados em uma única entrada de registro. Esse intervalo de tempo pode ser de 5 segundos (padrão), 30 segundos, 1 minuto, 5 minutos, 10 minutos ou 15 minutos.
• Taxa de amostragem: antes de ser gravado no Logging, o número de registros pode ser amostrado para reduzir a quantidade deles. Por padrão, o volume de entrada de registros é escalonado em 0,50 (50%), o que significa que metade das entradas será mantida. É possível definir esse valor de 1.0 (100%, todas as entradas de registro serão mantidas) até 0.0 (0%, nenhum registro será mantido).
• Anotações de metadados: por padrão, as entradas do registro de fluxo são anotadas com informações de metadados, como os nomes das VMs de origem e de destino ou a região geográfica de origens e destinos externos. É possível desativar as anotações de metadados ou especificar apenas algumas anotações para economizar espaço de armazenamento.
• Filtragem: por padrão, os registros são gerados a cada fluxo na sub-rede. É possível definir filtros para que sejam gerados apenas registros que correspondam a determinados critérios.

Anotações de metadados

Os registros contêm campos de base e de metadados. A seção Formato de registro lista quais campos são do tipo metadados e quais são do tipo base. Todos os campos de base são sempre incluídos. É possível personalizar quais campos de metadados manter.

• Se você selecionar todos os metadados, todos os campos de metadados no formato de registros de fluxo de VPC serão incluídos nos registros de fluxo. Quando novos campos de metadados são adicionados ao formato de registro, os registros de fluxo incluem automaticamente os novos campos.

• Se você não selecionar metadados, todos os campos de metadados serão omitidos.

• Se você selecionar metadados personalizados, poderá especificar os campos de metadados que quer incluir pelo campo pai, como src_vpc, ou pelos nomes completos, como src_vpc.project_id.

  Quando novos campos de metadados são adicionados ao formato de registro, os registros de fluxo não incluem esses campos, a menos que sejam um novo campo em um campo pai especificado para ser incluído.

  • Quando você especifica metadados personalizados usando campos pais, quando novos campos de metadados são adicionados ao formato de registro no campo pai, os registros de fluxo incluem automaticamente os novos campos.

  • Se você especificar metadados personalizados com o nome completo do campo, quando novos campos de metadados forem adicionados ao campo pai, os registros de fluxo não incluirão os novos campos.

Para informações sobre como personalizar campos de metadados, consulte as instruções da CLI gcloud ou da API sobre como ativar a geração de registros de fluxo de VPC quando você cria uma sub-rede.

Anotações do GKE

É possível que fluxos que tenham um endpoint em um cluster do GKE sejam anotados com anotações do GKE, que incluem detalhes do cluster, do pod e do serviço do endpoint.

Anotações de serviço do GKE

O tráfego enviado para um ClusterIP, NodePort ou LoadBalancer recebe anotações de serviço. Se for enviado para um NodePort ou LoadBalancer, o fluxo receberá a anotação de serviço nos dois saltos da conexão.

O tráfego enviado diretamente para a porta de serviço de um pod será anotado com uma anotação de serviço no endpoint de destino.

O tráfego enviado para a porta de serviço de um pod em que o pod está fazendo mais de um serviço na mesma porta de serviço será anotado com vários serviços no endpoint de destino. Isso se limita a dois serviços. Se houver mais, o endpoint será anotado com um marcador MANY_SERVICES especial.

Anotações de pod no tráfego da Internet

O tráfego entre um pod e a Internet não recebe anotações de pod por padrão. Em pacotes para a Internet, o agente de mascaramento traduz o endereço IP do pod para o endereço IP do nó antes que os registros de fluxo de VPC vejam o pacote. Assim, os registros de fluxo de VPC não sabem nada sobre o pod e não podem adicionar o anotações de pod.

Devido ao mascaramento, as anotações de pod só serão visíveis se os destinos estiverem dentro dos destinos padrão não mascaradosou em uma lista nonMasqueradeCIDRs personalizada. Se você incluir destinos de Internet em uma lista nonMasqueradeCIDRs personalizada, será necessário fornecer uma maneira para que os endereços IP internos do pod sejam traduzidos antes de serem entregues à Internet. Para clusters particulares e não particulares, é possível usar o Cloud NAT. Consulte Interação do GKE para mais detalhes.

Formato do registro

Os registros contêm campos básicos, que são os campos principais de cada registro, e campos de metadados que acrescentam informações adicionais. É possível omitir os campos de metadados para economizar custos de armazenamento.

Alguns campos de registro aparecem em um formato múltiplo, com mais de um dado em cada campo. Por exemplo, o campo connection é do formato IpConnection, que contém o endereço IP e a porta de origem e destino, mais o protocolo, em um único campo. Esses vários campos estão descritos abaixo da tabela de formatos de registro.

Observação: os valores dos campos de metadados não são baseados no caminho do plano de dados. Eles são aproximações, podendo estar ausentes ou incorretos. Por outro lado, os valores dos campos base são obtidos diretamente dos cabeçalhos dos pacotes.

Campo	Formato do campo	Tipo de campo: base ou metadados opcionais
conexão	IpConnection Cinco tuplas que descrevem a conexão	Camadas
reportado por	string O lado que informou o fluxo. Pode ser SRC ou DEST.	Camadas
rtt_msec	int64 Latência medida durante o intervalo de tempo, apenas para fluxos TCP. A latência medida é o tempo decorrido entre o envio de um SEQ e o recebimento de um ACK correspondente. O resultado da latência é a soma do RTT da rede e de qualquer tempo consumido pelo aplicativo.	Camadas
bytes_sent	int64 Quantidade de bytes enviados da origem para o destino	Camadas
packets_sent	int64 Número de pacotes enviados da origem para o destino	Camadas
start_time	string Carimbo de data/hora (formato de string de data RFC 3339) do primeiro pacote observado durante o intervalo de tempo agregado.	Camadas
end_time	string Carimbo de data/hora (formato de string de data RFC 3339) do último pacote observado durante o intervalo de tempo agregado	Camadas
src_gke_details	GkeDetails Metadados do GKE para endpoints de origem. Disponível apenas se o endpoint for o GKE.	Metadados
dest_gke_details	GkeDetails Metadados do GKE para endpoints de destino. Disponível apenas se o endpoint for o GKE.	Metadados
src_instance	InstanceDetails Se a origem da conexão for uma VM localizada na mesma VPC, esse campo será preenchido com os detalhes da instância da VM. Em uma configuração de VPC compartilhada, project_id corresponde ao projeto proprietário da instância, geralmente o projeto de serviço.	Metadados
dest_instance	InstanceDetails Se o destino da conexão for uma VM localizada na mesma VPC, esse campo será preenchido com os detalhes da instância da VM. Em uma configuração de VPC compartilhada, project_id corresponde ao projeto proprietário da instância, geralmente o projeto de serviço.	Metadados
src_location	GeographicDetails Se a origem da conexão for externa à VPC, esse campo será preenchido com metadados de local disponíveis.	Metadados
dest_location	GeographicDetails Se o destino da conexão for externo à VPC, esse campo será preenchido com metadados de local disponíveis.	Metadados
src_vpc	VpcDetails Se a origem da conexão for uma VM localizada na mesma VPC, esse campo será preenchido com os detalhes da rede VPC. Em uma configuração de VPC compartilhada, project_id corresponde ao do projeto host.	Metadados
dest_vpc	VpcDetails Se o destino da conexão for uma VM localizada na mesma VPC, esse campo será preenchido com os detalhes da rede VPC. Em uma configuração de VPC compartilhada, project_id corresponde ao do projeto host.	Metadados

Formato do campo IpConnection

Campo	Tipo	Descrição
protocolo	int32	Número do protocolo IANA
src_ip	string	Endereço IP de origem
dest_ip	string	Endereço IP de destino
src_port	int32	Porta de origem
dest_port	int32	Porta de destino

Formato do campo GkeDetails

Campo	Tipo	Descrição
cluster	ClusterDetails	Metadados do cluster do GKE
pod	PodDetails	Metadados do pod do GKE, preenchidos quando a origem ou o destino do tráfego for um pod.
serviço	ServiceDetails	Metadados do Serviço do GKE, preenchidos apenas em endpoints de Serviço. O registro contém até dois Serviços. Se houver mais de dois Serviços relevantes, esse campo conterá um único Serviço com um marcador MANY_SERVICES especial.

Formato do campo ClusterDetails

Campo	Tipo	Descrição
cluster_location	string	Local do cluster. É uma zona ou uma região, dependendo se o cluster for zonal ou regional.
cluster_name	string	Nome do cluster do GKE

Formato do campo PodDetails

Campo	Tipo	Descrição
pod_name	string	Nome do pod
pod_namespace	string	Namespace do pod

Formato do campo ServiceDetails

Campo	Tipo	Descrição
service_name	string	Nome do serviço. Se houver mais de dois Serviços relevantes, o campo será definido como um marcador MANY_SERVICES especial.
service_namespace	string	Namespace do Serviço

Exemplo:

Se houver dois serviços, o campo Serviço será semelhante a:

service: [
 0: {
  service_name: "my-lb-service"
  service_namespace: "default"
 }
 1: {
  service_name: "my-lb-service2"
  service_namespace: "default"
 }
]

Se houver mais de dois serviços, o campo Serviço será semelhante a:

service: [
 0: {
  service_name: "MANY_SERVICES"
 }
]

Formato do campo InstanceDetails

Campo	Tipo	Descrição
project_id	string	Código do projeto que contém a VM
region	string	Região da VM
vm_name	string	Nome da instância da VM
zona	string	Zona da VM

Formato do campo GeographicDetails

Campo	Tipo	Descrição
asn	int32	O número de sistema autônomo (ASN, na sigla em inglês) da rede externa a que este endpoint pertence.
cidade	string	Cidade para endpoints externos
continent	string	Continente para endpoints externos
country	string	País para endpoints externos, representado por códigos de país ISO 3166-1 Alfa-3.
region	string	Região para endpoints externos

Formato do campo VpcDetails

Campo	Tipo	Descrição
project_id	string	Código do projeto que contém a VPC
subnetwork_name	string	Sub-rede em que a VM está operando
vpc_name	string	VPC em que a VM está operando

Filtragem de registros

Ao ativar os registros de fluxo de VPC, é possível definir um filtro com base nos campos de base e de metadados que preservam apenas os registros que correspondem ao filtro. Todos os outros registros serão descartados antes de serem gravados no Logging. Isso economiza dinheiro e reduz o tempo necessário para encontrar as informações que você está procurando.

É possível filtrar por qualquer subconjunto de campos do Formato de registro.

A filtragem de registros de fluxo de VPC usa CEL, uma linguagem de expressão incorporada para expressões lógicas baseadas em atributos. As expressões de filtro dos registros de fluxo de VPC têm um limite de 2.048 caracteres. Para mais informações, consulte Operadores lógicos de CEL compatíveis.

Para mais informações sobre a CEL, consulte a introdução da CEL e a definição da linguagem. O recurso de filtro de geração é compatível com um subconjunto limitado de sintaxe CEL.

Para informações sobre como criar uma sub-rede que usa filtragem de registros, consulte as instruções da CLI gcloud ou da API sobre Como ativar os registros de fluxo de VPC ao criar uma sub-rede.

Para informações sobre como configurar a filtragem de registros, consulte as instruções da CLI gcloud ou da API sobre como atualizar parâmetros dos registros de fluxo de VPC.

Exemplo 1: limitar a coleta de registros a uma VM específica chamada my-vm. Nesse caso, serão gravados apenas os registros em que o campo src_instance for informado como my-vm pela origem do tráfego ou em que o campo dst_instance for informado como my-vm pelo destino do tráfego.

gcloud compute networks subnets update my-subnet \
    --logging-filter-expr="(src_instance.vm_name == 'my-vm' && reporter=='SRC') || (dest_instance.vm_name == 'my-vm' && reporter=='DEST')"

Exemplo 2: limitar a coleta de registros a pacotes com endereços IP de origem na sub-rede 10.0.0.0/8.

gcloud compute networks subnets update my-subnet \
    --logging-filter-expr="inIpRange(connection.src_ip, '10.0.0.0/8')"

Exemplo 3: limitar a coleta de registros ao tráfego externo a uma VPC.

gcloud compute networks subnets update my-subnet \
    --logging-filter-expr '!(has(src_vpc.vpc_name) && has(dest_vpc.vpc_name))'

Operadores lógicos compatíveis com CEL

Expressão	Tipos compatíveis	Descrição
verdadeiro, falso	Booleano	Constantes booleanas
x == y x != y	Booleano, Int, String	Operadores de comparação Exemplo: connection.protocol == 6
x && y x || y	Booleano	Operadores lógicos booleanos Exemplo: connection.protocol == 6 && src_instance.vm_name == "vm_1"
!x	Booleano	Negação
1, 2.0, 0, ...	Int	Literais numéricos constantes
x + y	String	Concatenação de string
"foo", 'foo', ...	String	Literal de string constante
x.lower()	String	Retorna o valor em minúsculas da string
x.upper()	String	Retorna o valor em maiúsculas da string
x.contains(y)	String	Retorna verdadeiro se a string contiver a substring especificada
x.startsWith(y)	String	Retorna verdadeiro se a string começar com a substring especificada
x.endsWith(y)	String	Retorna verdadeiro se a string terminar com a substring especificada
inIpRange(X, Y)	String	Retorna verdadeiro se X for um IP e Y for um intervalo de IP que contenha X Exemplo: inIpRange("1.2.3.1", "1.2.3.0/24")
x.containsFieldValue(y)	x: list y: map(string, string)	Retorna verdadeiro se a lista contiver um objeto com campos que correspondem aos pares de chave-valor especificados Exemplo: dest_gke_details.service.containsFieldValue({'service_name': 'service1', 'service_namespace': 'namespace1'})
has(x)	String	Retorna verdadeiro se o campo estiver presente.

Exemplos de padrão de tráfego

Esta seção demonstra como os registros de fluxo de VPC funcionam em vários casos de uso.

Fluxos de VM para VM na mesma rede VPC

A VM flui dentro de 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
request	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
request	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
request	10.10.0.2	203.0.113.5	1.224	src_instance.* src_vpc.* dest_location.*
resposta	203.0.113.5	10.10.0.2	5.342	dest_instance.* dest_vpc.* src_location.*

Fluxos de VM para 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 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
request	10.10.0.2	10.30.0.2	1.224	src_instance.* src_vpc.*
resposta	10.30.0.2	10.10.0.2	5.342	dest_instance.* dest_vpc.*

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 "webserver", "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	webserver	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 acesso 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 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 para VM em balanceadores 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 ambiente convidado do Linux ou do Windows 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. Para um exemplo de par solicitação/resposta HTTP, a tabela a seguir explica os campos das entradas de registro de fluxo observadas. Para este exemplo, considere a seguinte configuração de rede:

• Instância do navegador em 192.168.1.2
• Balanceador de carga de rede de passagem interna em 10.240.0.200
• Instância do servidor da Web em 10.240.0.3

Direção do tráfego	reporter	connection.src_ip	connection.dest_ip	connection.src_instance	connection.dest_instance
Solicitação	SRC	192.168.1.2	10.240.0.200	Instância do navegador
Solicitação	DEST	192.168.1.2	10.240.0.200	Instância do navegador	Instância do servidor da Web
Resposta	SRC	10.240.0.3	192.168.1.2	Instância do servidor da Web	Instância do navegador
Resposta	DEST	10.240.0.200	192.168.1.2		Instância do navegador

A VM solicitante não sabe qual VM responderá à solicitação. Além disso, uma vez que a outra VM envia uma resposta tendo como endereço de origem o IP do balanceador de carga interno, ela não sabe qual VM respondeu. Por esses motivos, a VM solicitante não pode adicionar informações dest_instance ao seu relatório, mas apenas informações src_instance. Como a VM de resposta conhece o endereço IP da outra VM, ela fornece as duas informações, src_instance e dest_instance.

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) 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. 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á fazendo 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 público com um destino de entrada será encerrada no serviço do balanceador de carga. 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

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

As solicitações de um endereço IP público 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

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) 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.*

Preços

São aplicados preços padrão para o Logging, BigQuery ou Pub/Sub. Os preços de registros de fluxo de VPC estão descritos em Preços de telemetria de rede.

Perguntas frequentes

• Os registros de fluxo de VPC incluem o tráfego permitido e negado com base nas regras de firewall?

  • Os registros de fluxo de VPC abordam o tráfego a partir da perspectiva de uma VM. Todo o tráfego de saída (saída) de uma VM é registrado, mesmo se ela for bloqueada por uma regra de firewall de negação de saída. O tráfego de entrada (recebido) é registrado se for permitido por uma regra de firewall de permissão de entrada. O tráfego de entrada bloqueado por uma regra de firewall de negação de entrada não será registrado.

• Os registros de fluxo de VPC funcionam com instâncias de VM com várias interfaces?

  • Sim, é possível ativar os registros de fluxo de VPC para todas as interfaces em uma VM com várias interfaces.

• Os registros de fluxo da VPC funcionam com redes legadas?

  • Não, os registros de fluxo de VPC não são compatíveis com redes legadas.

A seguir

• Usar registros de fluxo da VPC