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 dentro de Google Cloud o entre Google Cloud y otras redes. 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.
- Los registros de flujo de VPC no se informan desde recursos que no son de VM, como Cloud Run o extremos locales.
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:
- 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.
- 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.
- 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.
- 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.
- 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) a0.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, comosrc_vpc.project_idCuando 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 que se enumeran en formato de registro, excepto los siguientes campos:
rtt_msecbytes_sentpackets_sentstart_timeend_time
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
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
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
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
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_idydest_vpc.project_idson para el proyecto host porque la subred de VPC pertenece a él.src_instance.project_idydest_instance.project_idson 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
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
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
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
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
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
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
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?
- Sí, puedes habilitar los registros de flujo de VPC para todas las interfaces en una VM con varias interfaces.
¿Los registros de flujo de VPC funcionan con redes heredadas?
- No, los registros de flujo de VPC no son compatibles con las redes heredadas.