Descripción general de la duplicación de paquetes

beta

La duplicación de paquetes clona el tráfico de instancias especificadas en tu red de nube privada virtual (VPC) y lo reenvía para su análisis. La duplicación de paquetes 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. En consecuencia, la duplicación de paquetes consume ancho de banda adicional en los hosts.

La duplicación de paquetes es útil cuando necesitas supervisar y analizar tu estado de seguridad. Exporta todo el tráfico, no solo el tráfico entre los períodos de muestreo. Por ejemplo, puede usar software de seguridad que analice el tráfico duplicado para detectar todas las amenazas o anomalías. Además, puedes 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 de ejemplo.

Cómo funciona

La duplicación de paquetes copia el tráfico de las fuentes duplicadas y 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 instancias. Si especificas una subred, todas las instancias existentes y futuras de esa subred se duplican. Puedes especificar uno o más tipos de fuentes; si una instancia coincide con al menos uno de ellos, se duplica.

    La duplicación de paquetes 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 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.

  • Un destino de colector es un grupo de instancias que se encuentra detrás de un balanceador de cargas interno. Las instancias en el grupo de instancias se denominan instancias de colector.

    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, Google Cloud reenvía el tráfico duplicado a las instancias de 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. Cualquier 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 de entrada y salida de las instancias duplicadas. En lugar de recopilar todo el tráfico, puedes usar filtros para limitar el tráfico que se duplica. El uso 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. Según el filtro y la prioridad de cada política, Google Cloud elige una para cada flujo. Si tienes políticas distintas, Google Cloud usa la política correspondiente que coincide con el tráfico duplicado. Por ejemplo, puede que tengas una política con el filtro 1.1.1.1/24:TCP y otra política con el filtro 2.2.2.2/24:UDP. Debido a que las políticas son distintas, no existe ambigüedad sobre la política que Google Cloud usa.

Sin embargo, si tienes políticas que se superponen, Google Cloud evalúa sus filtros y prioridades para elegir una. Por ejemplo, puede que tengas dos políticas, una que tenga 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 se superponen.

A la hora de elegir una política, Google Cloud las prioriza mediante la comparación del tamaño del rango de CIDR de sus filtros. Si las políticas que se superponen tienen exactamente el mismo filtro, Google Cloud compara sus valores de prioridad. En la siguiente lista, se detalla la evaluación que Google Cloud realiza cuando varias políticas se superponen:

  • Si las políticas tienen exactamente los mismos filtros (rango de CIDR y protocolo), Google Cloud usa la política con el valor de prioridad más bajo. Por ejemplo, si tienes varias políticas que usan el filtro predeterminado, es decir, que coinciden en 0.0.0.0/0 para todos los protocolos, Google Cloud usa la política con el valor de prioridad más bajo. Este es el único caso en el que Google Cloud usa el valor de prioridad.

    Si las políticas tienen la misma prioridad, Google Cloud elige una mediante un método no determinista. Cada vez que se vuelva a evaluar el tráfico de coincidencias respecto de estas políticas, Google Cloud podría elegir la misma política o una diferente.

  • En los siguientes casos, Google Cloud elige una política según su filtro. Se ignoran los valores de prioridad de cada política.

    • 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 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, Google Cloud usa la política que tiene el filtro 10.240.1.0/24:ALL.

    • Si las políticas tienen exactamente el mismo rango de CIDR, pero protocolos distintos, estas políticas no se superponen. Google Cloud usa la política que corresponde al protocolo del tráfico duplicado. Por ejemplo, puede que tengas una política para 10.240.1.0/24:TCP y otra para 10.240.1.0/24:UDP. Según el protocolo del tráfico duplicado, Google Cloud usa la política de TCP o UDP.

    • Si las políticas especifican exactamente el mismo rango de CIDR con protocolos superpuestos, Google Cloud elige una política mediante un método no determinista. 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 los casos en que la política seleccionada no sea determinista, es posible que Google Cloud capture el tráfico duplicado en varios balanceadores de cargas. Si quieres 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. Si las políticas tienen filtros que coinciden o usan el filtro predeterminado, establece números de prioridad únicos para esas políticas.

