Mirroring pacchetto

Questa pagina è una panoramica del servizio Mirroring pacchetto.

Il mirroring pacchetto clona il traffico delle istanze specificate nel tuo Virtual Private Cloud (VPC) e la inoltra per l'esame. Mirroring pacchetto acquisisce tutto il traffico e i dati dei pacchetti, tra cui: e intestazioni. L'acquisizione può essere configurata sia per il traffico in uscita che per il traffico in entrata solo traffico in entrata o solo traffico in uscita.

Il mirroring viene eseguito sulle istanze della macchina virtuale (VM), non sulla rete. Di conseguenza, il servizio Mirroring pacchetto consuma larghezza di banda aggiuntiva sulla delle VM in esecuzione.

Il mirroring pacchetto è utile quando devi monitorare e analizzare la sicurezza . Esporta tutto il traffico, non solo quello tra periodi di campionamento. Ad esempio, puoi utilizzare il software di sicurezza che analizza il traffico sottoposto a mirroring per rilevare tutte le minacce o le anomalie. Inoltre, puoi esaminare tutto il traffico per rilevare i problemi di prestazioni dell'applicazione. Per ulteriori informazioni, consulta esempi di casi d'uso.

Come funziona

La funzionalità Mirroring pacchetto copia il traffico dalle origini con mirroring e lo invia a un destinazione raccoglitore. Per configurare il mirroring pacchetto, occorre creare un pacchetto criterio di mirroring che specifica l'origine e la destinazione.

  • Le origini con mirroring sono istanze VM di Compute Engine che puoi selezionare specificando subnet, tag di rete o nomi di istanze. Se specifichi una subnet, viene eseguito il mirroring di tutte le istanze esistenti e future in quella subnet. Puoi specificare uno o più tipi di origine: se un'istanza corrisponde ad almeno uno di questi, in modo speculare.

    Il mirroring pacchetto raccoglie il traffico dall'interfaccia di rete di un'istanza nella rete in cui si applica il criterio di Mirroring pacchetto. Nei casi in cui un'istanza ha più interfacce di rete, le altre interfacce non vengono sottoposte a mirroring a meno che è stato configurato un altro criterio.

  • Una destinazione raccoglitore è un gruppo di istanze protetto da un carico interno con il bilanciatore del carico di rete passthrough esterno regionale. Le istanze nel gruppo di istanze sono definite raccoglitore di Compute Engine.

    Quando specifichi la destinazione del raccoglitore, inserisci il nome di un inoltro associata al bilanciatore del carico di rete passthrough interno. Google Cloud quindi inoltra il traffico sottoposto a mirroring alle istanze del raccoglitore. Un interno il bilanciatore del carico per Mirroring pacchetto è simile ad altri carichi interni di fatturazione, tranne per il fatto che la regola di forwarding deve essere configurata Mirroring pacchetto. Tutto il traffico non sottoposto a mirroring inviato al carico viene eliminato.

Filtri

Per impostazione predefinita, Mirroring pacchetto raccoglie tutto il traffico IPv4 dei di Compute Engine. Anziché raccogliere tutto il traffico IPv4, puoi utilizzare i filtri per espandere il traffico raccolto per includere tutto o parte del traffico IPv6. Puoi anche utilizza i filtri per restringere il traffico di cui viene eseguito il mirroring, che possono aiutarti a limitare la larghezza di banda utilizzata dalle istanze con mirroring.

Puoi configurare filtri per raccogliere il traffico in base a intervalli di protocollo e CIDR (IPv4, IPv6 o entrambi), direzione del traffico (solo in entrata, solo in uscita entrambi) o una combinazione di questi.

Ordine delle norme

A un'istanza possono essere applicati più criteri di mirroring pacchetto. La priorità di un il criterio di mirroring pacchetto è sempre 1000 e non può essere è cambiato. I criteri identici non sono supportati. Google Cloud può inviare verso uno qualsiasi dei bilanciatori del carico configurati con i criteri di Mirroring pacchetto. Per inviare in modo prevedibile e coerente il traffico sottoposto a mirroring a un singolo bilanciatore del carico, crea criteri con filtri che non si sovrappongono. Se gli intervalli si sovrappongono, imposta protocolli di filtro univoci.

A seconda del filtro di ciascun criterio, Google Cloud sceglie un criterio flusso di lavoro. Se disponi di criteri distinti, Google Cloud utilizza che corrisponde al traffico sottoposto a mirroring. Ad esempio, potresti avere un criterio con il filtro 198.51.100.3/24:TCP e un altro criterio che ha il filtro 2001:db8::/64:TCP:UDP. Poiché i criteri sono distinti, non c'è ambiguità sul criterio utilizzato da Google Cloud.

