Esta página se ha traducido con Cloud Translation API.

Replicación de paquetes

En esta página se ofrece una descripción general de la replicación de paquetes en la red de nube privada virtual (VPC). Si quieres analizar el tráfico de red de tus cargas de trabajo a gran escala y monitorizar el tráfico de red mediante dispositivos virtuales de terceros, usa la función de duplicación de paquetes de integración de seguridad de red. Para obtener más información, consulta el resumen de la integración fuera de banda.

Replicación de paquetes clona el tráfico de las instancias especificadas en tu red de VPC y lo reenvía para su análisis. La replicación de paquetes captura todo el tráfico y los datos de los paquetes, incluidas las cargas útiles y los encabezados. La captura se puede configurar para el tráfico de entrada y de salida, solo para el tráfico de entrada o solo para el tráfico de salida.

La creación de reflejos se produce en las instancias de máquina virtual (VM), no en la red. Por lo tanto, la replicación de paquetes consume ancho de banda adicional en las VMs.

Packet Mirroring es útil cuando necesitas monitorizar y analizar tu estado de seguridad. Exporta todo el tráfico, no solo el tráfico entre periodos de muestreo. Por ejemplo, puedes usar un software de seguridad que analice el tráfico reflejado para detectar todas las amenazas o anomalías. Además, puede inspeccionar el flujo de tráfico completo para detectar problemas de rendimiento de las aplicaciones. Para obtener más información, consulta los casos prácticos.

Cómo funciona

La replicación de paquetes copia el tráfico de las fuentes replicadas y lo envía a un destino de recogida. Para configurar la replicación de paquetes, cree una política de replicación de paquetes que especifique el origen y el destino.

Los orígenes replicados son instancias de VM de Compute Engine que puedes seleccionar especificando subredes, etiquetas de red o nombres de instancias. Si especificas una subred, se creará una imagen reflejada de todas las instancias actuales y futuras de esa subred. Puedes especificar uno o varios tipos de origen. Si una instancia coincide con al menos uno de ellos, se creará una réplica.

La replicación de paquetes recoge el tráfico de la interfaz de red de una instancia en la red en la que se aplica la política de replicación de paquetes. En los casos en los que una instancia tiene varias interfaces de red, las demás interfaces no se replican a menos que se haya configurado otra política para hacerlo.
Un destino de recopilador es un grupo de instancias que se encuentra detrás de un balanceador de carga interno. Las instancias del grupo de instancias se denominan instancias de recopilador.

Cuando especifiques el destino del recopilador, introduce el nombre de una regla de reenvío asociada al balanceador de carga de red de paso a través interno. Google Cloud reenvía el tráfico replicado a las instancias del recopilador. Un balanceador de carga interno para replicar paquetes es similar a otros balanceadores de carga internos, excepto que la regla de reenvío debe configurarse para replicar paquetes. Se descarta el tráfico que no sea reflejado y que se envíe al balanceador de carga.

Filtrado

De forma predeterminada, la replicación de paquetes recoge todo el tráfico IPv4 de las instancias replicadas. En lugar de recoger todo el tráfico IPv4, puede usar filtros para ampliar el tráfico recogido e incluir todo o parte del tráfico IPv6. También puede usar filtros para limitar el tráfico que se replica, lo que puede ayudarle a limitar el ancho de banda que usan las instancias replicadas.

Puede configurar filtros para recoger tráfico en función del protocolo, los intervalos de CIDR (IPv4, IPv6 o ambos), la dirección del tráfico (solo de entrada, solo de salida o ambos) o una combinación de estos criterios.

Orden de cumplimiento de políticas

Se pueden aplicar varias políticas de replicación de paquetes a una instancia. La prioridad de una política de creación de réplicas de paquetes siempre es 1000 y no se puede cambiar. No se admiten políticas idénticas. Google Cloud puede enviar tráfico a cualquiera de los balanceadores de carga que se hayan configurado con políticas de replicación de paquetes idénticas. Para enviar tráfico reflejado de forma predecible y coherente a un único balanceador de carga, cree políticas que tengan filtros con intervalos de direcciones que no se solapen. Si los intervalos se solapan, define protocolos de filtro únicos.

