Mirroring pacchetto

Questa pagina fornisce una panoramica del mirroring dei pacchetti.

Il mirroring dei pacchetti clona il traffico delle istanze specificate nella rete VPC (Virtual Private Cloud) e lo inoltra per l'esame. Il mirroring dei pacchetti acquisisce tutto il traffico e i dati dei pacchetti, inclusi payload 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 avviene sulle istanze di macchine virtuali (VM), non sulla rete. Di conseguenza, il mirroring pacchetto consuma una larghezza di banda aggiuntiva sulle VM.

Il mirroring dei pacchetti è utile quando devi monitorare e analizzare il tuo stato di sicurezza. Esporta tutto il traffico, non solo quello tra periodi di campionamento. Ad esempio, puoi utilizzare un 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, devi 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, tutte le istanze esistenti e future in quella subnet vengono sottoposte a mirroring. Puoi specificare uno o più tipi di origine: se un'istanza corrisponde ad almeno uno di questi, in modo speculare.

  Il mirroring dei pacchetti raccoglie il traffico dall'interfaccia di rete di un'istanza nella rete in cui si applica il criterio di mirroring dei pacchetti. Se un'istanza ha più interfacce di rete, le altre interfacce non vengono sottoposte a mirroring, a meno che non sia 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 chiamate istanze collector.

  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 bilanciatore del carico interno per il mirroring dei pacchetti è simile ad altri bilanciatori del carico interni, tranne per il fatto che la regola di inoltro deve essere configurata per il mirroring dei pacchetti. Tutto il traffico non sottoposto a mirroring inviato al bilanciatore del carico viene ignorato.

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 in modo da 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 i filtri per raccogliere il traffico in base al protocollo, agli intervalli CIDR (IPv4, IPv6 o entrambi), alla direzione del traffico (solo in entrata, solo in uscita o entrambe) o a una combinazione.

Ordine delle norme

A un'istanza possono essere applicati più criteri di mirroring dei pacchetti. La priorità di un criterio di mirroring dei pacchetti è sempre 1000 e non può essere modificata. I criteri identici non sono supportati. Google Cloud può inviare il traffico a uno qualsiasi dei bilanciatori del carico configurati con criteri di mirroring dei pacchetti identici. Per inviare traffico sottoposto a mirroring in modo prevedibile e coerente a un singolo bilanciatore del carico, crea criteri con filtri con intervalli di indirizzi non sovrapposti. 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 hai criteri distinti, Google Cloud utilizza il criterio corrispondente 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 con 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 protocolli sovrapposti: 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 corrispondente 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. In questo caso, Google Cloud potrebbe scegliere lo stesso criterio o un criterio diverso ogni volta che il traffico corrispondente viene rivalutato in base a questi criteri. Ti consigliamo di evitare di creare criteri di mirroring dei pacchetti identici.

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 Utilizzare i log di flusso VPC.

Proprietà chiave

Il seguente elenco descrive vincoli o comportamenti relativi al mirroring dei pacchetti che è importante comprendere prima di utilizzarlo:

• Ogni criterio di mirroring dei pacchetti definisce le origini sottoposte a mirroring e una destinazione del collettore. Devi rispettare le seguenti regole:

  • Tutte le origini sottoposte a mirroring devono trovarsi nello stesso progetto, nella stessa rete VPC e nella stessa regione Google Cloud.
  • Una destinazione del raccoglitore deve trovarsi nella stessa regione delle origini sottoposte a mirroring. Una destinazione del raccoglitore può trovarsi nella stessa rete VPC delle origini sottoposte a mirroring o in una rete VPC connessa alla rete delle origini sottoposte a mirroring tramite il peering di rete VPC.
  • Ogni criterio di mirroring può fare riferimento a una sola destinazione del collettore. Tuttavia, a una singola destinazione di raccoglitore possono essere utilizzati più e i criteri di mirroring.

• Tutti i protocolli di livello 4 sono supportati dal mirroring dei pacchetti.

• 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 intervallo CIDR di ::/0. Puoi eseguire il mirroring di tutto il traffico IPv4 e IPv6 utilizzando il seguente filtro intervallo CIDR separato da virgole:0.0.0.0/0,::/0.

• Il traffico con 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 dei pacchetti varia in base alla quantità di traffico in uscita che passa da un'istanza sottoposta a mirroring a un gruppo di istanze e se il traffico si sposta tra zone.

• 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. Ad esempio, puoi specificare 30 intervalli e 1 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 del mirroring dei pacchetti.

  Ti vengono addebitati anche tutti i componenti prerequisiti e il traffico in uscita correlati al mirroring dei pacchetti. Ad esempio, alle istanze che raccolgono il traffico viene addebitato il prezzo normale. Inoltre, se il traffico di mirroring dei pacchetti passa da una zona all'altra, ti viene addebitato il traffico in uscita. Per i dettagli sui prezzi, consulta la pagina dei prezzi correlata.

• 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 sezioni seguenti descrivono scenari reali che dimostrano perché potresti utilizzare il mirroring dei pacchetti.

Sicurezza aziendale

I team di sicurezza e di ingegneria di rete devono assicurarsi di rilevare tutte le anomalie e le minacce che potrebbero indicare violazioni della sicurezza e intrusioni. Essi rispecchiano tutto il traffico in modo da poter completare un'ispezione completa dei flussi sospetti. Poiché gli attacchi possono interessare più pacchetti, i team di sicurezza devono essere in grado di ricevere tutti i pacchetti per ogni flusso.

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

