Mirroring pacchetto

Questa pagina fornisce una panoramica di Mirroring pacchetto nella rete Virtual Private Cloud (VPC). Se vuoi analizzare il traffico di rete dei tuoi carichi di lavoro su larga scala e monitorare il traffico di rete utilizzando appliance virtuali di terze parti, utilizza il mirroring dei pacchetti di integrazione della sicurezza di rete. Per saperne di più, consulta la Panoramica dell'integrazione out-of-band.

Mirroring pacchetto clonare il traffico delle istanze specificate nella rete VPC e inoltrarlo per l'esame. Mirroring pacchetto acquisisce tutto il traffico e i dati dei pacchetti, inclusi payload e intestazioni. L'acquisizione può essere configurata per il traffico in uscita e in entrata, solo per il traffico in entrata o solo per il traffico in uscita.

Il mirroring avviene sulle istanze di macchine virtuali (VM), non sulla rete. Di conseguenza, il mirroring pacchetto consuma ulteriore larghezza di banda sulle VM.

Mirroring pacchetto è utile quando devi monitorare e analizzare lo 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 il flusso di traffico completo per rilevare problemi di prestazioni dell'applicazione. Per saperne di più, consulta gli esempi di casi d'uso.

Come funziona

Mirroring pacchetto copia il traffico dalle origini sottoposte a mirroring e lo invia a una destinazione di raccolta. Per configurare il mirroring pacchetto, crea un criterio di mirroring pacchetto che specifica l'origine e la destinazione.

• Le origini sottoposte a mirroring sono istanze VM di Compute Engine che puoi selezionare specificando subnet, tag di rete o nomi delle istanze. Se specifichi una subnet, vengono sottoposte a mirroring 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, viene replicata.

  Mirroring pacchetto raccoglie il traffico dall'interfaccia di rete di un'istanza nella rete in cui si applica il criterio di mirroring dei pacchetti. Nei casi in cui 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 che si trova 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 il mirroring pacchetto è simile ad altri bilanciatori del carico interni, tranne per il fatto che la regola di forwarding deve essere configurata per il mirroring pacchetto. Tutto il traffico non sottoposto a mirroring inviato al bilanciatore del carico viene eliminato.

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 entrambi) o a una combinazione.

Ordine di applicazione 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. Le policy identiche non sono supportate. Google Cloud può inviare traffico a uno qualsiasi dei bilanciatori del carico configurati con policy di mirroring dei pacchetti identiche. Per inviare il traffico sottoposto a mirroring in modo prevedibile e coerente a un singolo bilanciatore del carico, crea policy con filtri con intervalli di indirizzi non sovrapposti. Se gli intervalli si sovrappongono, imposta protocolli di filtro univoci.

A seconda del filtro di ogni norma, Google Cloud sceglie una norma per ogni flusso. Se disponi di policy distinte, Google Cloud utilizza la policy corrispondente che corrisponde al traffico sottoposto a mirroring. Ad esempio, potresti avere una norma con il filtro 198.51.100.3/24:TCP e un'altra norma con il filtro 2001:db8::/64:TCP:UDP. Poiché le norme sono distinte, non c'è ambiguità su quale norma Google Cloud utilizza.

Tuttavia, se hai policy sovrapposte, Google Cloud valuta i relativi filtri per scegliere quale utilizzare. Ad esempio, potresti avere due norme, una con un filtro per 10.0.0.0/24:TCP e un'altra per 10.0.0.0/16:TCP. Questi criteri si sovrappongono perché i loro intervalli CIDR si sovrappongono.

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

Google Cloud sceglie una norma in base a un filtro:

• Se le norme hanno intervalli CIDR diversi ma sovrapposti e gli stessi protocolli esatti, Google Cloud sceglie la norma 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 le policy specificano lo stesso intervallo CIDR esatto con protocolli sovrapposti, Google Cloud sceglie una policy 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 la corrispondenza del traffico TCP, Google Cloud utilizza il criterio 10.240.1.0/24:TCP. Le norme 10.240.1.0/24:ALL si applicano al traffico corrispondente per tutti gli altri protocolli.

