Mirroring pacchetto

Questa pagina è una panoramica del servizio 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 i payload e le intestazioni. L'acquisizione può essere configurata per entrambi i tipi di traffico, 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 larghezza di banda aggiuntiva sulle VM.

Mirroring pacchetto è utile quando è necessario monitorare e analizzare lo 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 eventuali anomalie. Inoltre, puoi ispezionare l'intero flusso di traffico per rilevare problemi di prestazioni delle applicazioni. Per ulteriori informazioni, consulta gli esempi di casi d'uso.

Come funziona

Mirroring pacchetto copia il traffico dalle origini con mirroring e lo invia a una destinazione raccoglitore. Per configurare il mirroring pacchetto, devi creare un criterio di mirroring pacchetto che specifichi 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 delle istanze. Se specifichi una subnet, viene eseguito il mirroring di tutte le istanze esistenti e future al suo interno. Puoi specificare uno o più tipi di origine: se un'istanza corrisponde ad almeno uno di questi, viene eseguito il mirroring.

    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 abbia 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 raccoglitore è un gruppo di istanze che si trova dietro un bilanciatore del carico interno. Le istanze nel gruppo di istanze sono definite 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, ad eccezione del 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.

Applicazione dei 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 di cui viene eseguito il 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 a protocollo, intervalli CIDR (IPv4, IPv6 o entrambi), direzione del traffico (solo in entrata, solo in uscita o entrambi) o una combinazione.

Ordine delle norme

A un'istanza possono essere applicati più criteri di mirroring pacchetto. La priorità di un criterio di mirroring pacchetto è sempre 1000 e non può essere modificata. Non sono supportati criteri identici. Google Cloud può inviare il traffico a qualsiasi bilanciatore del carico configurato con criteri di mirroring pacchetto identici. Per inviare in modo prevedibile e coerente il traffico sottoposto a mirroring a un singolo bilanciatore del carico, crea criteri che includano 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 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 criterio con il filtro 2001:db8::/64:TCP:UDP. Poiché i criteri sono distinti, non c'è ambiguità su quale criterio viene utilizzato da Google Cloud.

Tuttavia, se hai criteri che si sovrappongono, Google Cloud valuta i filtri per scegliere quale criterio 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é gli intervalli CIDR si sovrappongono.

Quando scegli un criterio, Google Cloud assegna la priorità ai criteri confrontando la dimensione dell'intervallo CIDR del 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 che lascia 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 che include il filtro 10.240.1.0/24:ALL.

  • Se i criteri specificano lo stesso esatto intervallo CIDR con protocolli che si sovrappongono, 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 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, questi criteri non si sovrappongono. Google Cloud usa 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 criteri che si sovrappongono hanno lo stesso filtro esatto, sono identici. In questo caso, Google Cloud potrebbe scegliere lo stesso criterio o uno diverso ogni volta che il traffico corrispondente viene rivalutato in base a questi criteri. Ti consigliamo di evitare di creare criteri di Mirroring pacchetto identici.

Log di flusso VPC

I log di flusso VPC non registrano i pacchetti sottoposti a mirroring. Se un'istanza del raccoglitore si trova su una subnet in cui sono abilitati i log di flusso VPC, viene registrato il traffico inviato direttamente all'istanza del raccoglitore, incluso quello proveniente dalle istanze sottoposte a mirroring. Ciò significa che se l'indirizzo IPv4 o IPv6 di destinazione originale corrisponde all'indirizzo IPv4 o IPv6 dell'istanza del raccoglitore, il flusso viene registrato.

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

Proprietà chiave

Nell'elenco seguente vengono descritti i vincoli o i comportamenti della funzionalità Mirroring pacchetto che è importante comprendere prima di utilizzarla:

  • Ogni criterio di Mirroring pacchetto definisce le origini con mirroring e una destinazione del raccoglitore. 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 utilizzando il peering di rete VPC.
    • Ogni criterio di mirroring può fare riferimento a una sola destinazione del raccoglitore. Tuttavia, più criteri di mirroring possono fare riferimento a una singola destinazione del raccoglitore.

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

  • Non puoi eseguire il mirroring e la raccolta del traffico sulla stessa interfaccia di rete di un'istanza VM, perché questa operazione causerebbe un loop di mirroring.

  • Per eseguire il mirroring del traffico tra i pod sullo stesso nodo di 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 per 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 nelle istanze è di 1 Gbps in entrata e 3 Gbps in uscita (1 Gbps di traffico normale in uscita e 2 Gbps di traffico in uscita sottoposto a mirroring). Per limitare il volume di traffico raccolto, puoi utilizzare i filtri.

  • Il costo di Mirroring pacchetto varia in base alla quantità di traffico in uscita che viaggia da un'istanza di cui è stato eseguito il mirroring a un gruppo di istanze e se il traffico si sposta tra zone.

  • Il mirroring pacchetto si applica sia alla direzione in entrata che in uscita. Se due istanze VM di cui viene eseguito il 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 in uscita.

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

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

    • 5 subnet
    • 5 tag
    • 50 istanze

  • Il numero massimo di filtri di mirroring pacchetto è 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 e maggiore del limite massimo.

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

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

  • Il traffico sottoposto a mirroring viene criptato solo se la VM cripta il traffico al livello dell'applicazione. Mentre le connessioni da VM a VM all'interno delle reti VPC e delle reti VPC in peering sono criptate, la crittografia e la decriptazione 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é potresti utilizzare Mirroring pacchetto.