Tuttavia, se i criteri si sovrappongono, Google Cloud valuta i filtri per scegliere il criterio da usare. Ad esempio, potresti avere due uno con un filtro per 10.0.0.0/24:TCP e un altro per 10.0.0.0/16:TCP. Questi criteri si sovrappongono perché i rispettivi intervalli CIDR si sovrappongono.

Quando sceglie un criterio, Google Cloud assegna la priorità ai criteri confrontando la dimensione dell'intervallo CIDR del proprio filtro.

Google Cloud sceglie un criterio in base a un filtro:

  • Se i criteri hanno intervalli CIDR diversi ma sovrapposti e protocolli, Google Cloud sceglie il criterio che utilizza il protocollo Intervallo CIDR. Supponiamo che la destinazione di un pacchetto TCP che lasci un'istanza con mirroring è 10.240.1.4 e esistono due criteri seguenti filtri: 10.240.1.0/24:ALL e 10.240.0.0/16:TCP. Poiché la corrispondenza più specifica per 10.240.1.4 è 10.240.1.0/24:ALL, Google Cloud utilizza il criterio con il filtro 10.240.1.0/24:ALL.

  • Se i criteri specificano lo stesso esatto intervallo CIDR con protocolli sovrapposti, Google Cloud sceglie un criterio con il protocollo più specifico. Ad esempio, i seguenti filtri hanno lo stesso intervallo ma si sovrappongono protocolli: 10.240.1.0/24:TCP e 10.240.1.0/24:ALL. Per TCP corrispondenti traffico, Google Cloud utilizza il criterio 10.240.1.0/24:TCP. Il criterio 10.240.1.0/24:ALL si applica al traffico corrispondente per tutti gli altri protocolli.

  • Se i criteri hanno lo stesso esatto intervallo CIDR ma protocolli distinti, questi I criteri non si sovrappongono. Google Cloud utilizza il criterio che corrisponde al protocollo del traffico sottoposto a mirroring. Ad esempio, potresti avere un criterio per 2001:db8::/64:TCP e un altro per 2001:db8::/64:UDP. In base per il traffico sottoposto a mirroring, Google Cloud utilizza .

  • Se le norme sovrapposte hanno lo stesso esatto filtro, sono identiche. Nella in questo caso, Google Cloud potrebbe scegliere lo stesso criterio o criterio ogni volta che il traffico corrispondente viene rivalutato rispetto a questi criteri. Ti consigliamo di evitare di creare il mirroring pacchetto identico criteri.

Log di flusso VPC

I log di flusso VPC non registrano i pacchetti con mirroring. Se un'istanza del raccoglitore si trova su un in cui sono abilitati i log di flusso VPC, il traffico inviato direttamente viene registrata l'istanza del raccoglitore, compreso il traffico proveniente dalle istanze sottoposte a mirroring. Questo è, se l'indirizzo IPv4 o IPv6 di destinazione originale corrisponde all'indirizzo IPv4 o IPv6 dell'istanza del raccoglitore, il flusso viene registrato.

Per ulteriori informazioni sui log di flusso VPC, consulta Utilizzo dei log di flusso VPC.

Proprietà chiave

