Duplicación de paquetes

En esta página, se brinda una descripción general de la duplicación de paquetes.

Con la duplicación de paquetes, se puede clonar el tráfico de las instancias especificadas en tu red de nube privada virtual (VPC) y reenviarlo para su análisis. La duplicación de paquetes capta todo el tráfico y los datos de paquetes, incluidas las cargas útiles y los encabezados. Se puede configurar la captura para solo el tráfico de entrada o solo el de salida, o ambos (entrada y salida).

La duplicación ocurre en las instancias de máquina virtual (VM), no en la red. Por lo tanto, con la duplicación de paquetes, se consume ancho de banda adicional en las VM.

La duplicación de paquetes es útil cuando necesitas supervisar y analizar tu estado de seguridad. Se exporta todo el tráfico, no solo el tráfico entre los períodos de muestreo. Por ejemplo, puedes usar software de seguridad para analizar el tráfico duplicado y detectar todas las amenazas o anomalías. Además, puedes inspeccionar el flujo de tráfico completo a fin de detectar problemas de rendimiento de las aplicaciones. Para obtener más información, consulta los ejemplos de Casos prácticos.

Cómo funciona

En la duplicación de paquetes, se copia el tráfico de las fuentes duplicadas y se lo envía a un destino de colector. Para configurar la duplicación de paquetes, crea una política de duplicación de paquetes que especifique la fuente y el destino.

• Las fuentes duplicadas son instancias de VM de Compute Engine que puedes seleccionar mediante la especificación de subredes, etiquetas de red o nombres de instancias. Si especificas una subred, todas las instancias existentes y futuras de esa subred se duplican. Puedes especificar uno o más tipos de fuente, si una instancia coincide con al menos uno de ellos, se duplicará.

  En la duplicación de paquetes, se recopila el tráfico de la interfaz de red de una instancia en la red en la que se aplica la política de duplicación de paquetes. En los casos en los que una instancia tiene varias interfaces de red, las otras interfaces no se duplican, a menos que se haya configurado otra política para hacerlo.

• El destino de un recopilador es un grupo de instancias que se encuentra detrás de un balanceador de cargas interno. Las instancias del grupo se denominan instancias de recopilador.

  Cuando especificas el destino de recopilador, ingresas el nombre de una regla de reenvío que está asociada con el balanceador de cargas de red de transferencia interno. A continuación, en Google Cloud, se reenvía el tráfico duplicado a las instancias del colector. Un balanceador de cargas interno para la duplicación de paquetes es similar a otros balanceadores de cargas internos, excepto que la regla de reenvío debe configurarse para la duplicación de paquetes. Todo el tráfico no duplicado que se envía al balanceador de cargas se descarta.

Filtros

De forma predeterminada, la Duplicación de paquetes recopila todo el tráfico IPv4 de las instancias duplicadas. En lugar de recopilar todo el tráfico IPv4, puedes usar filtros para expandir el tráfico que se recopila a fin de incluir todo el tráfico IPv6 o parte de él. También puedes usar filtros para limitar el tráfico que se duplica, lo que puede ayudarte a limitar el ancho de banda que usan las instancias duplicadas.

Puedes configurar filtros para recopilar tráfico en función del protocolo, los rangos de CIDR (IPv4, IPv6 o ambos), la dirección del tráfico (solo de entrada, solo de salida o ambos) o una combinación.

Orden de la política

Se pueden aplicar varias políticas de duplicación de paquetes a una instancia. La prioridad de una política de duplicación de paquetes siempre es 1000 y no se puede cambiar. No se admiten las políticas idénticas. Google Cloud puede enviar tráfico a cualquiera de los balanceadores de cargas que se configuraron con políticas de duplicación de paquetes idénticas. Si deseas enviar tráfico duplicado a un solo balanceador de cargas de manera predecible y coherente, crea políticas que tengan filtros con rangos de direcciones que no se superpongan. Si los rangos se superponen, configura protocolos de filtro únicos.

Google Cloud elige una política para cada flujo según el filtro de cada política. Si tienes políticas distintas, en Google Cloud, se usa la política correspondiente que coincide con el tráfico duplicado. Por ejemplo, puedes tener una política con el filtro 198.51.100.3/24:TCP y otra con el filtro 2001:db8::/64:TCP:UDP. Debido a que las políticas son distintas, no existe ambigüedad sobre la política que se usa en Google Cloud.

Sin embargo, si tienes políticas que se superponen, 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 superponen porque sus rangos de CIDR también lo hacen.