En función del filtro de cada política, Google Cloud elige una política para cada flujo. Si tienes políticas distintas, Google Cloud usa la política correspondiente que coincida con el tráfico replicado. Por ejemplo, puede que tengas una política con el filtro 198.51.100.3/24:TCP y otra con el filtro 2001:db8::/64:TCP:UDP. Como las políticas son distintas, no hay ambigüedad sobre qué política usa Google Cloud .

Sin embargo, si tienes políticas que se solapan, Google Cloud evalúa sus filtros para elegir qué política usar. Por ejemplo, puedes tener dos políticas: una con un filtro para 10.0.0.0/24:TCP y otra para 10.0.0.0/16:TCP. Estas políticas se solapan porque sus intervalos CIDR se solapan.

Al elegir una política, Google Cloud prioriza las políticas comparando el tamaño del intervalo CIDR de sus filtros.

Google Cloud elige una política en función de un filtro:

Si las políticas tienen intervalos CIDR diferentes, pero superpuestos, y los mismos protocolos, Google Cloud elige la política que usa el intervalo CIDR más específico. Supongamos que el destino de un paquete TCP que sale de una instancia replicada es 10.240.1.4 y que hay dos políticas con los siguientes filtros: 10.240.1.0/24:ALL y 10.240.0.0/16:TCP. Como la coincidencia más específica de 10.240.1.4 es 10.240.1.0/24:ALL,Google Cloud usa la política que tiene el filtro 10.240.1.0/24:ALL.
Si las políticas especifican el mismo intervalo CIDR exacto con protocolos superpuestos,Google Cloud elige la política con el protocolo más específico. Por ejemplo, los siguientes filtros tienen el mismo intervalo, pero protocolos superpuestos: 10.240.1.0/24:TCP y 10.240.1.0/24:ALL. Para que coincida con el tráfico TCP, Google Cloud usa la política 10.240.1.0/24:TCP. La política 10.240.1.0/24:ALL se aplica al tráfico coincidente de todos los demás protocolos.
Si las políticas tienen el mismo intervalo CIDR exacto, pero protocolos distintos, estas políticas no se solapan. Google Cloud usa la política que corresponde al protocolo del tráfico reflejado. Por ejemplo, puede tener una política para 2001:db8::/64:TCP y otra para 2001:db8::/64:UDP. En función del protocolo del tráfico reflejado, Google Cloud usa la política TCP o UDP.
Si las políticas superpuestas tienen el mismo filtro exacto, son idénticas. En este caso, Google Cloud puede elegir la misma política o una política diferente cada vez que se vuelva a evaluar el tráfico coincidente con respecto a estas políticas. Te recomendamos que evites crear políticas de duplicación de paquetes idénticas.

Registros de flujo de VPC

VPC Flow Logs no registra los paquetes replicados. Si una instancia de recogida está en una subred que tiene habilitados los registros de flujo de VPC, se registrará el tráfico que se envíe directamente a la instancia de recogida, incluido el tráfico de las instancias reflejadas. Es decir, si la dirección IPv4 o IPv6 de destino original coincide con la dirección IPv4 o IPv6 de la instancia del recopilador, el flujo se registra.

Para obtener más información sobre Registros de flujo de VPC, consulta el artículo Usar Registros de flujo de VPC.

Propiedades clave

En la siguiente lista se describen las restricciones o los comportamientos de la función de duplicación de paquetes que es importante conocer antes de usarla:

