Registros de flujo de VPC

Los registros de flujo de VPC registran una muestra de flujos de red que envían y reciben las instancias de VM, incluidas las instancias que se usan como nodos de Google Kubernetes Engine. Estos registros se pueden usar para supervisar redes, detectar intrusiones, realizar análisis de seguridad en tiempo real y optimizar gastos.

Puedes ver los registros de flujo en Cloud Logging y los puedes exportar a cualquier destino que admita la exportación de Cloud Logging.

Los registros de flujo se agregan por conexión desde las VM de Compute Engine y se exportan en tiempo real. Cuando te suscribes a Pub/Sub, puedes analizar los registros de flujo con las API de transmisión en tiempo real.

Propiedades principales

  • Los registros de flujo de VPC son parte de Andromeda, el software que impulsa las redes de VPC. Los registros de flujo de VPC no presentan demoras ni penalizaciones de rendimiento cuando se habilitan.
  • Los registros de flujo de VPC funcionan con redes de VPC, no con redes heredadas. Puedes habilitar o inhabilitar los registros de flujo de VPC por subred. Cuando los registros de flujo de VPC se encuentran habilitados en una subred, recolectan información de todas las instancias de VM de esa subred.
  • Los registros de flujo de VPC realizan un muestreo de los flujos de TCP, UDP, ICMP y GRE de cada VM. Se realizan muestreos de los flujos entrantes y salientes. Estos flujos pueden estar entre la VM y otra VM, un host en el centro de datos local, un servicio de Google o un host en Internet. Si se captura un flujo con el muestreo, los registros de flujo de VPC generan un registro para el flujo. Cada informe de flujo incluye la información que se describe en la sección Formato del registro.
  • Los registros de flujo de VPC interactúan con reglas de firewall de las siguientes maneras:
    • Los paquetes de salida se muestrean antes de las reglas de firewall de salida. Incluso si una regla de firewall de salida rechaza los paquetes salientes, los registros de flujo de VPC pueden muestrear esos paquetes.
    • Los paquetes de entrada se muestrean después de las reglas de firewall de entrada. Si una regla de firewall de entrada deniega paquetes entrantes, los registros de flujo de VPC no muestrean esos paquetes.
  • Puedes usar filtros en los registros de flujo de VPC para generar solo ciertos registros.
  • Los registros de flujo de VPC admiten las VM que tienen interfaces de red múltiples. Debes habilitar los registros de flujo de VPC para cada subred, en cada VPC, que contenga una interfaz de red.
  • Para registrar flujos entre Pods en el mismo nodo de Google Kubernetes Engine (GKE), debes habilitar la visibilidad dentro de los nodos del clúster.

Casos de uso

Supervisión de red

El registro de flujo de VPC te permite ver en tiempo real la capacidad de procesamiento y rendimiento. Puedes llevar a cabo las siguientes acciones:

  • Supervisar la red de VPC
  • Realizar diagnósticos de la red
  • Filtrar los registros de flujo por VM y por aplicación para comprender los cambios en el tráfico
  • Comprender el crecimiento del tráfico para realizar una previsión de la capacidad

Cómo comprender el uso de la red y optimizar los gastos de tráfico de red

Con el registro de flujos de VPC puedes analizar el uso de la red. Puedes analizar los siguientes elementos del flujo de la red:

  • El tráfico entre regiones y zonas
  • El tráfico de Internet hacia países específicos
  • Los usuarios que más conversan

Puedes utilizar el análisis como base para optimizar los gastos del tráfico de red.

Intrusiones en la red

Puedes utilizar el registro de flujo de VPC para detectar las intrusiones en la red. Por ejemplo, si ocurre un incidente, puedes examinar los siguientes elementos:

  • Qué IP se comunicó con quién y en qué momento
  • Los IP comprometidos, con el análisis del flujo de red de entrada y de salida

Análisis de seguridad en tiempo real

Puedes aprovechar las API de transmisión en tiempo real (a través de Pub/Sub) y, también, integrar en los sistemas de SIEM (información de seguridad y administración de eventos). Esto te brinda supervisión en tiempo real, correlación de eventos, análisis y alertas de seguridad.

Recopilación de registros

Los registros de flujo se recopilan para cada conexión de VM en intervalos específicos. Todos los paquetes recopilados de un intervalo determinado para una conexión en particular se agregan durante un período (intervalo de agregación) en una sola entrada de registro de flujo. Estos datos se envían a Logging.

Los registros se almacenan en Logging durante 30 días de forma predeterminada. Si quieres conservar los registros por más tiempo, puedes configurar un período de retención personalizado o exportarlos a un destino admitido.

Muestreo y procesamiento de registros

Google Cloud crea muestras de los paquetes que ingresan a una VM y salen de ella para generar registros de flujo. No todos los paquetes se capturan en su propio registro. Se captura alrededor de 1 de cada 30 paquetes, pero esta tasa de muestreo puede ser menor según la carga de la VM. No se puede ajustar esta tasa.