Il seguente elenco descrive i vincoli o i comportamenti Mirroring pacchetto che è importante comprendere prima di utilizzarlo:

  • Ogni criterio di mirroring pacchetto definisce origini con mirroring e un raccoglitore destinazione. Devi rispettare le seguenti regole:

    • Tutte le origini sottoposte a mirroring devono trovarsi nello stesso progetto, VPC e la regione Google Cloud.
    • Una destinazione del raccoglitore deve trovarsi nella stessa regione delle origini sottoposte a mirroring. Una destinazione del raccoglitore può essere situata nello stesso VPC una rete VPC come le origini con mirroring o una rete VPC connessa alle sorgenti sottoposte a mirroring utilizzando il peering di rete VPC.
    • Ogni criterio di mirroring può fare riferimento solo a una singola destinazione del raccoglitore. Tuttavia, a una singola destinazione raccoglitore possono essere associati più e i criteri di mirroring.
  • Tutti i protocolli di livello 4 sono supportati dal servizio Mirroring pacchetto.

  • Non puoi eseguire il mirroring e raccogliere il traffico sulla stessa interfaccia di rete di una VM perché questa operazione causerebbe un loop di mirroring.

  • Eseguire il mirroring del traffico che passa tra i pod sullo stesso Google Kubernetes Engine (GKE) devi abilitare l'opzione Intranode visibilità per nel cluster.

  • Per eseguire il mirroring del traffico IPv6, utilizza i filtri per specificare gli intervalli CIDR IPv6 del traffico IPv6 di cui vuoi eseguire il mirroring. Puoi eseguire il mirroring di tutto il traffico IPv6 utilizzando un filtro per l'intervallo CIDR di ::/0. Puoi eseguire il mirroring di tutti gli indirizzi IPv4 e IPv6 utilizzando il seguente filtro per l'intervallo CIDR separato da virgole: 0.0.0.0/0,::/0.

  • Il traffico di mirroring consuma larghezza di banda sull'istanza sottoposta a mirroring. Ad esempio: se un'istanza con mirroring subisce 1 Gbps di traffico in entrata e 1 Gbps di traffico in uscita, il traffico totale sulle istanze è 1 Gbps di traffico in entrata e 3 Gbit/s di traffico in uscita (1 Gbit/s di traffico normale e 2 Gbit/s di traffico in uscita sottoposto a mirroring traffico). Per limitare il traffico raccolto, puoi utilizzare i filtri.

  • Il costo del mirroring pacchetto varia in base alla quantità di traffico in uscita del traffico che viaggia da un'istanza sottoposta a mirroring a un gruppo di istanze e indica se il traffico viaggia da una zona all'altra.

  • Mirroring pacchetto si applica sia alla direzione in entrata che in uscita. Se due Le istanze VM di cui viene eseguito il mirroring si inviano traffico l'una all'altra Google Cloud raccoglie due versioni dello stesso pacchetto. Puoi modificare questo comportamento specificando che solo i pacchetti in entrata o in uscita in modo speculare.

  • È possibile creare un numero massimo di criteri di mirroring pacchetto di un progetto. Per ulteriori informazioni, consulta le quote per progetto nella alla pagina quote.

  • Per ogni criterio di mirroring pacchetto, il numero massimo di origini sottoposte a mirroring che che puoi specificare dipende dal tipo di origine:

    • 5 subnet
    • 5 tag
    • 50 istanze
  • Il numero massimo di filtri per il mirroring pacchetto è 30, ovvero il numero Intervalli di indirizzi IPv4 e IPv6 moltiplicati per il numero di protocolli. Per Ad esempio, puoi specificare 30 intervalli e un protocollo, ovvero 30 filtri. Tuttavia, non è possibile specificare 30 intervalli e 2 protocolli, ovvero 60 e maggiore del valore massimo.

  • Ti sono addebitati i costi relativi alla quantità di dati elaborati dal servizio Mirroring pacchetto. Per i dettagli, consulta i prezzi di Mirroring pacchetto.

    Ti vengono addebitati anche tutti i componenti prerequisiti e il traffico in uscita correlati al Mirroring pacchetto. Ad esempio, le istanze che raccolgono traffico vengono addebitate alla tariffa standard. Inoltre, se il pacchetto il mirroring del traffico viaggia tra le zone, ti viene addebitato il costo del traffico in uscita per via del traffico. Per i dettagli sui prezzi, consulta le relative pagina dei prezzi.

  • Il traffico sottoposto a mirroring viene criptato solo se la VM lo cripta livello di applicazione. Mentre le connessioni da VM a VM all'interno di reti VPC e reti VPC in peering criptato, la crittografia e la decrittografia avvengono negli hypervisor. Dal punto di vista della VM, questo traffico non è criptato.

Casi d'uso

Le seguenti sezioni descrivono scenari reali che dimostrano perché puoi potrebbe utilizzare il mirroring pacchetto.

Sicurezza aziendale

I team di sicurezza e di network engineering devono assicurarsi di riuscire a individuare anomalie e minacce che potrebbero indicare intrusioni e violazioni della sicurezza. Loro eseguire il mirroring di tutto il traffico, in modo che possa completare un'ispezione completa per controllare i flussi sospetti. Dato che gli attacchi possono estendersi su più pacchetti, i team di sicurezza devono essere in grado di ottenere tutti i pacchetti per ogni flusso.

Ad esempio, i seguenti strumenti di sicurezza richiedono di acquisire più di pacchetti:

  • Sistema di rilevamento delle intrusioni (IDS) richiedono più pacchetti di un singolo flusso per corrispondere a un in modo che gli strumenti possano rilevare minacce persistenti.

  • I motori di ispezione approfondita dei pacchetti ispezionano i payload dei pacchetti per rilevare il protocollo le anomalie in uso.

  • L’analisi forense della rete per la conformità PCI e altri casi d’uso normativi richiedono per esaminare la maggior parte dei pacchetti. Mirroring pacchetto offre una soluzione per acquisire diversi vettori d'attacco, come comunicazioni non frequenti o tentativi di comunicazione non riusciti.