Cada política de replicación de paquetes define fuentes replicadas y un destino de recopilador. Debes cumplir las siguientes reglas:
- Todos los orígenes replicados deben estar en el mismo proyecto, la misma red VPC y la misma región. Google Cloud
- El destino del recopilador debe estar en la misma región que los orígenes replicados. Un destino del recopilador puede estar en la misma red VPC que los orígenes replicados o en una red VPC conectada a la red de los orígenes replicados mediante el emparejamiento entre redes de VPC.
- Cada política de creación de reflejo solo puede hacer referencia a un destino de recogida. Sin embargo, varias políticas de creación de reflejos pueden hacer referencia a un mismo destino de recopilador.
Packet Mirroring admite todos los protocolos de capa 4.
No puedes duplicar y recoger tráfico en la misma interfaz de red de una instancia de VM, ya que esto provocaría un bucle de duplicación.
Para replicar el tráfico que pasa entre pods del mismo nodo de Google Kubernetes Engine (GKE), debes habilitar la visibilidad intranodo en el clúster.
Para replicar el tráfico IPv6, utilice filtros para especificar los intervalos CIDR de IPv6 del tráfico que quiera replicar. Puedes replicar todo el tráfico IPv6 con un filtro de intervalo CIDR de ::/0. Puedes replicar todo el tráfico IPv4 e IPv6 mediante el siguiente filtro de intervalo CIDR separado por comas: 0.0.0.0/0,::/0.
La replicación del tráfico consume ancho de banda en la instancia replicada. Por ejemplo, si una instancia replicada experimenta 1 Gbps de tráfico de entrada y 1 Gbps de tráfico de salida, el tráfico total de las instancias será de 1 Gbps de entrada y 3 Gbps de salida (1 Gbps de tráfico de salida normal y 2 Gbps de tráfico de salida replicado). Para limitar el tráfico que se recoge, puede usar filtros.
El coste de la replicación de paquetes varía en función de la cantidad de tráfico de salida que se traslada de una instancia replicada a un grupo de instancias y de si el tráfico se traslada entre zonas.
La replicación de paquetes se aplica tanto a la dirección de entrada como a la de salida. Si dos instancias de VM que se están replicando envían tráfico entre sí,Google Cloud recoge dos versiones del mismo paquete. Puedes modificar este comportamiento especificando que solo se repliquen los paquetes de entrada o de salida.
Hay un número máximo de políticas de replicación de paquetes que puedes crear en un proyecto. Para obtener más información, consulta las cuotas por proyecto en la página de cuotas.
En cada política de replicación de paquetes, el número máximo de fuentes replicadas que puedes especificar depende del tipo de fuente:
- 5 subredes
- 5 etiquetas
- 50 instancias
El número máximo de filtros de duplicación de paquetes es 30, que es el número de intervalos de direcciones IPv4 e IPv6 multiplicado por el número de protocolos. Por ejemplo, puede especificar 30 intervalos y 1 protocolo, lo que equivaldría a 30 filtros. Sin embargo, no puedes especificar 30 intervalos y 2 protocolos, ya que serían 60 filtros, lo que supera el máximo.
El tráfico replicado solo se cifra si la VM cifra ese tráfico en la capa de aplicación. Aunque las conexiones entre máquinas virtuales dentro de las redes de VPC y las redes de VPC emparejadas están encriptadas, el cifrado y el descifrado se producen en los hipervisores. Desde la perspectiva de la VM, este tráfico no está cifrado.

Casos prácticos

En las siguientes secciones se describen situaciones reales que demuestran por qué puede usar la creación de réplicas de paquetes.

Seguridad empresarial

Los equipos de seguridad y de ingeniería de redes deben asegurarse de detectar todas las anomalías y amenazas que puedan indicar brechas e intrusiones de seguridad. Duplican todo el tráfico para poder completar una inspección exhaustiva de los flujos sospechosos. Como los ataques pueden abarcar varios paquetes, los equipos de seguridad deben poder obtener todos los paquetes de cada flujo.

Por ejemplo, las siguientes herramientas de seguridad requieren que captures varios paquetes:

Las herramientas de sistemas de detección de intrusiones (IDS) requieren varios paquetes de un solo flujo para que coincidan con una firma, de modo que las herramientas puedan detectar amenazas persistentes.
Los motores de inspección profunda de paquetes inspeccionan las cargas útiles de los paquetes para detectar anomalías en los protocolos.
La informática forense de redes para cumplir la normativa PCI y otros casos prácticos requiere que se examinen la mayoría de los paquetes. La función de duplicación de paquetes proporciona una solución para capturar diferentes vectores de ataque, como comunicaciones poco frecuentes o comunicaciones intentadas pero fallidas.

Monitorización del rendimiento de las aplicaciones

