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. En la duplicación de paquetes, se captura todo el tráfico de entrada y salida, además de los datos de paquetes, como las cargas útiles y los encabezados. 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 los hosts.

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 Compute Engine que puedes seleccionar mediante la especificación de subredes, etiquetas de red o nombres de instancia. 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 colector es un grupo de instancias que se encuentra detrás de un balanceador de cargas interno. Las instancias del grupo se denominan instancias de colector. Para el grupo de instancias, recomendamos que uses grupos de instancias administrados porque proporcionan funciones de ajuste de escala automático y reparación automática.

    Cuando especificas el destino de colector, ingresas el nombre de una regla de reenvío que está asociada con el balanceador de cargas 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

Con la duplicación de paquetes, se recopila todo el tráfico de entrada y salida de las instancias duplicadas de forma predeterminada. En lugar de recopilar todo el tráfico, puedes usar filtros para limitar el tráfico que se duplica. El empleo de filtros puede ayudarte a limitar el uso del ancho de banda en las instancias duplicadas.

Puedes configurar filtros para recopilar tráfico en función del protocolo, los rangos de direcciones IP o ambos. Puedes usar filtros para especificar solo el tráfico duplicado que se recopilará, no el tráfico que se excluirá.

Orden de la política

Se pueden aplicar varias políticas de duplicación de paquetes a una instancia. En Google Cloud, se elige una 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 203.0.113.2/24: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, se evalúan sus filtros para elegir una. 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 cuentan con exactamente los mismos protocolos, se selecciona la política que usa el rango de direcciones IP 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, se 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. En Google Cloud, se 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 10.240.1.0/24:TCP y otra para 10.240.1.0/24: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, se elige una con un método no determinista. Cada vez que se vuelve a evaluar el tráfico coincidente respecto de estas políticas, se puede elegir la misma política o una diferente.

En los casos en los que la política seleccionada no es determinista, es posible que se capture el tráfico duplicado en varios balanceadores de cargas con Google Cloud. 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.

Registros de flujo de VPC

Si las instancias duplicadas están en una subred que también tiene registros de flujo de VPC habilitados, los paquetes clonados no se informan en estos registros. En los registros de flujo de VPC, solo se registra el tráfico no duplicado.

Sin embargo, si las instancias de colector están en una subred que tiene registros de flujo de VPC habilitados, el flujo entre las instancias duplicadas y de colector se captura en estos registros. En los registros, se muestran las direcciones IP de fuente y de destino como las instancias duplicadas y de colector. Para detener la recopilación de registros en el tráfico duplicado, inhabilita los registros de flujo de VPC en la subred de instancias de colector.

Para obtener más información, 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:

  • Solo puedes duplicar el tráfico de TCP, de UDP y de ICMP.

  • Las fuentes duplicadas y el destino de colector deben estar en la misma región. Pueden estar en diferentes redes de VPC si están conectadas mediante el intercambio de tráfico entre redes de VPC.

  • 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 en el mismo nodo de Google Kubernetes Engine (GKE), debes habilitar la visibilidad dentro de los nodos del clúster.

  • 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.

  • 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 de 30, que es la cantidad de rangos de direcciones IP 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.

Casos prácticos

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:

  • En las herramientas del sistema de detección de intrusiones (IDS), se requiere 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 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 se envía tráfico duplicado a una red de VPC central desde las instancias en diferentes redes de VPC. De este modo, no necesitas compilar un colector de destino en cada red. En la red de VPC central, se alojan uno o más destinos de colector a los que se envía todo el tráfico duplicado.

Puedes lograr esta situación mediante el intercambio de tráfico entre redes de VPC. En todas las redes de VPC que incluyen fuentes duplicadas, se debe realizar un intercambio de tráfico con la red central.

Las redes de VPC pueden estar en el mismo proyecto o en proyectos diferentes. Para cada red de VPC de intercambio de tráfico, debes crear una política de duplicación de paquetes. En este caso, la política se encuentra en el proyecto que contiene la red central. La política también puede estar en un proyecto con una red en la que se realice un intercambio de tráfico con la red central.

Según el diagrama anterior, en el destino de colector, se 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 de compute.packetMirroringUser en project-a.

Para obtener más información sobre cómo habilitar la conectividad privada en dos redes de VPC, consulta la página sobre cómo intercambiar 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 configurar 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 deseas duplicar otras interfaces de red, debes crear una política para cada interfaz, ya que cada una se encuentra en una red diferente.

Próximos pasos