Monitoraggio delle prestazioni delle applicazioni

I tecnici di rete possono utilizzare il traffico sottoposto a mirroring per risolvere i problemi di prestazioni generati dai team delle applicazioni e dei database. Per verificare la presenza di problemi di rete, gli ingegneri di rete possono vedere cosa sta succedendo attraverso la rete invece di affidarsi log delle applicazioni.

Ad esempio, i tecnici di rete possono utilizzare i dati del servizio Mirroring pacchetto per completare le seguenti attività:

  • Analizzare protocolli e comportamenti in modo da poter individuare e risolvere problemi come o la perdita di pacchetti o la reimpostazione TCP.

  • Analizzare (in tempo reale) i modelli di traffico da desktop remoto, VoIP e altro applicazioni interattive. I tecnici di rete possono cercare problemi che esperienza utente dell'applicazione, come il reinvio di più pacchetti o del previsto.

Esempi di topologie di destinazione del raccoglitore

Puoi utilizzare il mirroring pacchetto in varie configurazioni. I seguenti esempi mostrano la posizione delle destinazioni dei raccoglitori e le relative norme per diverse del mirroring dei pacchetti, come il peering di rete VPC VPC condiviso.

Destinazione del raccoglitore nella stessa rete

L'esempio seguente mostra una configurazione di mirroring pacchetto in cui l'origine e la destinazione del raccoglitore si trovano nella stessa rete VPC.

Un criterio di mirroring pacchetto con un
         un'origine e un raccoglitore di destinazione nello stesso VPC
         in ogni rete.
Criterio di mirroring del pacchetto con tutte le risorse nello stesso Rete VPC (fai clic per ingrandire).

Nel diagramma precedente, il criterio di mirroring pacchetto è configurato per eseguire mirrored-subnet e invia il traffico sottoposto a mirroring al bilanciatore del carico di rete passthrough interno. Google Cloud esegue il mirroring del traffico sulle istanze esistenti e future in una subnet. Tutto il traffico da e verso internet, host on-premise o Google viene eseguito il mirroring.

Destinazione del raccoglitore in una rete peer

Puoi creare un modello di raccoglitore centralizzato, in cui le istanze in diversi Le reti VPC inviano traffico sottoposto a mirroring a una destinazione del raccoglitore in una rete VPC centrale, In questo modo, puoi utilizzare una singola raccoglitore di destinazione.

Nell'esempio seguente, il bilanciatore del carico di rete passthrough interno collector-load-balancer è nella regione us-central1 nella rete VPC network-a in project-a. Questo raccoglitore di destinazione può essere utilizzato da due Mirroring pacchetto norme:

  • policy-1 raccoglie pacchetti da origini con mirroring nella regione us-central1 nella rete VPC network-a in project-a e le invia per arrivare alla destinazione collector-load-balancer.

  • policy-2 raccoglie pacchetti da origini con mirroring nella regione us-central1 nella rete VPC network-b in project-b e le invia per la stessa destinazione collector-load-balancer.

Sono necessari due criteri di mirroring perché esistono origini con mirroring reti VPC.

Un criterio di mirroring pacchetto
         in cui si trova la destinazione del raccoglitore. La rete è in peering
         con altre reti in cui risiedono le sorgenti sottoposte a mirroring.
Criteri di mirroring del pacchetto in una rete centrale in peering con altri reti con origini speculari (fai clic per ingrandire).

Nel diagramma precedente, la destinazione del raccoglitore raccoglie il traffico sottoposto a mirroring da subnet in due reti diverse. Tutte le risorse (dati di origine e destinazione) deve trovarsi nella stessa regione. La configurazione in network-a è simile a nell'esempio in cui l'origine sottoposta a mirroring e la destinazione raccoglitore si trovano nella stessa rete VPC, L'app policy-1 è configurata per raccogliere traffico da subnet-a e invialo a collector-ilb.

policy-2 è configurato in project-a, ma specifica subnet-b come mirroring sorgente. Poiché network-a e network-b sono in peering, la destinazione il raccoglitore può raccogliere il traffico da subnet-b.

