Mirroring pacchetto

Questa pagina fornisce una panoramica del Mirroring pacchetto.

Mirroring pacchetto clona il traffico delle istanze specificate nella rete VPC (Virtual Private Cloud) e lo inoltra per l'esame. Mirroring pacchetto acquisisce tutto il traffico e i dati dei pacchetti, inclusi payload e intestazioni. La cattura può essere configurata sia per il traffico in entrata sia per quello in uscita, solo per il traffico in entrata o solo per quello 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.

Mirroring pacchetto è utile quando devi monitorare e analizzare il tuo stato di sicurezza. Esporta tutto il traffico, non solo quello tra i 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 l'intero flusso di traffico per rilevare problemi di prestazioni dell'applicazione. Per ulteriori informazioni, consulta i casi d'uso di esempio.

Come funziona

Mirroring pacchetto copia il traffico dalle origini sottoposte a mirroring e lo invia a una destinazione del collettore. Per configurare Mirroring pacchetto, devi creare un criterio di mirroring dei pacchetti che specifichi l'origine e la destinazione.

• Le origini sottoposte a mirroring sono istanze VM di Compute Engine che puoi selezionare specificando sottoreti, 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 a almeno uno di questi, viene duplicata.

  Mirroring pacchetto 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 per farlo.

• Una destinazione del raccoglitore è un gruppo di istanze dietro un bilanciatore del carico interno. Le istanze nel gruppo di istanze sono chiamate istanze collector.

  Quando specifichi la destinazione del raccoglitore, inserisci il nome di una regola di forwarding associata al bilanciatore del carico di rete passthrough interno. Google Cloud inoltra quindi il traffico sottoposto a mirroring alle istanze del raccoglitore. Un bilanciatore del carico interno per Mirroring pacchetto è simile ad altri bilanciatori del carico interni, tranne per il fatto che la regola di forwarding deve essere configurata per Mirroring pacchetto. 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 delle istanze sottoposte a mirroring. 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 utilizzare i filtri per restringere il traffico sottoposto a mirroring, il che può aiutarti a limitare la larghezza di banda utilizzata dalle istanze sottoposte a 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 ogni criterio, Google Cloud sceglie un criterio per ogni flusso. 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à su quale criterio utilizzi Google Cloud.

Tuttavia, se hai criteri in sovrapposizione, Google Cloud valuta i relativi filtri per scegliere quale utilizzare. Ad esempio, potresti avere due criteri, 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 relativi intervalli CIDR si sovrappongono.

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

Google Cloud sceglie un criterio in base a un filtro:

• Se i criteri hanno intervalli CIDR diversi ma sovrapposti e gli stessi protocolli esatti, Google Cloud sceglie il criterio che utilizza l'intervallo CIDR più specifico. Supponiamo che la destinazione di un pacchetto TCP in uscita da un'istanza sottoposta a mirroring sia 10.240.1.4 e che esistano due criteri con i 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 intervallo CIDR esatto 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 il traffico TCP corrispondente, 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 intervallo CIDR esatto, ma protocolli distinti, 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. A seconda del protocollo del traffico sottoposto a mirroring, Google Cloud utilizza il criterio TCP o UDP.

• Se i criteri sovrapposti hanno lo stesso filtro esatto, sono identici. 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 sottoposti a mirroring. Se un'istanza del raccoglitore si trova in una subnet in cui sono abilitati i log di flusso VPC, il traffico inviato direttamente all' istanza del raccoglitore viene registrato, incluso il traffico proveniente dalle istanze sottoposte a mirroring. ovvero, se l'indirizzo IPv4 o IPv6 di destinazione originale corrisponde all'indirizzo IPv4 o IPv6 dell'istanza del collector, 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 pacchetto 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.
  • La destinazione di un 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 del collettore possono fare riferimento più criteri di mirroring.

• Tutti i protocolli di livello 4 sono supportati dal Mirroring pacchetto.

• Non puoi eseguire il mirroring e raccogliere il traffico sulla stessa interfaccia di rete di un'istanza VM perché ciò causerebbe un loop di mirroring.

• Per eseguire il mirroring del traffico che passa tra i pod sullo stesso nodo Google Kubernetes Engine (GKE), devi attivare la visibilità tra nodi per il cluster.

• Per eseguire il mirroring del traffico IPv6, utilizza i filtri per specificare gli intervalli CIDR IPv6 del traffico IPv6 che 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 sottoposta a mirroring registra 1 Gbps di traffico in entrata e 1 Gbps di traffico in uscita, il traffico totale sulle istanze è di 1 Gbps in entrata e 3 Gbps in uscita (1 Gbps di traffico in uscita normale e 2 Gbps di traffico in uscita sottoposto a mirroring). Per limitare il traffico raccolto, puoi utilizzare i filtri.

