Acerca de los flujos de tráfico

En esta página, se describe cómo los registros de flujo de VPC informan los registros de flujo para casos de uso comunes. Consulta las siguientes secciones para ver ejemplos de flujos de tráfico de muestra por medio de registros de flujo de VPC.

Flujos de VM a VM en la misma 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.*

VM-to-external-IP-address flows

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

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

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

En este ejemplo, la VM 10.10.0.2 intercambia paquetes por 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.* internet_routing_details.*
reply	203.0.113.5	10.10.0.2	5,342	dest_instance.* dest_vpc.* src_location.*

VM-to-on-premises flows

Flujos de una VM a entornos locales (haz clic para ampliar).

Para 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 desde la VM que está en la red de VPC solo:

• Para los flujos de salida, los registros se informan desde la VM de la red de VPC que es el origen del tráfico.
• Para los flujos de entrada, los registros se informan desde la VM de la 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 (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	web server	host_project	10.10.0.20	recommendation	host_project

Los proyectos de servicio no son propietarios de la red de VPC compartida ni 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).

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

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

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

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

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

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.* internet_routing_details.*

¿Qué sigue?

• Configura los registros de flujo de VPC
• Accede a los registros de flujo