Espelhamento de pacotes

Esta página é uma vista geral do espelhamento de pacotes na rede da nuvem virtual privada (VPC). Se quiser analisar o tráfego de rede das suas cargas de trabalho em grande escala e monitorizar o tráfego de rede através de dispositivos virtuais de terceiros, use a sincronização de pacotes de integração de segurança de rede. Para mais informações, consulte o artigo Vista geral da integração fora da banda.

O espelhamento de pacotes clona o tráfego de instâncias especificadas na sua rede VPC e encaminha-o para exame. A replicação de pacotes captura todo o tráfego e dados de pacotes, incluindo payloads e cabeçalhos. A captura pode ser configurada para tráfego de saída e de entrada, apenas tráfego de entrada ou apenas tráfego de saída.

A replicação acontece nas instâncias de máquinas virtuais (VM) e não na rede. Consequentemente, a replicação de pacotes consome largura de banda adicional nas VMs.

A replicação de pacotes é útil quando precisa de monitorizar e analisar o seu estado de segurança. Exporta todo o tráfego e não apenas o tráfego entre períodos de amostragem. Por exemplo, pode usar software de segurança que analise o tráfego espelhado para detetar todas as ameaças ou anomalias. Além disso, pode inspecionar o fluxo de tráfego completo para detetar problemas de desempenho da aplicação. Para mais informações, consulte os exemplos de utilização.

Como funciona

O espelhamento de pacotes copia o tráfego de origens espelhadas e envia-o para um destino de recolha. Para configurar o espelhamento de pacotes, crie uma política de espelhamento de pacotes que especifique a origem e o destino.

• As origens espelhadas são instâncias de VM do Compute Engine que pode selecionar especificando sub-redes, etiquetas de rede ou nomes de instâncias. Se especificar uma sub-rede, todas as instâncias existentes e futuras nessa sub-rede são espelhadas. Pode especificar um ou mais tipos de origens. Se uma instância corresponder a, pelo menos, um deles, é replicada.

  O espelhamento de pacotes recolhe tráfego da interface de rede de uma instância na rede onde a política de espelhamento de pacotes se aplica. Nos casos em que uma instância tem várias interfaces de rede, as outras interfaces não são espelhadas, a menos que outra política tenha sido configurada para o fazer.

• Um destino do coletor é um grupo de instâncias que está atrás de um equilibrador de carga interno. As instâncias no grupo de instâncias são denominadas instâncias de recolha.

  Quando especifica o destino do coletor, introduz o nome de uma regra de encaminhamento associada ao balanceador de carga de passagem interno. Google CloudEm seguida, encaminha o tráfego espelhado para as instâncias do coletor. Um balanceador de carga interno para a replicação de pacotes é semelhante a outros balanceadores de carga internos, exceto que a regra de encaminhamento tem de ser configurada para a replicação de pacotes. Todo o tráfego não espelhado enviado para o balanceador de carga é ignorado.

Filtragem

Por predefinição, a replicação de pacotes recolhe todo o tráfego IPv4 de instâncias replicadas. Em vez de recolher todo o tráfego IPv4, pode usar filtros para expandir o tráfego recolhido de modo a incluir todo ou parte do tráfego IPv6. Também pode usar filtros para restringir o tráfego espelhado, o que pode ajudar a limitar a largura de banda usada por instâncias espelhadas.

Pode configurar filtros para recolher tráfego com base no protocolo, nos intervalos CIDR (IPv4, IPv6 ou ambos), na direção do tráfego (apenas entrada, apenas saída ou ambos) ou numa combinação.

Ordem da política

Podem aplicar-se várias políticas de espelhamento de pacotes a uma instância. A prioridade de uma política de replicação de pacotes é sempre 1000 e não pode ser alterada. As políticas idênticas não são suportadas. Google Cloud pode enviar tráfego para qualquer um dos balanceadores de carga que tenham sido configurados com políticas de espelhamento de pacotes idênticas. Para enviar tráfego espelhado de forma previsível e consistente para um único equilibrador de carga, crie políticas com filtros com intervalos de endereços não sobrepostos. Se os intervalos se sobrepuserem, defina protocolos de filtragem únicos.