En Google Cloud, a la hora de elegir se priorizan las políticas mediante la comparación del tamaño del rango de CIDR de sus filtros.

En Google Cloud, se elige una política basada en un filtro, con los siguientes alcances:

• Si las políticas tienen rangos de CIDR diferentes pero superpuestos y tienen exactamente los mismos protocolos, Google Cloud selecciona la política que usa el rango de CIDR más específico. Supongamos que el destino de un paquete de TCP que sale de una instancia duplicada es 10.240.1.4 y hay dos políticas con los siguientes filtros: 10.240.1.0/24:ALL y 10.240.0.0/16:TCP. Debido a que la coincidencia más específica para 10.240.1.4 es 10.240.1.0/24:ALL, se usa la política que tiene el filtro 10.240.1.0/24:ALL.

• Si en las políticas se especifica exactamente el mismo rango de CIDR con protocolos que se superponen, Google Cloud elige una política con el protocolo más específico. Por ejemplo, los siguientes filtros tienen el mismo rango, pero los protocolos se superponen: 10.240.1.0/24:TCP y 10.240.1.0/24:ALL. Google Cloud usa la política 10.240.1.0/24:TCP para el tráfico de TCP coincidente. 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 exactamente el mismo rango de CIDR pero protocolos distintos, estas políticas no se superponen. En Google Cloud, se usa la política que corresponde al protocolo del tráfico duplicado. Por ejemplo, puedes tener una política para 2001:db8::/64:TCP y otra para 2001:db8::/64:UDP. También, se usa la política de TCP o UDP según el protocolo del tráfico duplicado.

• Si las políticas que se superponen tienen exactamente el mismo filtro, son idénticas. En este caso, Google Cloud puede elegir la misma política o una política diferente cada vez que el tráfico coincidente se vuelva a evaluar en función de estas políticas. Te recomendamos que evites crear políticas de duplicación de paquetes idénticas.

Registros de flujo de VPC

En los registros de flujo de VPC, no se registran los paquetes duplicados. Si una instancia de colector está en una subred que tiene habilitados los registros de flujo de VPC, se registra el tráfico que se envía directamente a la instancia de colector, incluido el tráfico de las instancias duplicadas. Es decir, si la dirección IPv4 o IPv6 de destino original coincide con la dirección IPv4 o IPv6 de la instancia de colector, se registra el flujo.

Para obtener más información sobre los registros de flujo de VPC, consulta Usa los registros de flujo de VPC.

Propiedades principales

En la siguiente lista, se describen las restricciones o los comportamientos relacionados con la duplicación de paquetes que es importante comprender antes del uso:

• Cada política de duplicación de paquetes define fuentes duplicadas y un destino de colector. Debes cumplir con las siguientes reglas:

  • Todas las fuentes duplicadas deben estar en el mismo proyecto, la red de VPC y la región de Google Cloud.
  • Un destino de colector debe estar en la misma región que las fuentes duplicadas. Un destino de colector se puede encontrar en la misma red de VPC que las fuentes duplicadas o en una red de VPC conectada a la red de fuentes duplicadas mediante el intercambio de tráfico entre redes de VPC.
  • Cada política de duplicación solo puede hacer referencia a un único destino de colector. Sin embargo, varias políticas de duplicación pueden hacer referencia a un solo destino de colector.

• Todos los protocolos de capa 4 son compatibles con la Duplicación de paquetes.

• No puedes duplicar ni recopilar tráfico en la misma interfaz de red que una instancia de VM porque esto provocaría un bucle de duplicación.

• Para duplicar el tráfico que pasa entre los Pods del mismo nodo de Google Kubernetes Engine (GKE), debes habilitar la visibilidad dentro de los nodos en el clúster.

• Para duplicar el tráfico IPv6, usa filtros para especificar los rangos de CIDR IPv6 del tráfico IPv6 que deseas duplicar. Puedes duplicar todo el tráfico IPv6 mediante un filtro de rango de CIDR de ::/0. Puedes duplicar todo el tráfico IPv4 e IPv6 mediante el siguiente filtro de rango de CIDR separado por comas: 0.0.0.0/0,::/0.

• La duplicación de tráfico consume ancho de banda en la instancia duplicada. Por ejemplo, si en una instancia duplicada se experimenta 1 Gbps de tráfico de entrada y 1 Gbps de tráfico de salida, el tráfico total en las instancias es de 1 Gbps de entrada y de 3 Gbps de salida (1 Gbps de tráfico de salida normal y 2 Gbps de tráfico de salida duplicado). Para limitar el tráfico que se recopila, puedes usar filtros.