Después de que se generan los registros de flujo, Google Cloud los procesa de acuerdo con el siguiente procedimiento:

  1. Filtros: Puedes especificar que solo se generen los registros que coinciden con los criterios especificados. Por ejemplo, puedes filtrar para que solo se generen registros para una VM en particular o solo los registros con un valor de metadatos específico y se descarta el resto. Para obtener más información, consulta Filtrado de registros.
  2. Agregación: La información de los paquetes de muestra se agrega en un intervalo de agregación configurable para producir una entrada de registro de flujo.
  3. Muestreo del registro de flujo: Este es un segundo proceso de muestreo. Las entradas del registro de flujo también se muestrean según un parámetro configurable de tasa de muestreo.
  4. Metadatos: Si se inhabilita, se descartan todas las anotaciones de metadatos. Si deseas conservar los metadatos, puedes especificar que se conserven todos los campos o un conjunto de campos especificado. Para obtener más información, consulta Anotaciones de metadatos.
  5. Escritura en Logging: Las entradas finales de registro se escriben en Cloud Logging.

Debido a que los registros de flujo de VPC no capturan todos los paquetes, compensa los paquetes perdidos a través de la interpolación de los paquetes capturados. Esto sucede para los paquetes que se pierden debido a la configuración de muestreo inicial y configurable por el usuario.

A pesar de que Google Cloud no captura todos los paquetes, las capturas de registros pueden ser bastante grandes. Para equilibrar las necesidades de visibilidad del tráfico y de costo de almacenamiento, ajusta los siguientes aspectos de la recopilación de registros:

  • Intervalo de agregación: Los paquetes de muestra de un intervalo de tiempo se agregan en una sola entrada de registro. Este intervalo de tiempo puede ser de 5 segundos (predeterminado), 30 segundos, 1 minuto, 5 minutos, 10 minutos o 15 minutos.
  • Tasa de muestreo: Antes de escribirse en Logging, se puede muestrear la cantidad de registros para reducir su número. De forma predeterminada, el volumen de entradas de registro se ajusta en 0.5 (50%), lo que significa que se conserva la mitad de las entradas. Puedes configurar este ajuste de 1.0 (100%, se conservan todas las entradas de registro) a 0.0 (0%, no se conserva ningún registro).
  • Anotaciones de metadatos: De forma predeterminada, las entradas de registro de flujo se anotan con información de metadatos, como los nombres de las VM de origen y destino o la región geográfica de fuentes y destinos externos. Las anotaciones de metadatos se pueden desactivar, o puedes especificar solo ciertas anotaciones para ahorrar espacio de almacenamiento.
  • Filtros: De forma predeterminada, se generan registros para cada flujo en la subred. Puedes establecer filtros para que solo se generen registros que coincidan con ciertos criterios.

Anotaciones de metadatos

Los registros contienen campos base y campos de metadatos. En la sección Formato del registro, se enumeran los campos que son de tipo metadatos y los que son de tipo base. Todos los campos base siempre se incluyen. Puedes personalizar qué campos de metadatos conservas.

  • Si seleccionas todos los metadatos, todos los campos de metadatos en el formato de registro Registros de flujo de VPC se incluyen en los registros de flujo. Cuando se agregan campos de metadatos nuevos al formato del registro, los registros de flujo incluyen automáticamente los campos nuevos.

  • Si no seleccionas metadatos, se omitirán todos los campos de metadatos.

  • Si seleccionas metadatos personalizados, puedes especificar los campos de metadatos que deseas incluir con el campo superior, como src_vpc, o con sus nombres completos, como src_vpc.project_id

    Cuando se agregan campos de metadatos nuevos al formato del registro, los registros de flujo no incluirán estos campos, a menos que sean un campo nuevo dentro de un campo superior que hayas especificado.

    • Si especificas metadatos personalizados con campos superiores, cuando los campos de metadatos nuevos se agreguen al formato del registro de ese campo superior, los registros de flujo incluirán automáticamente los campos nuevos.

    • Si especificas metadatos personalizados con el nombre completo del campo, cuando se agreguen campos de metadatos nuevos al campo superior, los registros de flujo no incluirán los campos nuevos.

Si quieres obtener información acerca de cómo personalizar campos de metadatos, consulta las instrucciones de gcloud CLI o la API para habilitar el registro de flujo de VPC cuando creas una subred.

Anotaciones de GKE

Los flujos que tienen un extremo en un clúster de GKE pueden anotarse con anotaciones de GKE, que pueden incluir detalles del clúster, el Pod y el Service del extremo.

Anotaciones del Service de GKE

El tráfico enviado a un ClusterIP, NodePort o LoadBalancer puede recibir anotaciones del servicio. Si se envía a un NodePort o un LoadBalancer, el flujo recibe la anotación del Service en ambos saltos de la conexión.