Consoante o filtro de cada política, Google Cloud escolhe uma política para cada fluxo. Se tiver políticas distintas,o Google Cloud usa a política correspondente que corresponde ao tráfego espelhado. Por exemplo, pode ter uma política com o filtro 198.51.100.3/24:TCP e outra política com o filtro 2001:db8::/64:TCP:UDP. Como as políticas são distintas, não existe ambiguidade sobre qual política o Google Cloud usa.

No entanto, se tiver políticas sobrepostas,o sistema Google Cloud avalia os respetivos filtros para escolher a política a usar. Por exemplo, pode ter duas políticas, uma com um filtro para 10.0.0.0/24:TCP e outra para 10.0.0.0/16:TCP. Estas políticas sobrepõem-se porque os respetivos intervalos CIDR se sobrepõem.

Quando escolhe uma política, Google Cloud prioriza as políticas comparando o tamanho do intervalo CIDR do respetivo filtro.

Google Cloud escolhe uma política com base num filtro:

• Se as políticas tiverem intervalos CIDR diferentes, mas sobrepostos, e os mesmos protocolos exatos, o Google Cloud escolhe a política que usa o intervalo CIDR mais específico. Suponhamos que o destino de um pacote TCP que sai de uma instância espelhada é 10.240.1.4 e existem duas políticas com os seguintes filtros: 10.240.1.0/24:ALL e 10.240.0.0/16:TCP. Uma vez que a correspondência mais específica para 10.240.1.4 é 10.240.1.0/24:ALL,Google Cloud usa a política que tem o filtro 10.240.1.0/24:ALL.

• Se as políticas especificarem exatamente o mesmo intervalo CIDR com protocolos sobrepostos, oGoogle Cloud escolhe uma política com o protocolo mais específico. Por exemplo, os seguintes filtros têm o mesmo intervalo, mas protocolos sobrepostos: 10.240.1.0/24:TCP e 10.240.1.0/24:ALL. Para a correspondência de tráfego TCP, Google Cloud usa a política 10.240.1.0/24:TCP. A política de 10.240.1.0/24:ALL aplica-se ao tráfego correspondente para todos os outros protocolos.

• Se as políticas tiverem exatamente o mesmo intervalo CIDR, mas protocolos distintos, estas políticas não se sobrepõem.O Google Cloud usa a política que corresponde ao protocolo do tráfego espelhado. Por exemplo, pode ter uma política para 2001:db8::/64:TCP e outra para 2001:db8::/64:UDP. Consoante o protocolo do tráfego espelhado, Google Cloud usa a política de TCP ou UDP.

• Se as políticas sobrepostas tiverem o mesmo filtro exato, são idênticas. Neste caso, Google Cloud pode escolher a mesma política ou uma política diferente sempre que o tráfego correspondente for reavaliado em função destas políticas. Recomendamos que evite criar políticas de replicação de pacotes idênticas.

VPC Flow Logs

Os registos de fluxo da VPC não registam pacotes espelhados. Se uma instância de coletor estiver numa sub-rede com os registos de fluxo da VPC ativados, o tráfego enviado diretamente para a instância de coletor é registado, incluindo o tráfego de instâncias espelhadas. Isto significa que, se o endereço IPv4 ou IPv6 de destino original corresponder ao endereço IPv4 ou IPv6 da instância do coletor, o fluxo é registado.

Para mais informações acerca dos registos de fluxo da VPC, consulte o artigo Usar registos de fluxo da VPC.

Propriedades principais

A lista seguinte descreve restrições ou comportamentos da replicação de pacotes que é importante compreender antes de a usar:

• Cada política de espelhamento de pacotes define origens espelhadas e um destino do coletor. Tem de cumprir as seguintes regras:

  • Todas as origens espelhadas têm de estar no mesmo projeto, rede VPC e Google Cloud região.
  • Um destino do coletor tem de estar na mesma região que as origens espelhadas. Um destino do coletor pode estar localizado na mesma rede VPC que as origens espelhadas ou numa rede VPC ligada à rede das origens espelhadas através do peering de redes VPC.
  • Cada política de espelhamento só pode fazer referência a um único destino de recolha. No entanto, uma única propriedade de recolha pode ser referenciada por várias políticas de replicação.