Los ingenieros de redes pueden usar el tráfico duplicado para solucionar los problemas de rendimiento que comunican los equipos de aplicaciones y bases de datos. Para comprobar si hay problemas de red, los ingenieros de redes pueden ver lo que se transmite por cable en lugar de depender de los registros de aplicaciones.

Por ejemplo, los ingenieros de redes pueden usar los datos de la duplicación de paquetes para completar las siguientes tareas:

Analiza los protocolos y los comportamientos para que puedan detectar y solucionar problemas, como la pérdida de paquetes o los restablecimientos de TCP.
Analiza (en tiempo real) los patrones de tráfico del escritorio remoto, VoIP y otras aplicaciones interactivas. Los ingenieros de redes pueden buscar problemas que afecten a la experiencia de usuario de la aplicación, como el reenvío de varios paquetes o más reconexiones de las esperadas.

Topologías de destino del recopilador de ejemplo

Puedes usar la replicación de paquetes en varias configuraciones. En los siguientes ejemplos se muestra la ubicación de los destinos del recopilador y sus políticas para diferentes configuraciones de réplica de paquetes, como el emparejamiento entre redes de VPC y la VPC compartida.

Destino del recopilador en la misma red

En el siguiente ejemplo se muestra una configuración de replicación de paquetes en la que el origen replicado y el destino del recopilador están en la misma red VPC.

Una política de replicación de paquetes con un origen replicado y un recopilador de destino en la misma red de VPC. — Política de replicación de paquetes que tiene todos los recursos en la misma red de VPC (haz clic en la imagen para ampliarla).

En el diagrama anterior, la política de replicación de paquetes está configurada para replicar mirrored-subnet y enviar el tráfico replicado al balanceador de carga de red con paso a través interno.Google Cloud replica el tráfico de las instancias actuales y futuras de la subred. Todo el tráfico hacia y desde Internet, los hosts on-premise o los servicios de Google se replica.

Destino del recopilador en una red peer

Puedes crear un modelo de recopilador centralizado en el que las instancias de diferentes redes VPC envíen tráfico replicado a un destino de recopilador en una red VPC central. De esta forma, puedes usar un solo colector de destino.

En el siguiente ejemplo, el balanceador de carga de red de paso a través interno collector-load-balancer se encuentra en la región us-central1 de la red de VPC network-a en project-a. Este recopilador de destino se puede usar en dos políticas de replicación de paquetes:

policy-1 recopila paquetes de orígenes replicados en la región us-central1 de la red de VPC network-a en project-a y los envía al destino collector-load-balancer.
policy-2 recopila paquetes de orígenes replicados en la región us-central1 de la red de VPC network-b en project-b y los envía al mismo destino collector-load-balancer.

Se necesitan dos políticas de creación de réplicas porque los orígenes replicados se encuentran en redes de VPC diferentes.

Una política de replicación de paquetes en una red central en la que se encuentra el destino del recopilador. La red está emparejada
con otras redes en las que se encuentran las fuentes reflejadas. — Políticas de replicación de paquetes en una red central emparejada con otras redes que tienen orígenes replicados (haz clic en la imagen para ampliarla).

En el diagrama anterior, el destino del recopilador recoge el tráfico replicado de las subredes de dos redes diferentes. Todos los recursos (el origen y el destino) deben estar en la misma región. La configuración de network-a es similar a la del ejemplo en el que el origen replicado y el destino del recopilador están en la misma red VPC. policy-1 se configura para recoger tráfico de subnet-a y enviarlo a collector-ilb.

policy-2 está configurado en project-a, pero especifica subnet-b como origen duplicado. Como network-a y network-b están emparejados, el recopilador de destino puede recoger tráfico de subnet-b.

Las redes están en proyectos diferentes y pueden tener propietarios distintos. Cualquiera de los propietarios puede crear la política de replicación de paquetes si tiene los permisos adecuados:

Si los propietarios de project-a crean la política de replicación de paquetes, deben tener el rol compute.packetMirroringAdmin en la red, la subred o las instancias que se van a replicar en project-b.
Si los propietarios de project-b crean la política de replicación de paquetes, deben tener el rol compute.packetMirroringUser en project-a.