• El costo de la duplicación de paquetes varía según la cantidad de tráfico de salida que se mueve de una instancia duplicada a un grupo de instancias y si el tráfico se mueve entre zonas.

• La duplicación de paquetes se aplica a la dirección de entrada y de salida. Si se genera tráfico entre dos instancias de VM que se duplican, en Google Cloud, se recopilan dos versiones del mismo paquete. Puedes modificar este comportamiento si especificas que solo se dupliquen los paquetes de entrada o salida.

• Existe una cantidad máxima de políticas de duplicación de paquetes que puedes crear para un proyecto. Para obtener más información, consulta las cuotas por proyecto en la página de cuotas.

• Para cada política de duplicación de paquetes, la cantidad máxima de fuentes duplicadas que puedes especificar depende del tipo de fuente:

  • 5 subredes
  • 5 etiquetas
  • 50 instancias

• La cantidad máxima de filtros de duplicación de paquetes es 30, que es la cantidad de rangos de direcciones IPv4 e IPv6 multiplicada por la cantidad de protocolos. Por ejemplo, puedes especificar 30 rangos y 1 protocolo, que serían 30 filtros. Sin embargo, no puedes especificar 30 rangos y 2 protocolos, que serían 60 filtros, porque esa cantidad excede el máximo.

• Se te cobrará según la cantidad de datos que se procesen mediante la duplicación de paquetes. Para obtener detalles, consulta los precios de la duplicación de paquetes.

  También se te cobra por todos los componentes necesarios y el tráfico de salida relacionados con la duplicación de paquetes. Por ejemplo, las instancias en las que se recopila tráfico se cobran según la tarifa regular. Además, si el tráfico de duplicación de paquetes se mueve entre zonas, se te cobra por el tráfico de salida. Para obtener información sobre los precios, consulta la página de precios relacionada.

• El tráfico duplicado se encripta solo si la VM encripta ese tráfico en la capa de la aplicación. Mientras las conexiones de VM a VM dentro de redes de VPC y de redes de intercambio de tráfico estén encriptadas, la encriptación y desencriptación se realizan en los hipervisores. Desde la perspectiva de la VM, este tráfico no está encriptado.

Casos de uso

En las siguientes secciones, se describen situaciones del mundo real en las que se demuestran los casos en los que puedes usar la duplicación de paquetes.

Seguridad empresarial

Los equipos de seguridad y de ingeniería de red deben asegurarse de detectar todas las anomalías y amenazas que pueden indicar intrusiones y un incumplimiento de las normas de seguridad. Duplican todo el tráfico a fin de realizar una inspección exhaustiva de los flujos sospechosos. Dado que los ataques pueden abarcar varios paquetes, los equipos de seguridad deben ser capaces de obtener todos los paquetes de cada flujo.

Por ejemplo, en las siguientes herramientas de seguridad, se requiere que captures varios paquetes:

• Las herramientas del sistema de detección de intrusiones (IDS) requieren que varios paquetes de un solo flujo coincidan con una firma para que las herramientas puedan detectar amenazas persistentes.

• Los motores de inspección profunda de paquetes inspeccionan las cargas útiles del paquete a fin de detectar anomalías en el protocolo.

• Las intrusiones en la red para el cumplimiento de la PCI y otros casos de uso relacionados con las normas requieren que la mayoría de los paquetes se examinen. La duplicación de paquetes proporciona una solución para capturar diferentes vectores de ataque, como una comunicación poco frecuente o un intento de comunicación que falló.

Supervisión del rendimiento de las aplicaciones

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

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

• Analizar protocolos y comportamientos a fin de encontrar y solucionar problemas, como la pérdida de paquetes o los restablecimientos de TCP

• Analizar (en tiempo real) los patrones de tráfico desde un escritorio remoto, VoIP y otras aplicaciones interactivas. Los ingenieros de red pueden buscar problemas que afecten la experiencia del usuario de la aplicación, como múltiples reenvíos de paquetes o una cantidad de reconexiones mayor que la esperada

Ejemplos de topologías de destino de colector

Puedes usar la duplicación de paquetes con varias opciones de configuración. En los siguientes ejemplos, se muestra la ubicación de los destinos de colector y sus políticas para las diferentes configuraciones de duplicación de paquetes, como el intercambio de tráfico entre redes de VPC y la VPC compartida.