El tráfico enviado de forma directa al puerto de Service de un Pod se anota con una anotación del Service en el extremo de destino.

El tráfico enviado al puerto de Service de un Pod en el que el Pod está creando una copia de seguridad de más de un Service en el mismo puerto se anota con varios Service en el extremo de destino. Se limita a dos Service. Si hay más que eso, el extremo se anotará con un marcador MANY_SERVICES especial.

Anotaciones de Pod en el tráfico de Internet

De forma predeterminada, el tráfico entre un Pod e Internet no recibe anotaciones de Pod. Para los paquetes a Internet, el agente de enmascaramiento traduce la dirección IP del Pod a la dirección IP del nodo antes de que los registros de flujo de VPC vean el paquete, por lo que los registros de flujo de VPC no conocen nada del Pod y no pueden agregar anotaciones del Pod.

Debido al enmascaramiento, las anotaciones de Pod solo son visibles si los destinos se encuentran dentro de los destinos predeterminados sin enmascarar o en una lista nonMasqueradeCIDRs personalizada. Si incluyes destinos de Internet en una lista nonMasqueradeCIDRs personalizada, debes proporcionar una forma de que las direcciones IP internas del Pod se traduzcan antes de que se entreguen a Internet. Para los clústeres privados y no privados, puedes usar Cloud NAT. Consulta Interacción de GKE para obtener más detalles.

Formato del registro

Los registros contienen campos base, que son los campos principales de cada registro, y campos de metadatos que agregan información adicional. Los campos de metadatos se pueden omitir para ahorrar costos de almacenamiento.

Algunos campos de registro se encuentran en formato de varios campos y poseen más de un dato en un campo específico. Por ejemplo, el campo connection tiene el formato IpConnection, que contiene el puerto y la dirección IP de origen y destino, además del protocolo, en un solo campo. Estos campos de varios campos se describen a continuación en la tabla de formato de registros.

Campo Formato del campo Tipo del campo: base o metadatos opcionales
connection IpConnection
5 tuplas que describen esta conexión.
Capas
reporter string
El lado que reportó el flujo. Puede ser SRC o DEST.
Capas
rtt_msec int64
Latencia medida durante el intervalo de tiempo solo para flujos TCP. La latencia medida es el tiempo transcurrido entre el envío de un SEQ y la recepción de un ACK correspondiente. El resultado de la latencia es la suma del RTT de la red y el tiempo que consume la aplicación.
Capas
bytes_sent int64
Cantidad de bytes que se enviaron desde el origen hacia el destino
Capas
packets_sent int64
Cantidad de paquetes que se enviaron desde el origen hacia el destino
Capas
start_time string
Marca de tiempo (string con formato de fecha RFC 3339) del primer paquete observado durante el intervalo de tiempo agregado
Capas
hora_de_finalización string
Marca de tiempo (string con formato de fecha RFC 3339) del último paquete que se observó durante el intervalo de tiempo agregado
Capas
src_gke_details GkeDetails
Metadatos de GKE para los extremos de origen. Solo está disponible si el extremo es GKE.
Metadatos
dest_gke_details GkeDetails
Metadatos de GKE para los extremos de destino. Solo está disponible si el extremo es GKE.
Metadatos
src_instance InstanceDetails
Si la fuente de la conexión era una VM ubicada en la misma VPC, este campo se propaga con los detalles de la instancia de VM. En una configuración de VPC compartida, project_id corresponde al proyecto que posee la instancia, en general, el proyecto de servicio.
Metadatos
dest_instance InstanceDetails
Si la fuente de la conexión era una VM ubicada en la misma VPC, este campo se propaga con los detalles de la instancia de VM. En una configuración de VPC compartida, project_id corresponde al proyecto que posee la instancia, en general, el proyecto de servicio.
Metadatos
src_location GeographicDetails
Si el origen de la conexión es externo a la VPC, este campo se propaga con los metadatos de ubicación disponibles.
Metadatos
dest_location GeographicDetails
Si el destino de la conexión es externo a la VPC, este campo se propaga con los metadatos de ubicación disponibles.
Metadatos
src_vpc VpcDetails
Si la fuente de la conexión era una VM ubicada en la misma VPC, este campo se propaga con los detalles de la red de VPC. En una configuración de VPC compartida, project_id corresponde a la del proyecto host.
Metadatos
dest_vpc VpcDetails
Si el destino de la conexión era una VM ubicada en la misma VPC, este campo se propaga con los detalles de la red de VPC. En una configuración de VPC compartida, project_id corresponde a la del proyecto host.
Metadatos

Formato del campo IpConnection

Campo Tipo Descripción
protocolo int32 Número del protocolo IANA
src_ip string Dirección IP de origen
dest_ip string Dirección IP de destino
src_port int32 Puerto de origen
dest_port int32 Puerto de destino

Formato del campo GkeDetails