Para obtener más información sobre cómo habilitar la conectividad privada entre dos redes VPC, consulta Emparejamiento entre redes de VPC.

VPC compartida

En los siguientes casos de VPC compartida, las instancias replicadas del destino del recopilador están en la misma red de VPC compartida. Aunque los recursos estén en la misma red, pueden estar en proyectos diferentes, como el proyecto host o varios proyectos de servicio distintos. En los siguientes ejemplos se muestra dónde se deben crear las políticas de replicación de paquetes y quién puede crearlas.

Si tanto los orígenes replicados como el destino del recopilador están en el mismo proyecto (ya sea en un proyecto host o en un proyecto de servicio), la configuración es similar a la de tener todo en la misma red VPC. El propietario del proyecto puede crear todos los recursos y definir los permisos necesarios en ese proyecto.

Para obtener más información, consulta la descripción general de la VPC compartida.

Destino del recopilador en el proyecto de servicio

En el siguiente ejemplo, el destino del recopilador se encuentra en un proyecto de servicio que usa una subred del proyecto del host. En este caso, la política también está en el proyecto de servicio. La política también puede estar en el proyecto host.

La relación entre los proyectos host y de servicio de Packet Mirroring. — Destino del recopilador en el proyecto de servicio (haz clic en la imagen para ampliarla).

En el diagrama anterior, el proyecto de servicio contiene las instancias del recolector que usan la subred del recolector en la red de VPC compartida. La política de replicación de paquetes se ha creado en el proyecto de servicio y se ha configurado para replicar instancias que tengan una interfaz de red en subnet-mirrored.

Los usuarios del proyecto de servicio o del proyecto host pueden crear la política de creación de reflejo de paquetes. Para ello, los usuarios deben tener el rol compute.packetMirroringUser en el proyecto de servicio en el que se encuentra el destino del recolector. Los usuarios también deben tener el rol compute.packetMirroringAdmin en las fuentes reflejadas.

Destino del recopilador en el proyecto de host

En el siguiente ejemplo, el destino del recopilador está en el proyecto host y las instancias reflejadas están en los proyectos de servicio.

Este ejemplo puede aplicarse a situaciones en las que los desarrolladores implementan aplicaciones en proyectos de servicio y usan la red de VPC compartida. No tienen que gestionar la infraestructura de red ni la creación de réplicas de paquetes. En su lugar, un equipo centralizado de redes o de seguridad, que tiene control sobre el proyecto host y la red de VPC compartida, es el responsable de aprovisionar las políticas de creación de réplicas de paquetes.

En el diagrama anterior, la política de replicación de paquetes se crea en el proyecto host, donde se encuentra el destino del recopilador. La política se configura para replicar instancias en la subred replicada. Las instancias de VM de los proyectos de servicio pueden usar la subred replicada y su tráfico se replica.

Los usuarios del proyecto de servicio o del proyecto host pueden crear la política de creación de reflejo de paquetes. Para ello, los usuarios del proyecto de servicio deben tener el rol compute.packetMirroringUser en el proyecto host. Los usuarios del proyecto host necesitan el rol compute.packetMirroringAdmin para las fuentes replicadas en los proyectos de servicio.

Instancias de VM con varias interfaces

Puede incluir instancias de VM que tengan varias interfaces de red en una política de creación de reflejo de paquetes. Como una política puede replicar recursos de una sola red, no puedes crear una política para replicar el tráfico de todas las interfaces de red de una instancia. Si necesitas duplicar más de una interfaz de red de una instancia con varias interfaces de red, debes crear una política de duplicación de paquetes para cada interfaz, ya que cada interfaz se conecta a una red de VPC única.

Precios

Se te cobra por la cantidad de datos que procesa la replicación de paquetes, Para obtener más información, consulta los precios de Packet Mirroring.

También se te cobrarán todos los componentes obligatorios y el tráfico de salida relacionados con la replicación de paquetes. Por ejemplo, las instancias que recogen tráfico se cobran a la tarifa normal. Además, si el tráfico de réplica de paquetes se desplaza entre zonas, se te cobrará por el tráfico de salida. Para obtener información sobre los precios, consulta la página de precios correspondiente.