Sicurezza aziendale

I team di sicurezza e di tecnici di rete devono assicurarsi di rilevare tutte le anomalie e le minacce che potrebbero indicare violazioni della sicurezza e intrusioni. Esegui il mirroring di tutto il traffico in modo da 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 ricevere 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 abbinare una firma, in modo che gli strumenti possano rilevare le minacce persistenti.

  • I motori Deep Packet Inspection ispezionano i payload dei pacchetti per rilevare anomalie di protocollo.

  • Le analisi forensi della rete per la conformità PCI e altri casi d'uso normativi richiedono l'esame della maggior parte dei pacchetti. Mirroring pacchetto offre una soluzione per acquisire diversi vettori di attacco, come comunicazioni non frequenti o comunicazioni tentate ma non riuscite.

Monitoraggio delle prestazioni delle applicazioni

I tecnici di rete possono utilizzare il traffico con 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 vedere cosa va oltre il cavo anziché fare affidamento sui log delle applicazioni.

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

  • Analizzare protocolli e comportamenti in modo che possano individuare e risolvere problemi, come la perdita di pacchetti o le reimpostazioni TCP.

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

Esempio di topologie di destinazione del raccoglitore

Puoi utilizzare Mirroring pacchetto in diverse configurazioni. I seguenti esempi mostrano la località delle destinazioni dei raccoglitori e i relativi criteri per diverse configurazioni di mirroring pacchetto, come peering di rete VPC e 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 sottoposte a mirroring si trovano nella stessa rete VPC.

Nel diagramma precedente, il criterio di mirroring pacchetto è configurato per eseguire il mirroring mirrored-subnet e l'invio del 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 del raccoglitore in una rete peer

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

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 con 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 con mirroring nella regione us-central1 nella rete VPC network-b in project-b e li invia alla stessa destinazione collector-load-balancer.

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

Nel diagramma precedente, la destinazione del raccoglitore raccoglie il traffico sottoposto a mirroring dalle subnet in due reti diverse. Tutte le risorse (origine e 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 con mirroring. Poiché network-a e network-b sono in peering, il raccoglitore di destinazione può raccogliere 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 dispongono delle autorizzazioni corrette:

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

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

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

VPC condiviso

Nei seguenti scenari di VPC condiviso, 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 il progetto host o più progetti di servizio diversi. I seguenti esempi mostrano dove è necessario creare i criteri di Mirroring pacchetto 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 alla presenza di tutto nella stessa rete VPC. Il proprietario del progetto può creare tutte le risorse e impostare le autorizzazioni richieste in quel progetto.

Per ulteriori informazioni, consulta 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 si trova 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 rete VPC condiviso. Il criterio di mirroring dei pacchetti è 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 servizio o del progetto host possono creare il criterio di Mirroring pacchetto. A questo scopo, gli utenti devono avere il ruolo compute.packetMirroringUser nel progetto di servizio in cui si trova la destinazione del raccoglitore. Gli utenti devono disporre anche del ruolo compute.packetMirroringAdmin per le 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 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 networking né Mirroring pacchetto. Invece, un team di networking o sicurezza centralizzato, che ha il controllo sul progetto host e sulla rete VPC condiviso, è responsabile del provisioning dei criteri di mirroring dei pacchetti.

Nel diagramma precedente, il criterio di Mirroring pacchetto viene creato nel progetto host, in cui si trova la destinazione del raccoglitore. Il criterio è configurato per eseguire il mirroring delle istanze nella subnet con mirroring. Le istanze VM nei progetti di servizio possono utilizzare la subnet con mirroring e il relativo traffico viene sottoposto a mirroring.

Gli utenti del servizio o del progetto host possono creare il criterio di Mirroring pacchetto. A questo scopo, gli utenti nel progetto di servizio devono avere il ruolo compute.packetMirroringUser nel progetto host. Gli utenti nel 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 da una singola rete, non puoi creare un unico criterio per eseguire il mirroring del traffico per tutte le interfacce di rete di un'istanza. Se devi eseguire il mirroring di più di un'interfaccia di rete di un'istanza di interfacce di rete multiple, devi creare un criterio di mirroring pacchetto per ogni interfaccia, poiché ogni interfaccia si connette a una rete VPC univoca.

Passaggi successivi