• Se i criteri hanno lo stesso intervallo CIDR esatto, ma protocolli distinti, questi 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. A seconda del protocollo del traffico sottoposto a mirroring, Google Cloud utilizza il criterio TCP o UDP.

• Se i criteri sovrapposti hanno esattamente lo stesso filtro, sono identici. In questo caso, Google Cloud potrebbe scegliere la stessa norma o una norma diversa ogni volta che il traffico corrispondente viene rivalutato in base a queste norme. 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 collettore, il flusso viene registrato.

Per saperne di più sui log di flusso VPC, consulta Utilizzo dei log di flusso VPC.

Proprietà chiave

Il seguente elenco descrive i vincoli o i comportamenti di 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 Google Cloud regione.
  • Una destinazione del raccoglitore deve trovarsi nella stessa regione delle origini sottoposte a mirroring. Una destinazione 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 raccoglitore. Tuttavia, una singola destinazione del collettore può essere referenziata da più policy di mirroring.

• Tutti i protocolli di livello 4 sono supportati da 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 abilitare 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 di cui vuoi eseguire il mirroring. Puoi eseguire il mirroring di tutto il traffico IPv6 utilizzando un filtro dell'intervallo CIDR di ::/0. Puoi eseguire il mirroring di tutto il traffico IPv4 e IPv6 utilizzando il seguente filtro dell'intervallo CIDR separato da virgole: 0.0.0.0/0,::/0.

• Il mirroring del traffico 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 servizio Mirroring pacchetto varia in base alla quantità di traffico in uscita che si sposta 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 istanze VM sottoposte a mirroring inviano traffico l'una all'altra, Google Cloud raccoglie due versioni dello stesso pacchetto. Puoi modificare questo comportamento specificando che vengono sottoposti a mirroring solo i pacchetti in entrata o solo quelli in uscita.

• Esiste un numero massimo di criteri di mirroring dei pacchetti che puoi creare per un progetto. Per saperne di più, 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, che corrispondono a 30 filtri. Tuttavia, non puoi specificare 30 intervalli e 2 protocolli, che corrispondono a 60 filtri e superano il massimo.

• Il traffico di cui è stato eseguito il mirroring viene criptato solo se la VM cripta il traffico a 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 ingegneria della sicurezza e della rete devono assicurarsi di rilevare tutte le anomalie e le minacce che potrebbero indicare violazioni e intrusioni della sicurezza. Eseguono il mirroring di tutto il traffico per poter completare un'ispezione completa dei flussi sospetti. Poiché 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 l'acquisizione di più pacchetti:

• Gli strumenti del sistema di rilevamento delle intrusioni (IDS) richiedono più pacchetti di un singolo flusso per corrispondere a una firma, in modo che gli strumenti possano rilevare 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 l'esame della maggior parte dei pacchetti. Mirroring pacchetto fornisce una soluzione per acquisire diversi vettori di attacco, come comunicazioni poco frequenti o tentativi di comunicazione senza esito.

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 i dati trasmessi via cavo anziché fare affidamento sui log delle applicazioni.

Ad esempio, gli ingegneri di rete possono utilizzare i dati di Mirroring pacchetto per completare le seguenti attività:

• Analizza i protocolli e i comportamenti in modo da poter trovare e risolvere problemi come la perdita di pacchetti o i ripristini TCP.

• Analizza (in tempo reale) i pattern di traffico da desktop remoto, VoIP e altre applicazioni interattive. Gli ingegneri di rete possono cercare problemi che influiscono sull'esperienza utente dell'applicazione, ad esempio più ritrasmissioni di pacchetti o più riconnessioni del previsto.

Topologie di destinazione del raccoglitore di esempio

