Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Mirroring pacchetto

Questa pagina offre una panoramica di Mirroring pacchetto.

Mirroring pacchetto clona il traffico delle istanze specificate nella rete Virtual Private Cloud (VPC) e lo inoltra per sottoporlo a 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 entrata e in uscita, solo per quello in entrata o solo in uscita.

Il mirroring avviene sulle istanze di macchine virtuali (VM), non sulla rete. Di conseguenza, 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 il traffico tra periodi di campionamento. Ad esempio, potete 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 del traffico per rilevare problemi di prestazioni dell'applicazione. Per saperne di più, consulta gli casi d'uso di esempio.

Come funziona

Mirroring pacchetto copia il traffico da 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, tutte le istanze esistenti e future vengono sottoposte a mirroring. Puoi specificare uno o più tipi di origine: se un'istanza corrisponde ad almeno uno di questi, verrà sottoposta a 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 dietro un bilanciatore del carico interno. Le istanze nel gruppo di istanze sono definite istanze raccoglitore.

    Quando specifichi la destinazione del raccoglitore, inserisci il nome di una regola di forwarding associata al bilanciatore del carico TCP/UDP interno. Google Cloud inoltra il traffico sottoposto a mirroring alle istanze del raccoglitore. Un bilanciatore del carico interno per il servizio Mirroring pacchetto è simile ad altri bilanciatori del carico interni, ad eccezione del fatto che è necessario configurare la regola di forwarding per il mirroring pacchetto. Tutto il traffico non sottoposto a mirroring viene inviato al bilanciatore del carico.

Filtri

Per impostazione predefinita, Mirroring pacchetto raccoglie tutto il traffico delle istanze sottoposte a mirroring. Anziché raccogliere tutto il traffico, puoi utilizzare i filtri per limitare il traffico sottoposto a mirroring. L'uso dei filtri può aiutarti a limitare l'utilizzo della larghezza di banda sulle istanze sottoposte a mirroring.

Puoi configurare filtri per raccogliere traffico in base a protocollo, intervalli di indirizzi IP, direzione del traffico (solo traffico in entrata, solo in uscita o entrambi) o una combinazione.

Ordine 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. I criteri identici non sono supportati. Google Cloud può inviare 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 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 criterio con il filtro 203.0.113.2/24:UDP. Poiché i criteri sono diversi, non esiste alcuna ambiguità in merito al criterio utilizzato da Google Cloud.

Tuttavia, in caso di criteri sovrapposti, Google Cloud valuta i propri 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é i rispettivi intervalli CIDR si sovrappongono.

Quando scegli un criterio, Google Cloud dà la priorità ai criteri confrontando le dimensioni 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 di indirizzi IP più specifico. Supponiamo che la destinazione di un pacchetto TCP che lascia un'istanza con mirroring sia 10.240.1.4 e che esistano due criteri con i filtri seguenti: 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 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 la corrispondenza del traffico TCP, 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 ma protocolli distinti, questi criteri non si sovrappongono. Google Cloud utilizza il criterio corrispondente al protocollo del traffico sottoposto a mirroring. Ad esempio, potresti avere un criterio per 10.240.1.0/24:TCP e un altro per 10.240.1.0/24: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 pacchetto identici.

Log di flusso VPC

I log di flusso VPC non registrano i pacchetti sottoposti a mirroring. Se un'istanza di raccoglitore si trova su una subnet in cui sono abilitati i log di flusso VPC, il traffico inviato direttamente all'istanza di raccoglitore viene registrato, incluso il traffico proveniente da istanze sottoposte a mirroring. In altre parole, se l'indirizzo IP di destinazione originale corrisponde all'indirizzo IP dell'istanza del raccoglitore, il flusso viene registrato.

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

Proprietà principali

Di seguito sono riportati i vincoli o i comportamenti relativi a Mirroring pacchetto che è importante comprendere prima dell'uso:

  • Ogni criterio di Mirroring pacchetto definisce le origini sottoposte a mirroring e una destinazione raccoglitore. Devi rispettare le seguenti regole:

    • Tutte le origini sottoposte a mirroring devono trovarsi nello stesso progetto, nella stessa rete VPC e nella stessa area geografica Google Cloud.
    • La destinazione di un 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 utilizzando il peering di rete VPC.
    • Ogni criterio di mirroring può fare riferimento a una sola destinazione raccoglitore. Tuttavia, una singola destinazione del raccoglitore può essere utilizzata come riferimento da più criteri di mirroring.
  • Tutti i protocolli di livello 4 su IPv4 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.

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

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

  • Mirroring pacchetto si applica sia in direzione di traffico in entrata che in uscita. Se due 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 viene eseguito il mirroring solo dei pacchetti in entrata o in uscita.

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

  • Per ogni criterio di Mirroring pacchetto, 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 per il mirroring pacchetto è 30, ovvero il numero di intervalli di indirizzi IP moltiplicati per il numero di protocolli. Ad esempio, puoi specificare 30 intervalli e 1 protocollo, che corrisponde a 30 filtri. Tuttavia, non puoi specificare 30 intervalli e 2 protocolli, per i quali i filtri sono 60 e superiori al 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 dei prerequisiti e il traffico in uscita relativi a Mirroring pacchetto. Ad esempio, le istanze che raccolgono traffico ricevono l'addebito alla tariffa normale. Inoltre, se il mirroring del pacchetto viaggia tra le zone, ti viene addebitato il traffico in uscita. Per i dettagli sui prezzi, consulta la relativa pagina dei prezzi.

  • Il traffico con mirroring viene criptato solo se la VM cripta quel traffico a livello di 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 vengono eseguite negli hypervisor. Dal punto di vista della VM, questo traffico non è criptato.