• Todos os protocolos da camada 4 são suportados pelo espelhamento de pacotes.

• Não pode espelhar nem recolher tráfego na mesma interface de rede de uma instância de VM porque isso causaria um ciclo de espelhamento.

• Para espelhar o tráfego que passa entre os pods no mesmo nó do Google Kubernetes Engine (GKE), tem de ativar a visibilidade dentro dos nós para o cluster.

• Para duplicar o tráfego IPv6, use filtros para especificar os intervalos CIDR IPv6 do tráfego IPv6 que quer duplicar. Pode duplicar todo o tráfego IPv6 usando um filtro de intervalo CIDR de ::/0. Pode espelhar todo o tráfego IPv4 e IPv6 usando o seguinte filtro de intervalo CIDR separado por vírgulas: 0.0.0.0/0,::/0.

• A replicação do tráfego consome largura de banda na instância replicada. Por exemplo, se uma instância espelhada tiver 1 Gbps de tráfego de entrada e 1 Gbps de tráfego de saída, o tráfego total nas instâncias é de 1 Gbps de entrada e 3 Gbps de saída (1 Gbps de tráfego de saída normal e 2 Gbps de tráfego de saída espelhado). Para limitar o tráfego recolhido, pode usar filtros.

• O custo da replicação de pacotes varia consoante a quantidade de tráfego de saída que viaja de uma instância replicada para um grupo de instâncias e se o tráfego viaja entre zonas.

• O espelhamento de pacotes aplica-se à direção de entrada e saída. Se duas instâncias de VM que estão a ser espelhadas enviarem tráfego entre si, oGoogle Cloud recolhe duas versões do mesmo pacote. Pode alterar este comportamento especificando que apenas os pacotes de entrada ou apenas os pacotes de saída são duplicados.

• Existe um número máximo de políticas de espelhamento de pacotes que pode criar para um projeto. Para mais informações, consulte as quotas por projeto na página quotas.

• Para cada política de espelhamento de pacotes, o número máximo de origens espelhadas que pode especificar depende do tipo de origem:

  • 5 sub-redes
  • 5 etiquetas
  • 50 instâncias

• O número máximo de filtros de replicação de pacotes é 30, que é o número de intervalos de endereços IPv4 e IPv6 multiplicado pelo número de protocolos. Por exemplo, pode especificar 30 intervalos e 1 protocolo, o que corresponderia a 30 filtros. No entanto, não pode especificar 30 intervalos e 2 protocolos, o que corresponderia a 60 filtros e excederia o máximo.

• O tráfego espelhado só é encriptado se a VM encriptar esse tráfego na camada de aplicação. Embora as ligações de VM para VM nas redes VPC e nas redes VPC com intercâmbio sejam encriptadas, a encriptação e a desencriptação ocorrem nos hipervisores. Do ponto de vista da VM, este tráfego não está encriptado.

Exemplos de utilização

As secções seguintes descrevem cenários reais que demonstram por que motivo pode usar a replicação de pacotes.

Segurança empresarial

As equipas de engenharia de segurança e de rede têm de garantir que detetam todas as anomalias e ameaças que possam indicar violações e intrusões de segurança. Refletem todo o tráfego para poderem concluir uma inspeção abrangente dos fluxos suspeitos. Uma vez que os ataques podem abranger vários pacotes, as equipas de segurança têm de conseguir obter todos os pacotes para cada fluxo.

Por exemplo, as seguintes ferramentas de segurança requerem a captura de vários pacotes:

• As ferramentas do sistema de deteção de intrusões (IDS) requerem vários pacotes de um único fluxo para corresponder a uma assinatura, para que as ferramentas possam detetar ameaças persistentes.

• Os motores de inspeção profunda de pacotes inspecionam as cargas úteis dos pacotes para detetar anomalias de protocolo.