Puoi utilizzare il mirroring pacchetto in varie configurazioni. Gli esempi seguenti mostrano la posizione delle destinazioni raccoglitore e le relative policy per diverse configurazioni di mirroring pacchetto, come il peering di rete VPC e VPC condiviso.

Destinazione raccoglitore nella stessa rete

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

Nel diagramma precedente, la norma di mirroring dei pacchetti è configurata per eseguire il mirroring di mirrored-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 subnet. Viene eseguito il mirroring di tutto il traffico da e verso internet, host on-premise o servizi Google.

Destinazione raccoglitore in una rete peer

Puoi creare un modello di raccoglitore centralizzato, in cui le istanze in diverse reti VPC inviano il traffico sottoposto a mirroring a una destinazione raccoglitore in una rete VPC centrale. In questo modo, puoi utilizzare un unico raccoglitore di destinazioni.

Nell'esempio seguente, 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 pacchetto:

• 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 alla stessa destinazione collector-load-balancer.

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

Nel diagramma precedente, la destinazione raccoglitore raccoglie il traffico sottoposto a mirroring dalle subnet in due reti diverse. Tutte le risorse (l'origine e la destinazione) devono trovarsi nella stessa regione. La configurazione in network-a è simile all'esempio in cui l'origine sottoposta a mirroring e la destinazione 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 origine mirror. Poiché network-a e network-b sono in peering, il raccoglitore di destinazione può raccogliere il traffico da subnet-b.

Le reti si trovano in progetti diversi e potrebbero avere proprietari diversi. È possibile che uno dei due proprietari crei il criterio di mirroring pacchetto se dispone delle autorizzazioni giuste:

• Se i proprietari di project-a creano il criterio di mirroring pacchetto, devono disporre del 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 disporre del ruolo compute.packetMirroringUser in project-a.

Per ulteriori informazioni sull'attivazione della 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 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 servizio. Gli esempi seguenti mostrano dove devono essere create le policy di mirroring dei pacchetti e chi può crearle.

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

Per maggiori informazioni, consulta la panoramica del VPC condiviso.

Destinazione raccoglitore nel progetto di servizio

Nell'esempio seguente, la destinazione del collettore si trova in un progetto di servizio che utilizza una subnet nel progetto host. In questo caso, le norme si trovano anche nel 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 del raccoglitore nella reteVPC condivisoa. Il criterio di mirroring pacchetto è stato creato nel progetto di servizio ed è configurato per eseguire il mirroring delle istanze che hanno un'interfaccia di rete in subnet-mirrored.

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

Destinazione raccoglitore nel progetto host

Nell'esempio seguente, la destinazione del collettore 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 in progetti di servizio e utilizzano la rete VPC condiviso. Non devono gestire l'infrastruttura di rete oMirroring pacchettoo. Un team di rete o di sicurezza centralizzato, che ha il controllo del progetto host e della rete VPC condiviso, è responsabile del provisioning dei criteri di mirroring dei pacchetti.

Nel diagramma precedente, il criterio di mirroring dei pacchetti viene creato nel progetto host, in cui si trova la destinazione del collettore. La policy è configurata per replicare le istanze nella subnet sottoposta a 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 progetto di servizio o 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 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 una policy di mirroring dei pacchetti per ogni interfaccia, perché ogni interfaccia si connette a una rete VPC unica.

Prezzi

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

Ti vengono addebitati anche tutti i componenti prerequisiti e il traffico in uscita correlati alMirroring pacchettoi. Ad esempio, le istanze che raccolgono il traffico vengono addebitate alla tariffa normale. Inoltre, se il traffico di mirroring dei pacchetti si sposta tra le zone, ti viene addebitato il traffico in uscita. Per i dettagli sui prezzi, consulta la pagina dei prezzi correlata.

Passaggi successivi

• Utilizza il mirroring pacchetto.
• Monitora il mirroring pacchetto.
• Panoramica del bilanciatore del carico di rete passthrough interno.
• Provider partner del mirroring pacchetto.
• Panoramica sull'integrazione fuori banda.