Campo Tipo Descripción
clúster ClusterDetails Metadatos del clúster de GKE
pod PodDetails Metadatos del Pod de GKE, propagados cuando el origen o el destino del tráfico es un Pod
servicio ServiceDetails Metadatos del Service de GKE, propagados solo en los extremos del Service. El registro contiene hasta dos Service. Si hay más de dos Service relevantes, este campo contiene un solo Service con un marcador MANY_SERVICES especial.

Formato del campo ClusterDetails

Campo Tipo Descripción
cluster_location string Ubicación del clúster. Puede ser una zona o región, dependiendo de si se trata de un clúster zonal o regional.
cluster_name string Nombre del clúster de GKE.

Formato del campo PodDetails

Campo Tipo Descripción
pod_name string Nombre del Pod.
pod_namespace string Espacio de nombres del Pod.

Formato del campo ServiceDetails

Campo Tipo Descripción
service_name string Nombre del Service. Si hay más de dos Service relevantes, el campo se configura como un marcador MANY_SERVICES especial.
service_namespace string Espacio de nombres del Service

Ejemplo:

Si hay dos servicios, el campo Service tiene el siguiente aspecto:

service: [
 0: {
  service_name: "my-lb-service"
  service_namespace: "default"
 }
 1: {
  service_name: "my-lb-service2"
  service_namespace: "default"
 }
]

Si hay más de dos servicios, el campo Service tiene el siguiente aspecto:

service: [
 0: {
  service_name: "MANY_SERVICES"
 }
]

Formato del campo InstanceDetails

Campo Tipo Descripción
project_id string ID del proyecto que contiene la VM.
region string Región de la VM
vm_name string Nombre de la instancia de la VM.
zona string Zona de la VM

Formato del campo GeographicDetails

Campo Tipo Descripción
asn int32 El número del sistema autónomo (ASN) de la red externa a la que pertenece este extremo
city string Ciudad para los extremos externos.
continent string Continente de los extremos externos.
country string País para los extremos externos, representado como un código de país de ISO 3166-1 Alpha-3.
region string Región de los extremos externos.

Formato del campo VpcDetails

Campo Tipo Descripción
project_id string ID del proyecto que contiene la VPC
subnetwork_name string Subred en la que opera la VM
vpc_name string VPC en la que opera la VM

Filtrado de registros

Cuando habilitas los registros de flujo de VPC, puedes configurar un filtro basado en los campos base y de metadatos que solo conservan los registros que coinciden con el filtro. Todos los demás registros se descartan antes de escribirse en Logging, lo que te ahorra dinero y reduce el tiempo necesario para encontrar la información que buscas.

Puedes filtrar en cualquier subconjunto de campos del formato de registro.

Los filtros de registros de flujo de VPC usan CEL, un lenguaje de expresión incorporado para las expresiones lógicas basadas en atributos. Las expresiones de filtro para los registros de flujo de VPC tienen un límite de 2,048 caracteres. Para obtener más información, consulta Operadores lógicos CEL admitidos.

Para obtener más información acerca del CEL, consulta la introducción a CEL y la definición de lenguaje. La función de filtro de generación admite un subconjunto limitado de sintaxis CEL.

Si deseas obtener información acerca de cómo crear una subred que use el filtrado de registros, consulta las instrucciones de gcloud CLI o de la API para habilitar los registros de flujo de VPC cuando creas una subred.

Si deseas obtener información para configurar el filtrado de registros, consulta gcloud CLI o las instrucciones de la API para actualizar los parámetros de registros de flujo de VPC.

Ejemplo 1: Limita la recopilación de registros a una VM específica llamada my-vm. En este caso, solo se graban los registros en los que el campo src_instance informado por la fuente del tráfico es my-vm o el campo dst_instance, como lo indica el destino del tráfico es my-vm.

gcloud compute networks subnets update my-subnet \
    --logging-filter-expr="(src_instance.vm_name == 'my-vm' && reporter=='SRC') || (dest_instance.vm_name == 'my-vm' && reporter=='DEST')"

Ejemplo 2: Limita la recopilación de registros a los paquetes cuyas direcciones IP de origen estén en la subred 10.0.0.0/8.

gcloud compute networks subnets update my-subnet \
    --logging-filter-expr="inIpRange(connection.src_ip, '10.0.0.0/8')"

Ejemplo 3: Limita la recopilación de registros al tráfico externo a una VPC.

gcloud compute networks subnets update my-subnet \
    --logging-filter-expr '!(has(src_vpc.vpc_name) && has(dest_vpc.vpc_name))'

Operadores lógicos CEL admitidos

Expresión Tipos compatibles Descripción
true, false Booleano Constantes booleanas

x == y

x !== y

Booleano, Int, String

Operadores de comparación

Ejemplo: connection.protocol == 6

x && y

x || y

Booleano

Operadores lógicos booleanos

Ejemplo: connection.protocol == 6 && src_instance.vm_name == "vm_1"