• A análise forense de rede para conformidade com a PCI e outros exemplos de utilização regulamentares requer que a maioria dos pacotes seja examinada. A replicação de pacotes oferece uma solução para capturar diferentes vetores de ataque, como comunicação pouco frequente ou comunicação tentada, mas sem êxito.

Monitorização do desempenho das aplicações

Os engenheiros de rede podem usar o tráfego espelhado para resolver problemas de desempenho comunicados pelas equipas de aplicações e bases de dados. Para verificar problemas de rede, os engenheiros de rede podem ver o que está a ser transmitido por cabo em vez de dependerem dos registos da aplicação.

Por exemplo, os engenheiros de rede podem usar dados da replicação de pacotes para concluir as seguintes tarefas:

• Analisar protocolos e comportamentos para que possam encontrar e corrigir problemas, como perda de pacotes ou reposições de TCP.

• Analise (em tempo real) os padrões de tráfego do ambiente de trabalho remoto, VoIP e outras aplicações interativas. Os engenheiros de rede podem pesquisar problemas que afetam a experiência do utilizador da aplicação, como reenvios de pacotes múltiplos ou mais reconexões do que o esperado.

Exemplos de topologias de destino do coletor

Pode usar a replicação de pacotes em várias configurações. Os exemplos seguintes mostram a localização dos destinos do coletor e as respetivas políticas para diferentes configurações de espelhamento de pacotes, como o intercâmbio da rede da VPC e a VPC partilhada.

Destino do coletor na mesma rede

O exemplo seguinte mostra uma configuração de espelhamento de pacotes em que a origem espelhada e o destino do coletor estão na mesma rede VPC.

No diagrama anterior, a política de espelhamento de pacotes está configurada para espelhar mirrored-subnet e enviar tráfego espelhado para o Network Load Balancer de passagem interno. Google Cloud espelha o tráfego em instâncias existentes e futuras na sub-rede. Todo o tráfego de e para a Internet, os anfitriões no local ou os serviços Google é espelhado.

Destino do coletor numa rede ponto a ponto

Pode criar um modelo de coletor centralizado, em que as instâncias em diferentes redes de VPC enviam tráfego espelhado para um destino de coletor numa rede de VPC central. Desta forma, pode usar um único coletor de destino.

No exemplo seguinte, o balanceador de carga de rede de encaminhamento interno está na região us-central1 na rede VPC em project-a.collector-load-balancernetwork-a Este coletor de destino pode ser usado por duas políticas de replicação de pacotes:

• policy-1 recolhe pacotes de origens espelhadas na região us-central1 na rede VPC network-a em project-a e envia-os para o destino collector-load-balancer.

• policy-2 recolhe pacotes de origens espelhadas na região us-central1 na rede VPC network-b em project-b e envia-os para o mesmo destino collector-load-balancer.

São necessárias duas políticas de replicação porque existem origens replicadas em diferentes redes VPC.

No diagrama anterior, o destino do coletor recolhe tráfego espelhado de sub-redes em duas redes diferentes. Todos os recursos (a origem e o destino) têm de estar na mesma região. A configuração em network-a é semelhante ao exemplo em que a origem espelhada e o destino do coletor estão na mesma rede de VPC. O policy-1 está configurado para recolher tráfego de subnet-a e enviá-lo para collector-ilb.

policy-2 está configurado em project-a, mas especifica subnet-b como uma fonte refletida. Uma vez que network-a e network-b estão em peering, o coletor de destino pode recolher tráfego de subnet-b.

As redes estão em projetos diferentes e podem ter proprietários diferentes. É possível que qualquer um dos proprietários crie a política de espelhamento de pacotes se tiver as autorizações certas:

• Se os proprietários de project-a criarem a política de espelhamento de pacotes, têm de ter a função compute.packetMirroringAdmin na rede, na sub-rede ou nas instâncias a espelhar em project-b.

• Se os proprietários de project-b criarem a política de espelhamento de pacotes, têm de ter a função de compute.packetMirroringUser em project-a.

Para mais informações sobre como ativar a conetividade privada em duas redes da VPC, consulte o artigo Intercâmbio da rede da VPC.

VPC partilhada