Casi d'uso

Le seguenti sezioni descrivono gli scenari reali che dimostrano il motivo per cui potresti utilizzare Mirroring pacchetto.

Sicurezza aziendale

I team di sicurezza e progettazione della rete devono assicurarsi di rilevare tutte le anomalie e le minacce che potrebbero indicare violazioni della sicurezza e intrusioni. 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 ottenere tutti i pacchetti per ciascun flusso.

Ad esempio, i seguenti strumenti di sicurezza richiedono di acquisire 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 possano rilevare le minacce permanenti.

  • I motori Deep Packet Inspection controllano i payload dei pacchetti per rilevare le anomalie del protocollo.

  • La network forensics per la conformità PCI e altri casi d'uso normativi richiede l'esame della maggior parte dei pacchetti. Mirroring pacchetto fornisce una soluzione per l'acquisizione di vettori di attacco diversi, come una comunicazione non frequente o una comunicazione tentata, ma non riuscita.

Monitoraggio delle prestazioni delle applicazioni

I tecnici di rete possono utilizzare il traffico con mirroring per risolvere i problemi di prestazioni segnalati dai team addetti alle applicazioni e al database. Per verificare la presenza di problemi di rete, i tecnici della rete possono visualizzare i problemi oltre il totale, anziché affidarsi ai log delle applicazioni.

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

  • Analizza protocolli e comportamenti in modo che possano trovare e risolvere i problemi, come la perdita di pacchetti o il reset TCP.

  • Analizza in tempo reale i pattern di traffico da desktop remoto, VoIP e altre applicazioni interattive. I tecnici di rete possono cercare i problemi che influiscono sull'esperienza utente dell'applicazione, ad esempio più invii di pacchetti o più connessioni del previsto.

Esempio di topologie di destinazione del raccoglitore

Puoi utilizzare Mirroring pacchetto in varie configurazioni. Gli esempi seguenti mostrano la località delle destinazioni raccoglitore e i relativi criteri per diverse configurazioni di mirroring pacchetto, come peering di rete VPC e VPC condiviso.

Destinazione raccoglitore nella stessa rete

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

Nel diagramma precedente, il criterio di Mirroring pacchetto è configurato per eseguire il mirroring di mirrored-subnet e inviare il traffico sottoposto a mirroring al bilanciatore del carico TCP/UDP 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 di raccoglitore in una rete VPC centrale. In questo modo, puoi utilizzare un solo raccoglitore destinazione.

Nel seguente esempio, il bilanciatore del carico TCP/UDP interno collector-load-balancer si trova nell'area geografica 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 necessari due criteri di mirroring perché esistono origini sottoposte a mirroring 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 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 origine sottoposta a mirroring. 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 per entrambi i proprietari 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, nella subnet o nelle 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 saperne di più sull'attivazione della connettività privata in due reti VPC, consulta peering di rete VPC.

VPC condiviso

Nei seguenti scenari di VPC condiviso, le istanze sottoposte a mirroring per la destinazione 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 servizio. I seguenti esempi mostrano dove devono essere creati i criteri di mirroring pacchetto e chi può crearli.

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

Per saperne di più, consulta Condivisione di VPC condivisa.

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 è anche nel progetto di servizio. Il criterio potrebbe anche trovarsi 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 pacchetto è stato creato nel progetto di servizio ed è configurato in modo da eseguire il mirroring delle istanze che hanno un'interfaccia di rete in subnet-mirrored.

Gli utenti del progetto host o di servizio 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 avere il 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 applicarsi a scenari in cui gli sviluppatori eseguono il deployment di applicazioni in progetti di servizio e utilizzano la rete VPC condiviso. Non deve gestire l'infrastruttura di networking o Mirroring pacchetto. Un team di rete o di sicurezza centralizzato, che ha il controllo sul progetto host e sulla rete VPC condivisa, è responsabile del provisioning dei criteri di mirroring pacchetto.

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

Gli utenti del progetto host o di servizio possono creare il criterio di Mirroring pacchetto. Per farlo, 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 che hanno più interfacce di rete in un criterio di mirroring pacchetto. 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'istanza. Se devi eseguire il mirroring di più di un'interfaccia di rete di un'istanza di interfaccia di rete, devi creare un criterio di Mirroring pacchetto per ogni interfaccia, in quanto ogni interfaccia si connette a una rete VPC univoca.

Passaggi successivi