!x Booleano Negación
1, 2.0, 0, ... Int Literales numéricos constantes
x + y String Concatenación de string
"foo", 'foo', ... String Literal de string constante
x.lower() String Muestra el valor de la string en minúsculas
x.upper() String Muestra el valor de la string en mayúsculas
x.contains(y) String El resultado es verdadero si la string contiene la substring especificada
x.startsWith(y) String El resultado es verdadero si la string comienza con la substring especificada
x.endsWith(y) String El resultado es verdadero si la string termina con la substring especificada
inIpRange(X, Y) String

El resultado es verdadero si X es una IP e Y es un rango de IP que contiene X

Ejemplo: inIpRange("1.2.3.1", "1.2.3.0/24")

x.containsFieldValue(y) x: lista
y: mapa(string, string)

El resultado es verdadero si la lista contiene un objeto con campos que coinciden con los pares clave-valor especificados.

Ejemplo: dest_gke_details.service.containsFieldValue({'service_name': 'service1', 'service_namespace': 'namespace1'})

tiene(x) String

Muestra verdadero si el campo está presente.

Ejemplos de patrones de tráfico

En esta sección se explica cómo funcionan los registros de flujo de VPC en varios casos de uso.

Flujos de VM a VM en la misma red de VPC

Flujos de VM dentro de una red de VPC.
Flujos de VM dentro de una red de VPC. (Haz clic para agrandar).

En los flujos de VM a VM en la misma red de VPC, los registros de flujo se informan desde la VM que envía la solicitud y la VM que responde, siempre y cuando ambas VM estén en subredes que tengan habilitados los registros de flujo de VPC. En este ejemplo, la VM 10.10.0.2 envía una solicitud con 1,224 bytes a la VM 10.50.0.2, que también se encuentra en una subred con el registro habilitado. A su vez, 10.50.0.2 responde a la solicitud con una respuesta que contiene 5,342 bytes. La solicitud y la respuesta se registran desde ambas VM.

Informe de la VM de solicitud (10.10.0.2)
solicitud/respuesta connection.src_ip connection.dest_ip bytes_sent Anotaciones
solicitud 10.10.0.2 10.50.0.2 1,224 src_instance.*
dest_instance.*
src_vpc.*
dest_vpc.*
respuesta 10.50.0.2 10.10.0.2 5,342 src_instance.*
dest_instance.*
src_vpc.*
dest_vpc.*
Informe de la VM de respuesta (10.50.0.2)
solicitud/respuesta connection.src_ip connection.dest_ip bytes Anotaciones
solicitud 10.10.0.2 10.50.0.2 1,224 src_instance.*
dest_instance.*
src_vpc.*
dest_vpc.*
respuesta 10.50.0.2 10.10.0.2 5,342 src_instance.*
dest_instance.*
src_vpc.*
dest_vpc.*

Flujos de VM a una dirección IP externa

Flujos de VM a una dirección IP externa.
Flujos de VM a una dirección IP externa (haz clic para ampliar).

En los flujos que pasan por Internet entre una VM que está en una red de VPC y un extremo con una dirección IP externa, los registros de flujo se informan solo desde la VM que está en la red de VPC:

  • En los flujos de salida, los registros se informan desde la VM de red de VPC que es la fuente del tráfico.
  • En los flujos de entrada, los registros se informan desde la VM de red de VPC que es el destino del tráfico.

En este ejemplo, la VM 10.10.0.2 intercambia paquetes a través de Internet con un extremo que tiene la dirección IP externa 203.0.113.5. El tráfico de salida de 1,224 bytes que se envía de 10.10.0.2 a 203.0.113.5 se registra desde la VM de origen, 10.10.0.2. El tráfico de entrada de 5,342 bytes que se envía de 203.0.113.5 a 10.10.0.2 se registra desde el destino del tráfico, la VM 10.10.0.2.

solicitud/respuesta connection.src_ip connection.dest_ip bytes_sent Anotaciones
solicitud 10.10.0.2 203.0.113.5 1,224 src_instance.*
src_vpc.*
dest_location.*
respuesta 203.0.113.5 10.10.0.2 5,342 dest_instance.*
dest_vpc.*
src_location.*

Flujos de VM a las instalaciones

Flujos de VM a las instalaciones.
Flujos de VM a una ubicación local (haz clic para ampliar)

En los flujos entre una VM que está en una red de VPC y un extremo local con una dirección IP interna, los registros de flujo se informan solo desde la VM que está en la red de VPC:

  • En los flujos de salida, los registros se informan desde la VM de red de VPC que es la fuente del tráfico.
  • En los flujos de entrada, los registros se informan desde la VM de red de VPC que es el destino del tráfico.

En este ejemplo, la VM 10.10.0.2 y el extremo local 10.30.0.2 se conectan a través de una puerta de enlace de VPN o de Cloud Interconnect. El tráfico de salida de 1,224 bytes que se envía de 10.10.0.2 a 10.30.0.2 se registra desde la VM de origen, 10.10.0.2. El tráfico de entrada de 5,342 bytes que se envía de 10.30.0.2 a 10.10.0.2 se registra desde el destino del tráfico, la VM 10.10.0.2.