• Gli strumenti di sistema di rilevamento delle intrusioni (IDS) richiedono che più pacchetti di un singolo flusso corrispondano a una firma per poter rilevare le minacce persistenti.

• I motori di ispezione approfondita dei pacchetti ispezionano i payload dei pacchetti per rilevare anomalie del protocollo.

• L’analisi forense della rete per la conformità PCI e altri casi d’uso normativi richiedono per esaminare la maggior parte dei pacchetti. Il mirroring dei pacchetti fornisce una soluzione per acquisire diversi vettori di attacco, come la comunicazione infrequente o i 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 visualizzare cosa passa sulla rete anziché affidarsi ai log delle applicazioni.

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

• Analizzare i protocolli e i comportamenti in modo da trovare e risolvere i problemi, ad esempio la perdita di pacchetti o i reset TCP.

• Analizzare (in tempo reale) i modelli di traffico da desktop remoto, VoIP e altro applicazioni interattive. Gli ingegneri di rete possono cercare i problemi che interessano l'esperienza utente dell'applicazione, ad esempio più invii di pacchetti o più ricollegamenti 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.

Nel diagramma precedente, il criterio di mirroring dei pacchetti è configurato per eseguire il mirroringmirrored-subnet e inviare 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 reti VPC diverse inviano traffico sottoposto a mirroring a una destinazione del raccoglitore in una rete VPC centrale. In questo modo, puoi utilizzare un singolo raccoltore di destinazione.

Nel seguente esempio, il bilanciatore del carico di rete passthrough interno collector-load-balancer si trova nella regione us-central1 nella rete VPC network-a in project-a. Questo raccoglitore di destinazione può essere utilizzato da due criteri di mirroring dei pacchetti:

• policy-1 raccoglie i pacchetti dalle origini sottoposte a mirroring nella regione us-central1 nella rete VPC network-a in project-a e li invia alla destinazione collector-load-balancer.

• policy-2 raccoglie i pacchetti dalle origini sottoposte a mirroring nella regione us-central1 nella rete VPC network-b in project-b e li invia stessa destinazione collector-load-balancer.

Sono necessari due criteri di mirroring perché le origini sottoposte a mirroring esistono in reti VPC diverse.

Nel diagramma precedente, la destinazione del raccoglitore raccoglie il traffico sottoposto a mirroring da subnet in due reti diverse. Tutte le risorse (di origine e di destinazione) devono trovarsi nella stessa regione. La configurazione in network-a è simile all'esempio in cui l'origine sottoposta a mirroring e la destinazione del 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 emittenti si trovano in progetti diversi e potrebbero avere proprietari diversi. È possibile che entrambi i proprietari creino il criterio di mirroring dei pacchetti se dispongono delle autorizzazioni appropriate:

• Se i proprietari di project-a creano il criterio di mirroring dei pacchetti, devono avere il ruolo compute.packetMirroringAdmin sulla rete, sulla subnet o sulle istanze da 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 VPC condivisa, le istanze sottoposte a mirroring per la destinazione del raccoglitore si trovano tutte nella stessa rete VPC condivisa. Anche se le risorse si trovano tutte nella stessa rete, possono trovarsi in progetti diversi, ad esempio nel progetto host o in diversi progetti di servizi. Le seguenti esempi mostrano dove è necessario creare criteri di mirroring pacchetto e chi può creare che li rappresentano.

Se sia le origini sottoposte 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 a avere tutto 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.

Nel diagramma precedente, il progetto di servizio contiene le istanze del raccoglitore che utilizzano la subnet raccoglitore nella reteVPC condivisoa. Il criterio di mirroring dei pacchetti è stato creato nel progetto di servizio ed è configurato per eseguire il mirroring delle istanze 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 disporre del ruolo compute.packetMirroringUser nel progetto di servizio dove si trova la destinazione del raccoglitore. Gli utenti devono inoltre disporre del 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 sottoposte a 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 team di sicurezza o di networking centralizzato, che ha il controllo sul progetto host e sulla rete VPC condivisa, a essere responsabile del provisioning dei criteri di mirroring dei pacchetti.

Nel diagramma precedente, il criterio di mirroring dei pacchetti viene creato nel progetto host, dove si trova la destinazione del collettore. Il criterio è configurato su delle istanze nella subnet con mirroring. Le istanze VM nei progetti di servizio possono utilizzare la subnet sottoposta a mirroring e il loro traffico viene sottoposto a mirroring.

Gli utenti del servizio o del progetto host possono creare il criterio di mirroring pacchetto. Per farlo, gli utenti del progetto di servizio devono disporre del ruolo compute.packetMirroringUser nel progetto host. Gli utenti del progetto host richiedono il ruolo compute.packetMirroringAdmin per le origini sottoposte a mirroring nei progetti di servizio.

Istanze VM con più interfacce

Puoi includere in un pacchetto istanze VM con più interfacce di rete di mirroring. 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 devi eseguire il mirroring di più interfacce di rete di un'istanza con più interfacce di rete, devi creare un criterio di mirroring dei pacchetti per ogni interfaccia perché ogni interfaccia si connette a una rete VPC univoca.

Passaggi successivi

• Per creare e gestire i criteri di mirroring pacchetto, vedi Utilizzare il mirroring pacchetto.
• Per visualizzare le metriche e controllare i criteri di mirroring dei pacchetti esistenti, consulta Monitorare il mirroring dei pacchetti.
• Per informazioni sui bilanciatori del carico di rete passthrough interni, vedi Panoramica del bilanciatore del carico di rete passthrough interno.
• Per un elenco dei fornitori partner, vedi Partner Mirroring pacchetto di terze parti.