Le reti si trovano in progetti diversi e potrebbero avere proprietari diversi. È entrambi i proprietari possono creare il criterio di Mirroring pacchetto se hanno il autorizzazioni appropriate:

  • Se i proprietari di project-a creano il criterio di mirroring pacchetto, devono il ruolo compute.packetMirroringAdmin sulla rete, sulla subnet di cui eseguire il mirroring in project-b.

  • Se i proprietari di project-b creano il criterio di mirroring pacchetto, devono hanno il ruolo compute.packetMirroringUser in project-a.

Per ulteriori informazioni sull'abilitazione della connettività privata tra due Per le reti VPC, consulta Peering di rete VPC.

VPC condiviso

Nei seguenti scenari di VPC condiviso, le istanze sottoposte a mirroring per le destinazioni del raccoglitore si trovano tutte nella stessa rete VPC condiviso. Anche se Le risorse sono tutte nella stessa rete, possono trovarsi in progetti diversi, come progetto host o tra più progetti di servizio diversi. Le seguenti esempi mostrano dove è necessario creare criteri di mirroring pacchetto e chi può creare che li rappresentano.

Se sia l'origine sottoposta a mirroring sia la destinazione del raccoglitore si trovano nello stesso progetto, in un progetto host o in un progetto di servizio, la configurazione è simile tutto ciò che si trova nella stessa rete VPC. Il progetto proprietario può creare tutte le risorse e impostare le autorizzazioni richieste progetto.

Per ulteriori informazioni, consulta la sezione Panoramica del VPC condiviso.

Destinazione del raccoglitore nel progetto di servizio

Nell'esempio seguente, la destinazione del raccoglitore si trova in un progetto di servizio che utilizza una subnet nel progetto host. In questo caso, la norma è anche progetto di servizio. Il criterio potrebbe trovarsi anche nel progetto host.

La relazione tra l'host e il servizio
         progetti per il Mirroring pacchetto.
Destinazione del raccoglitore nel progetto di servizio (fai clic per ingrandire).

Nel diagramma precedente, il progetto di servizio contiene le istanze del raccoglitore che utilizzano la subnet raccoglitore nella reteVPC condivisoa. Il pacchetto Il criterio di mirroring è stato creato nel progetto di servizio ed è configurato per eseguire il mirroring con un'interfaccia di rete in subnet-mirrored.

Gli utenti del servizio o del progetto host possono creare il criterio di mirroring pacchetto. Per farlo, Gli utenti devono avere il ruolo compute.packetMirroringUser nel progetto di servizio in cui si trova la destinazione del raccoglitore. Gli utenti devono inoltre disporre Ruolo compute.packetMirroringAdmin nelle origini sottoposte a mirroring.

Destinazione del raccoglitore nel progetto host

Nell'esempio seguente, la destinazione del raccoglitore si trova nel progetto host e le istanze con mirroring si trovano nei progetti di servizio.

Questo esempio potrebbe riguardare scenari in cui gli sviluppatori distribuiscono applicazioni progetti di servizio e utilizzano la rete VPC condiviso. Non devono necessariamente e gestire l'infrastruttura di rete o Mirroring pacchetto. Invece, un un team centralizzato di networking o sicurezza, che ha il controllo del progetto host e la rete VPC condiviso, sono responsabili del provisioning e i criteri di mirroring.

La relazione tra l'host e il servizio
         progetti per il Mirroring pacchetto.
Destinazione del raccoglitore nel progetto host (fai clic per ingrandire).

Nel diagramma precedente, il criterio di mirroring pacchetto viene creato nell'host in cui si trova la destinazione del raccoglitore. Il criterio è configurato su delle istanze nella subnet sottoposta a mirroring. Le istanze VM nei progetti di servizio e il relativo traffico viene sottoposto a mirroring.

Gli utenti del servizio o del progetto host possono creare il criterio di mirroring pacchetto. Per farlo, gli utenti nel progetto di servizio devono avere il ruolo compute.packetMirroringUser in del progetto host. Gli utenti nel progetto host richiedono Ruolo compute.packetMirroringAdmin per le origini sottoposte a mirroring nel servizio in modo programmatico a gestire i progetti.

Istanze VM con più interfacce

Puoi includere in un pacchetto istanze VM con più interfacce di rete di Google Cloud. Poiché un criterio può eseguire il mirroring delle risorse da una singola rete, non puoi creare un criterio per eseguire il mirroring del traffico per tutte le interfacce di rete di un in esecuzione in un'istanza Compute Engine. Se è necessario eseguire il mirroring di più di un'interfaccia di rete di un di interfaccia di rete, devi creare un criterio di Mirroring pacchetto per perché ogni interfaccia si connette a una rete VPC univoca.

Passaggi successivi