solicitud/respuesta connection.src_ip connection.dest_ip bytes_sent Anotaciones
solicitud 10.10.0.2 10.30.0.2 1,224 src_instance.*
src_vpc.*
respuesta 10.30.0.2 10.10.0.2 5,342 dest_instance.*
dest_vpc.*

Flujos de VM a VM para una VPC compartida

Flujos de VPC compartida.
Flujos de VPC compartida (haz clic para ampliar).

En los flujos de VM a VM en una VPC compartida, puedes habilitar los registros de flujo de VPC en la subred del proyecto host. Por ejemplo, la subred 10.10.0.0/20 pertenece a una red de VPC compartida que se define en un proyecto host. Puedes ver los registros de flujo de las VM que pertenecen a esta subred, incluidas las que se crean para proyectos de servicio. En este ejemplo, los proyectos de servicio se llaman “webserver” (servidor web), “recommendation” (recomendación), “database” (base de datos).

En los flujos de VM a VM, cuando ambas VM se encuentran en el mismo proyecto (o en el caso de una red compartida, en el mismo proyecto host) se le proporciona, al otro extremo de la conexión, las anotaciones para el ID del proyecto y datos similares. Si la otra VM se encuentra en un proyecto diferente, no se proporcionan las anotaciones para la otra VM.

En la siguiente tabla, se muestra un flujo que registra 10.10.0.10 o 10.10.0.20.

  • src_vpc.project_id y dest_vpc.project_id son para el proyecto host porque la subred de VPC pertenece a él.
  • src_instance.project_id y dest_instance.project_id son para los proyectos de servicio porque las instancias pertenecen a ellos.
connection
.src_ip
src_instance
.project_id
src_vpc
.project_id
connection
.dest_ip
dest_instance
.project_id
dest_vpc
.project_id
10.10.0.10 webserver host_project 10.10.0.20 recommendation host_project

Los proyectos de servicio no son propietarios de la red de VPC compartida y no tienen acceso a los registros de flujo de la red de VPC compartida.

Flujos de VM a VM para el intercambio de tráfico entre redes de VPC

Flujos de intercambio de tráfico de red de VPC (haz clic para ampliar)
Flujos de intercambio de tráfico de red de VPC (haz clic para ampliar).

A menos que ambas VM se encuentren en el mismo proyecto de Google Cloud, los flujos de VM para las redes de intercambio de tráfico se informan de la misma manera que en los extremos externos: la información del proyecto y otras anotaciones no se proporcionan a la otra VM. Si ambas VM se encuentran en el mismo proyecto, incluso en redes diferentes, sí se proporciona a la otra VM la información del proyecto y otras anotaciones.

En este ejemplo, las subredes de la VM 10.10.0.2 del proyecto analytics-prod y de la VM 10.50.0.2 del proyecto webserver-test se conectan a través del intercambio de tráfico de redes de VPC. Si los registros de flujo de VPC están habilitados en el proyecto analytics-prod, el tráfico (1,224 bytes) que se envía de 10.10.0.2 a 10.50.0.2 se registra desde la VM 10.10.0.2, que es el origen del flujo. El tráfico (5,342 bytes) que se envía de 10.50.0.2 a 10.10.0.2 también se registra desde la VM 10.10.0.2, que es el destino del flujo.

En este ejemplo, los registros de flujo de VPC no se encuentran habilitados en el proyecto webserver-test, por lo que la VM 10.50.0.2 no realiza registros.

reporter connection.src_ip connection.dest_ip bytes_sent Anotaciones
source 10.10.0.2 10.50.0.2 1,224 src_instance.*
src_vpc.*
destination 10.50.0.2 10.10.0.2 5,342 dest_instance.*
dest_vpc.*

Flujos de VM a VM para balanceadores de cargas de red de transferencia interna

Flujos del balanceador de cargas de red de transferencia interna (haz clic para ampliar).
Flujos del balanceador de cargas de red de transferencia interna (haz clic para ampliar).

Cuando agregas una VM al servicio de backend para un balanceador de cargas de red de transferencia interna, el entorno invitado de Linux o Windows agrega la dirección IP del balanceador de cargas a la tabla de enrutamiento local de la VM. Esto permite que la VM acepte paquetes de solicitud con destinos establecidos en la dirección IP del balanceador de cargas. Cuando la VM responde, envía su respuesta de forma directa; sin embargo, la dirección IP de origen de los paquetes de respuesta está configurada en la dirección IP del balanceador de cargas, y no en la VM del balanceo de cargas.