Nos seguintes cenários de VPC partilhada, as instâncias espelhadas para o destino do coletor estão todas na mesma rede VPC partilhada. Embora os recursos estejam todos na mesma rede, podem estar em projetos diferentes, como o projeto anfitrião ou vários projetos de serviço diferentes. Os exemplos seguintes mostram onde as políticas de espelhamento de pacotes têm de ser criadas e quem as pode criar.

Se as origens espelhadas e o destino do coletor estiverem no mesmo projeto, quer num projeto anfitrião ou num projeto de serviço, a configuração é semelhante à de ter tudo na mesma rede VPC. O proprietário do projeto pode criar todos os recursos e definir as autorizações necessárias nesse projeto.

Para mais informações, consulte o artigo Vista geral da VPC partilhada.

Destino do coletor no projeto de serviço

No exemplo seguinte, o destino do coletor está num projeto de serviço que usa uma sub-rede no projeto anfitrião. Neste caso, a política também está no projeto de serviço. A política também pode estar no projeto anfitrião.

No diagrama anterior, o projeto de serviço contém as instâncias do coletor que usam a sub-rede do coletor na rede de VPC partilhada. A política de espelhamento de pacotes foi criada no projeto de serviço e está configurada para espelhar instâncias que tenham uma interface de rede em subnet-mirrored.

Os utilizadores do projeto de serviço ou anfitrião podem criar a política de espelhamento de pacotes. Para tal, os utilizadores têm de ter a função compute.packetMirroringUser no projeto de serviço onde se encontra o destino do coletor. Os utilizadores também têm de ter a função compute.packetMirroringAdmin nas origens espelhadas.

Destino do coletor no projeto anfitrião

No exemplo seguinte, o destino do coletor está no projeto anfitrião e as instâncias espelhadas estão nos projetos de serviço.

Este exemplo pode aplicar-se a cenários em que os programadores implementam aplicações em projetos de serviço e usam a rede de VPC partilhada. Não têm de gerir a infraestrutura de rede nem a replicação de pacotes. Em alternativa, uma equipa de rede ou segurança centralizada, que tem controlo sobre o projeto anfitrião e a rede de VPC partilhada, é responsável pelo aprovisionamento de políticas de replicação de pacotes.

No diagrama anterior, a política de espelhamento de pacotes é criada no projeto de anfitrião, onde se encontra o destino do coletor. A política está configurada para refletir instâncias na sub-rede refletida. As instâncias de VM em projetos de serviço podem usar a sub-rede espelhada e o respetivo tráfego é espelhado.

Os utilizadores do projeto de serviço ou anfitrião podem criar a política de espelhamento de pacotes. Para o fazer, os utilizadores no projeto de serviço têm de ter a função compute.packetMirroringUser no projeto anfitrião. Os utilizadores no projeto anfitrião precisam da função compute.packetMirroringAdmin para origens espelhadas nos projetos de serviço.

Instâncias de VM com várias interfaces

Pode incluir instâncias de VM com várias interfaces de rede numa política de espelhamento de pacotes. Uma vez que uma política pode replicar recursos de uma única rede, não pode criar uma política para replicar o tráfego de todas as interfaces de rede de uma instância. Se precisar de espelhar mais do que uma interface de rede de uma instância com várias interfaces de rede, tem de criar uma política de espelhamento de pacotes para cada interface, uma vez que cada interface se liga a uma rede VPC única.

Preços

É-lhe cobrado o volume de dados processados pela funcionalidade Packet Mirroring. Para obter detalhes, consulte os preços do Packet Mirroring.

Também lhe são cobrados todos os componentes pré-requisitos e o tráfego de saída relacionados com a replicação de pacotes. Por exemplo, as instâncias que recolhem tráfego são cobradas à taxa normal. Além disso, se o tráfego de espelhamento de pacotes viajar entre zonas, é cobrado o tráfego de saída. Para ver detalhes sobre os preços, consulte a página de preços relacionada.

O que se segue?

• Use o espelhamento de pacotes.
• Monitorize a replicação de pacotes.
• Vista geral do balanceador de carga de rede de encaminhamento interno.
• Fornecedores parceiros de espelhamento de pacotes.
• Vista geral da integração fora da banda.