• Il costo del Mirroring pacchetto 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 sia a quella in uscita. Se due istanze VM sottoposte a mirroring si inviano traffico tra loro, Google Cloud raccoglie due versioni dello stesso pacchetto. Puoi modificare questo comportamento specificando che solo i pacchetti in entrata o in uscita devono essere specchiati.

• Esiste un numero massimo di criteri di mirroring dei pacchetti che puoi creare per un progetto. Per ulteriori informazioni, consulta le quote per progetto nella pagina Quote.

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

  • 5 subnet
  • 5 tag
  • 50 istanze

• Il numero massimo di filtri di mirroring dei pacchetti è 30, ovvero il numero di intervalli di indirizzi IPv4 e IPv6 moltiplicato per il numero di protocolli. Ad esempio, puoi specificare 30 intervalli e 1 protocollo, ovvero 30 filtri. Tuttavia, non puoi specificare 30 intervalli e 2 protocolli, ovvero 60 filtri, che è superiore al numero 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 pacchetto. 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 a livello di livello di applicazione. Sebbene le connessioni da VM a VM all'interno delle reti VPC e delle reti VPC in peering siano criptate, 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 Mirroring pacchetto.

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ù 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.

• La forensistica di rete per la conformità PCI e altri casi d'uso normativi richiedono l'esame della maggior parte dei pacchetti. Mirroring pacchetto 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

Gli ingegneri di rete possono utilizzare il traffico sottoposto a mirroring per risolvere i problemi di prestazioni segnalati dai team di applicazioni e database. Per verificare la presenza di problemi di rete, gli ingegneri di rete possono visualizzare cosa viene trasmesso tramite cavo anziché affidarsi ai log delle applicazioni.

Ad esempio, gli ingegneri di rete possono utilizzare i dati del 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.

• Analizza (in tempo reale) i pattern di traffico da desktop remoto, VoIP e altre applicazioni interactive. Gli ingegneri di rete possono cercare i problemi che interessano l'esperienza utente dell'applicazione, ad esempio più reinvio 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 collezionisti e i relativi criteri per diverse configurazioni di mirroring dei pacchetti, come il peering di rete VPC e VPC condiviso.

Destinazione del raccoglitore nella stessa rete

L'esempio seguente mostra una configurazione di mirroring dei pacchetti in cui l'origine e la destinazione del raccoglitore sottoposte a mirroring 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 nella sottorete. Viene eseguito il mirroring di tutto il traffico da e verso internet, gli host on-premise o i servizi Google.

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. policy-1 è configurato per raccogliere il traffico da subnet-a e inviarlo a collector-ilb.

policy-2 è configurato in project-a, ma specifica subnet-b come fonte specchiata. Poiché network-a e network-b sono in peering, il collector di destinazione 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 dei pacchetti, devono avere il ruolo compute.packetMirroringUser in project-a.

Per ulteriori informazioni su come attivare la connettività privata tra due reti VPC, consulta Peering di rete VPC.

VPC condiviso

Nei seguenti scenari VPC condiviso, le istanze sottoposte a mirroring per la destinazione del raccoglitore si trovano tutte nella stessa rete VPC condiviso. 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. Gli esempi riportati di seguito mostrano dove devono essere creati i criteri di mirroring dei pacchetti e chi può crearli.

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 proprietario del progetto può creare tutte le risorse e impostare le autorizzazioni richieste nel progetto.

Per ulteriori informazioni, consulta la 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, il criterio è presente anche nel progetto di servizio. Il criterio potrebbe trovarsi anche nel progetto host.

Nel diagramma precedente, il progetto di servizio contiene le istanze del collector che utilizzano la subnet del collector nella rete VPC condiviso. 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 progetto di servizio o host possono creare il criterio di mirroring dei pacchetti. 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 essere applicabile a scenari in cui gli sviluppatori eseguono il deployment di applicazioni nei progetti di servizio e utilizzano la rete VPC condiviso. Non devono gestire l'infrastruttura di rete o il Mirroring pacchetto. È invece un team di sicurezza o di networking centralizzato, che ha il controllo sul progetto host e sulla rete VPC condiviso, 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 per riflettere le istanze nella subnet replicata. 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 progetto di servizio o host possono creare il criterio di mirroring dei pacchetti. 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 multi-interfaccia

Puoi includere istanze VM con più interfacce di rete in un criterio di mirroring dei pacchetti. Poiché un criterio può eseguire il mirroring delle risorse di una singola rete, non puoi creare un criterio per eseguire il mirroring del traffico per tutte le interfacce di rete di un istanza. 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 dei pacchetti, consulta Utilizzare il mirroring dei pacchetti.
• 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, consulta Panoramica dei bilanciatori del carico di rete passthrough interni.
• Per un elenco di provider partner, consulta Provider partner del mirroring pacchetto.