Recopilación de paquetes

Para recopilar tráfico duplicado, la duplicación de paquetes requiere que uses un balanceador de cargas interno como parte del destino de colector. Si tienes varias instancias de colector detrás del balanceador de cargas, Google Cloud podría enviar flujos de entrada y salida a diferentes instancias de colector. Sin embargo, a fin de que las herramientas de seguridad analicen los datos y detecten los patrones de forma eficaz, estas requieren todos los paquetes para una sola transmisión de comunicación (flujos de entrada y salida).

Para recopilar una transmisión en una sola instancia de colector, usa un grupo de instancias administrado o no administrado que siempre tenga una instancia de colector única.

Registros de flujo de VPC

Si las instancias duplicadas están en una subred que también tiene registros de flujo de VPC habilitados, estos no informan los paquetes clonados. Los registros de flujo de VPC solo registran 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, estos capturan el flujo entre las instancias duplicadas y de colector. Los registros muestran las direcciones IP de origen 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 de usarla:

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

  • Las fuentes duplicadas y el destino del 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.

  • La duplicación de tráfico consume ancho de banda en la instancia duplicada. Por ejemplo, si una instancia duplicada experimenta 1 Gbps de tráfico de entrada y 1 Gbps de salida, el tráfico total en las instancias es 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 duplicado). Para limitar el tráfico que se recopila, puedes usar filtros.

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

  • La duplicación de paquetes se aplica a la dirección de entrada y de salida. Si dos instancias de VM que se están duplicando generan tráfico entre sí, Google Cloud recopila 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 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 y es más que el máximo.

  • Para la versión Beta, no se cobra por usar la duplicación de paquetes. Los cargos comienzan cuando la duplicación de paquetes tiene disponibilidad general (GA). Se te cobra por cada regla de reenvío de duplicación de paquetes y por la cantidad de datos procesados, similar a las reglas de reenvío y los balanceadores de cargas existentes. Para obtener más información, consulta los precios de las reglas de reenvío y balanceo de cargas.

Casos prácticos

En las siguientes secciones, se describen situaciones del mundo real que demuestran en qué casos podrías 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 podrían indicar intrusiones y fallas 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 poder obtener todos los paquetes de cada flujo.

Por ejemplo, las siguientes herramientas de seguridad requieren 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.

  • Intrusiones en la red para el cumplimiento de la PCI y otros casos prácticos regulatorios. La duplicación de paquetes proporciona una solución para capturar diferentes vectores de ataque, como una comunicación poco frecuente o una comunicación intentada pero no exitosa.

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 ocurre en realidad, en lugar de depender de los registros de la aplicación.

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 opciones de configuración de duplicación de paquetes, como el intercambio de tráfico entre redes de VPC y la VPC compartida.

Destino del 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 subnet-a y enviar tráfico duplicado al balanceador de cargas interno. Google Cloud duplica el tráfico en las instancias existentes y futuras en la subred. Todo el tráfico hacia Internet, los hosts locales o los servicios de Google, así como el tráfico desde esas ubicaciones, se duplica.

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 una red de VPC central. De este modo, no es necesario compilar un destino de colector en cada red. La red central de VPC aloja uno o más destinos de colector en 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. Todas las redes de VPC que incluyen fuentes duplicadas deben 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 que tenga una red que realice un intercambio de tráfico con la red central.

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 está configurado para recopilar el tráfico de subnet-a y enviarlo a collector-ilb.

policy-2 está configurado 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 destino de colector puede recopilar el tráfico desde subnet-b.

Las redes están en proyectos diferentes y puede que tengan 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 compute.packetMirroringAdmin en la red, subred o 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 diferentes, 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 tener 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 que 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 que usan la subred de colector 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 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 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 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 red centralizado, que tiene el control del proyecto host y 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. Las instancias de VM en proyectos de servicio pueden 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 compute.packetMirroringUser en el proyecto host. Los usuarios del proyecto host requieren la función 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. Debido a que una política puede 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