Los flujos de VM a VM que se envían a través de un balanceador de cargas de red de transferencia interno se informan desde el origen y el destino. En la siguiente tabla se explican los campos de entrada de registro del flujo observados para un ejemplo de par solicitud-respuesta HTTP. A los fines de esta ilustración, considera la siguiente configuración de red:

  • Instancia del navegador en 192.168.1.2
  • Balanceador de cargas de red de transferencia interno en 10.240.0.200
  • Instancia del servidor web en 10.240.0.3
Dirección del tráfico reporter connection.src_ip connection.dest_ip connection.src_instance connection.dest_instance
Solicitud SRC 192.168.1.2 10.240.0.200 Instancia del navegador
Solicitud DEST 192.168.1.2 10.240.0.200 Instancia del navegador Instancia de webserver
Respuesta SRC 10.240.0.3 192.168.1.2 Instancia de webserver Instancia del navegador
Respuesta DEST 10.240.0.200 192.168.1.2 Instancia del navegador

La VM que envía la solicitud no sabe qué VM responderá. Además, debido a que la otra VM envía una respuesta con la IP del balanceador de cargas interno como la dirección de origen, no sabe qué VM respondió. Por estos motivos, la VM que envía la solicitud no puede agregar información de dest_instance a su registro, solo información de src_instance. Debido a que la VM que responde conoce la dirección IP de la otra VM, puede proporcionar información de src_instance y dest_instance.

Flujo de Pod a ClusterIP

Flujo de Pod a la IP del clúster (haz clic para ampliar).
Flujo de Pod a la IP del clúster (haz clic para ampliar).

En este ejemplo, el tráfico se envía desde el Pod cliente (10.4.0.2) a cluster-service (10.0.32.2:80). El destino se resuelve en la dirección IP del Pod del servidor si seleccionas (10.4.0.3) en el puerto de destino (8080).

En los bordes del nodo, el flujo se muestra dos veces con la dirección IP y el puerto traducidos. Para ambos puntos de muestreo, identificaremos que el Pod de destino respalda el servicio cluster-service en el puerto 8080 y anotamos el registro con los detalles del Service y los detalles del Pod. En caso de que el tráfico se enrute a un Pod en el mismo nodo, el tráfico no sale del nodo y no se muestrea en absoluto.

En este ejemplo, se encuentran los siguientes registros.

reporter connection.src_ip connection.dst_ip bytes_sent Anotaciones
SRC 10.4.0.2 10.4.0.3 1,224 src_instance.*
src_vpc.*
src_gke_details.cluster.*
src_gke_details.pod.*
dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.pod.*
dest_gke_details.service.*
DEST 10.4.0.2 10.4.0.3 1,224 src_instance.*
src_vpc.*
src_gke_details.cluster.*
src_gke_details.pod.*
dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.pod.*
dest_gke_details.service.*

Flujos de balanceador de carga externo de GKE

Flujos del balanceador de cargas externo (haz clic para ampliar).
Flujos del balanceador de cargas externo (haz clic para ampliar).

El tráfico de una dirección IP externa a un servicio de GKE (35.35.35.35) se enruta a un nodo en el clúster, 10.0.12.2 en este ejemplo, para el enrutamiento. De forma predeterminada, los balanceadores de cargas de red de transferencia externos distribuyen el tráfico entre todos los nodos del clúster, incluso aquellos que no ejecutan un Pod relevante. El tráfico puede necesitar saltos adicionales para llegar al Pod relevante. Para obtener más información, consulta Herramientas de redes fuera del clúster.

El tráfico se enruta desde el nodo (10.0.12.2) hacia el Pod de servidor seleccionado (10.4.0.2). Ambos saltos se registran porque se realizan muestras de todos los perímetros de los nodos. En caso de que el tráfico se enrute a un Pod en el mismo nodo, 10.4.0.3 en este ejemplo, el segundo salto no se registrará, porque no sale del nodo. El segundo salto se registra en los puntos de muestreo de ambos nodos. El segundo salto se registra en los puntos de muestreo de ambos nodos. Para el primer salto, identificamos el Service según la IP del balanceador de cargas y el puerto del Service (80). Para el segundo salto, identificamos que el Pod de destino respalda el Service en el puerto de destino (8080).

En este ejemplo, se encuentran los siguientes registros.

reporter connection.src_ip connection.dst_ip bytes_sent Anotaciones
DEST 203.0.113.1 35.35.35.35 1,224 src_location.*
dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.service.*
SRC 10.0.12.2 10.4.0.2 1,224 src_instance.*
src_vpc.*
src_gke_details.cluster.*
dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.pod.*
dest_gke_details.service.*
DEST 10.0.12.2 10.4.0.2 1,224 src_instance.*
src_vpc.*
src_gke_details.cluster.*
dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.pod.*
dest_gke_details.service.*

Flujos de ingreso de GKE

Flujos de ingreso (haz clic para ampliar).
Flujos de ingreso (haz clic para ampliar).