Destino de colector en la misma red

En el siguiente ejemplo, se muestra una configuración de duplicación de paquetes en la que la fuente duplicada y el destino de colector se encuentran en la misma red de VPC.

En el diagrama anterior, la política de duplicación de paquetes está configurada para duplicar mirrored-subnet y enviar tráfico duplicado al balanceador de cargas de red de transferencia interno. En Google Cloud, se duplica el tráfico en las instancias existentes y futuras de la subred. Se duplica todo el tráfico hacia y desde Internet, los hosts locales o los servicios de Google.

Destino de colector en una red de intercambio de tráfico

Puedes compilar un modelo de colector centralizado, en el que las instancias en diferentes redes de VPC envían tráfico duplicado a un destino de colector en una red de VPC central. De esta manera, puedes usar un único colector de destino.

En el siguiente ejemplo, el balanceador de cargas de red de transferencia interno collector-load-balancer se encuentra en la región us-central1 en la red de VPC network-a en project-a. Este colector de destino lo pueden usar dos políticas de duplicación de paquetes:

• policy-1 recopila paquetes de fuentes duplicadas en la región us-central1 en la red de VPC network-a en project-a y las envía al destino collector-load-balancer.

• policy-2 recopila paquetes de fuentes duplicadas en la región us-central1 en la red de VPC network-b en project-b y las envía al mismo destino collector-load-balancer.

Se requieren dos políticas de duplicación porque las fuentes duplicadas existen en redes de VPC diferentes.

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

policy-2 se configura en project-a, pero especifica subnet-b como una fuente duplicada. Dado que network-a y network-b realizan un intercambio de tráfico, el colector de destino puede recopilar el tráfico desde subnet-b.

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

• Si los propietarios de project-a crean la política de duplicación de paquetes, deben tener la función de compute.packetMirroringAdmin en la red, la subred o las instancias para duplicar en project-b.

• Si los propietarios de project-b crean la política de duplicación de paquetes, deben tener la función compute.packetMirroringUser en project-a.

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

VPC compartida

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

Si las fuentes duplicadas y el destino de colector están en el mismo proyecto, ya sea en un proyecto host o un proyecto de servicio, la configuración es similar a cuando se tiene todo en la misma red de VPC. El propietario del proyecto puede crear todos los recursos y establecer los permisos necesarios en ese proyecto.

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

Destino de colector en el proyecto de servicio

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

En el diagrama anterior, el proyecto de servicio contiene las instancias de colector en las que se usa la subred de este en la red de VPC compartida. La política de duplicación de paquetes se creó en el proyecto de servicio y está configurada para duplicar las instancias que tienen una interfaz de red en subnet-mirrored.

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

Destino de colector en el proyecto host

En el siguiente ejemplo, el destino de colector se encuentra en el proyecto host, y las instancias duplicadas 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 es necesario que administren la infraestructura de red ni la duplicación de paquetes. En cambio, un equipo de seguridad o de red centralizado, que tiene el control del proyecto host y de la red de VPC compartida, es responsable de aprovisionar las políticas de duplicación de paquetes.

En el diagrama anterior, la política de duplicación de paquetes se crea en el proyecto host, en el que se encuentra el destino de colector. La política está configurada para duplicar las instancias en la subred duplicada. En las instancias de VM de los proyectos de servicio, se puede usar la subred duplicada y su tráfico se duplica.

Los usuarios del proyecto host o de servicio pueden crear la política de duplicación de paquetes. Para ello, los usuarios del proyecto de servicio deben tener la función de compute.packetMirroringUser en el proyecto host. Los usuarios del proyecto host requieren la función de compute.packetMirroringAdmin para las fuentes duplicadas en los proyectos de servicio.

Instancias de VM de varias interfaces

Puedes incluir instancias de VM que tengan varias interfaces de red en una política de duplicación de paquetes. Dado que en una política se pueden duplicar recursos de una sola red, no puedes crear una política para duplicar 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 de interfaz de red múltiple, 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.

¿Qué sigue?

• Para crear y administrar políticas de duplicación de paquetes, consulta Usa la duplicación de paquetes.
• Para ver las métricas y verificar las políticas de duplicación de paquetes existentes, consulta Supervisa la duplicación de paquetes.
• Para obtener información sobre los balanceadores de cargas de red de transferencia internos, consulta Descripción general del balanceador de cargas de red de transferencia interno.
• Para obtener una lista de proveedores de socios, consulta Proveedores de socios de duplicación de paquetes.