Una conexión de una dirección IP pública a un destino de ingreso finaliza en el Servicio del balanceador de cargas. La conexión se mapea a un Service NodePort, según la URL. Para entregar la solicitud, el balanceador de cargas (130.211.0.1) se conecta a uno de los nodos del clúster (10.0.12.2) para el enrutamiento a través del NodePort del Service. De forma predeterminada, cuando se crea un Ingress, el controlador de Ingress de GKE configura un balanceador de cargas de HTTP(S) que distribuye el tráfico en todos los nodos del clúster, incluso aquellos que no ejecutan un Pod relevante. El tráfico puede necesitar saltos adicionales para llegar al Pod relevante. Para obtener más información, consulta Herramientas de redes fuera del clúster. El tráfico se enruta desde el nodo (10.0.12.2) hacia el Pod de servidor seleccionado (10.4.0.2).

Ambos saltos se registran porque se realizan muestras de todos los perímetros de los nodos. Para el primer salto, se identifica el Service según su NodePort (60000). Para el segundo salto, se comprueba que el Pod de destino respalde el Service en el puerto de destino (8080). El segundo salto se registra en los puntos de muestreo de ambos nodos. Sin embargo, en un caso en el que el tráfico se enruta a un Pod en el mismo nodo (10.4.0.3), el segundo salto no se registra porque el tráfico no abandonó el nodo.

En este ejemplo, se encuentran los siguientes registros.

reporter connection.src_ip connection.dst_ip bytes_sent Anotaciones
DEST 130.211.0.1 10.0.12.2 1,224 dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.service.*
SRC 10.0.12.2 10.4.0.2 1,224 src_instance.*
src_vpc.*
src_gke_details.cluster.*
dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.pod.*
dest_gke_details.service.*
DEST 10.0.12.2 10.4.0.2 1,224 src_instance.*
src_vpc.*
src_gke_details.cluster.*
dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.pod.*
dest_gke_details.service.*

Flujos de ingreso de GKE con el balanceo de cargas nativo del contenedor

Flujos de ingreso a través del balanceo de cargas nativo del contenedor (haz clic para ampliar).
Flujos de ingreso con el balanceo de cargas nativo del contenedor (haz clic para ampliar).

Las solicitudes de una dirección IP pública a un Ingress que usa el balanceo de cargas nativo del contenedor finalizan en el balanceador de cargas. En este tipo de Ingress, los Pods son objetos principales para el balanceo de cargas. Luego, se envía una solicitud desde el balanceador de cargas (130.211.0.1) de forma directa a un Pod seleccionado (10.4.0.2). Identificamos que el Pod de destino respalda al Service en el puerto de destino (8080).

En este ejemplo, se encuentra el siguiente registro.

reporter connection.src_ip connection.dst_ip bytes_sent Anotaciones
DEST 130.211.0.1 10.4.0.2 1,224 dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.pod.*
dest_gke_details.service.*

Pod al flujo externo

Pod al flujo externo (haz clic para ampliar).
Pod al flujo externo (haz clic para ampliar).

El tráfico de un Pod (10.4.0.3) a una IP externa (203.0.113.1) se modifica con el enmascaramiento de IP para que los paquetes se envíen desde la IP del nodo (10.0.12.2) en lugar de la IP del Pod. De forma predeterminada, el clúster de GKE está configurado para enmascarar el tráfico a destinos externos. Para obtener más información, consulta agente de enmascaramiento de IP.

Si quieres ver las anotaciones de Pod de este tráfico, puedes configurar el agente de enmascaramiento para que no enmascare las IP de los Pods. En ese caso, para permitir el tráfico a Internet, puedes configurar Cloud NAT, que procesa las direcciones IP del Pod. Para obtener más información acerca de Cloud NAT con GKE, consulta la interacción de GKE.

En este ejemplo, se encuentra el siguiente registro.

reporter connection.src_ip connection.dst_ip bytes_sent Anotaciones
SRC 10.0.12.2 203.0.113.1 1,224 src_instance.*
src_vpc.*
src_gke_details.cluster.*
dest_location.*

Precios

Se aplicará el precio estándar para Logging, BigQuery o Pub/Sub. El precio de los registros de flujo de VPC se describe en Precios de telemetría de red.

Preguntas frecuentes

  • ¿Los registros de flujo de VPC incluyen el tráfico permitido y el rechazado en función de las reglas de firewall?

    • Los registros de flujo de VPC incluyen el tráfico desde la perspectiva de una VM. Se registra todo el tráfico de salida (saliente) de una VM, incluso si está bloqueado por una regla de firewall de denegación de salida. El tráfico de entrada (entrante) se registra si una regla de firewall de entrada lo permite. El tráfico de entrada bloqueado por una regla de firewall de denegación de entrada no se registra.
  • ¿Los registros de flujo de VPC funcionan con instancias de VM con interfaces múltiples?

  • ¿Los registros de flujo de VPC funcionan con redes heredadas?

    • No, los registros de flujo de VPC no son compatibles con las redes heredadas.

¿Qué sigue?