Acerca de los flujos de tráfico

En esta página se describe cómo registra VPC Flow Logs los flujos de tráfico habituales. Consulta los siguientes ejemplos:

• Los flujos de VMs, los flujos de GKE y los flujos de conectividad híbrida describen los flujos dentro de Google Cloud y los flujos entre Google Cloud y los recursos fuera de Google Cloud. En los ejemplos de flujos entre diferentes proyectos, se da por hecho que los registros de flujo de VPC están configurados a nivel de proyecto.Google Cloud
• En Flujos entre redes de VPC de distintos proyectos, se describe cómo se anotan los flujos entre proyectos cuando se configuran los registros de flujo de VPC a nivel de organización.

Flujos de máquinas virtuales

En las siguientes secciones se muestran ejemplos de cómo Registros de flujo de VPC anota los flujos de tráfico desde y hacia las instancias de máquina virtual (VM).

Flujos entre VMs de la misma red de VPC

En el caso de los flujos entre VMs de la misma red de VPC, los registros de flujo se generan tanto en la VM que envía la solicitud como en la que responde, siempre que ambas VMs estén en subredes en las que se hayan habilitado los registros de flujo de VPC. En este ejemplo, la VM 10.10.0.2 envía una solicitud de 1224 bytes a la VM 10.50.0.2, que también está en una subred que tiene el registro habilitado. A su vez, 10.50.0.2 responde a la solicitud con una respuesta que contiene 5342 bytes. Tanto la solicitud como la respuesta se registran en las VMs que envían la solicitud y las que responden.

Según lo indicado por la VM que realiza la 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	1224	src_instance.* src_vpc.* dest_instance.* dest_vpc.*
responder	10.50.0.2	10.10.0.2	5342	src_instance.* src_vpc.* dest_instance.* dest_vpc.*

Según la VM que responde (10.50.0.2)
Solicitud/respuesta	connection.src_ip	connection.dest_ip	bytes_sent	Anotaciones
solicitud	10.10.0.2	10.50.0.2	1224	src_instance.* src_vpc.* dest_instance.* dest_vpc.*
responder	10.50.0.2	10.10.0.2	5342	src_instance.* src_vpc.* dest_instance.* dest_vpc.*

Flujos de máquina virtual a dirección IP externa

En el caso de los flujos que atraviesan Internet entre una máquina virtual que está en una red de VPC y un endpoint con una dirección IP externa, los registros de flujo solo se notifican desde la máquina virtual que está en la red de VPC:

• En el caso de los flujos de salida, los registros se notifican desde la VM de la red de VPC que es la fuente del tráfico.
• En el caso de los flujos de entrada, los registros se notifican 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 a través de Internet con un endpoint que tiene la dirección IP externa 203.0.113.5. El tráfico de salida de 1224 bytes enviado desde 10.10.0.2 a 203.0.113.5 se registra en la VM de origen, 10.10.0.2. El tráfico de entrada de 5342 bytes enviado desde 203.0.113.5 a 10.10.0.2 se registra desde el destino del tráfico, la máquina virtual 10.10.0.2.

Solicitud/respuesta	connection.src_ip	connection.dest_ip	bytes_sent	Anotaciones
solicitud	10.10.0.2	203.0.113.5	1224	src_instance.* src_vpc.* dest_location.* internet_routing_details.*
responder	203.0.113.5	10.10.0.2	5342	src_location.* dest_instance.* dest_vpc.*

Flujos de VM a VM en VPC compartida

En el caso de los flujos de VM a VM de la 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 definida en un proyecto host. Puedes ver los registros de flujo de las máquinas virtuales que pertenecen a esta subred, incluidas las creadas por proyectos de servicio. En este ejemplo, los proyectos de servicio se denominan "web server", "recommendation" y "database".

En el caso de los flujos entre máquinas virtuales, si ambas están en el mismo proyecto o en el mismo proyecto host (en el caso de una red compartida), se proporcionan anotaciones para el ID de proyecto y similares para el otro endpoint de la conexión. Si la otra VM está en un proyecto diferente, no se proporcionan anotaciones para la otra VM.

En la siguiente tabla se muestra un flujo tal como lo registran 10.10.0.10 o 10.10.0.20.

• src_vpc.project_id y dest_vpc.project_id son para el proyecto host, ya que la subred de VPC pertenece a este proyecto.
• src_instance.project_id y dest_instance.project_id son para los proyectos de servicio porque las instancias pertenecen a los proyectos de servicio.

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	servidor web	host_project	10.10.0.20	recomendación	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 entre VMs para el emparejamiento entre redes de VPC

A menos que ambas máquinas virtuales estén en el mismo Google Cloud proyecto, los flujos entre máquinas virtuales de redes de VPC emparejadas se registran de la misma forma que los de los endpoints externos: no se proporciona el proyecto ni otra información de anotación de la otra máquina virtual. Si ambas máquinas virtuales están en el mismo proyecto, aunque estén en redes diferentes, también se proporciona información del proyecto y otras anotaciones para la otra máquina virtual.

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 están conectadas mediante el emparejamiento entre redes de VPC. Si Registros de flujo de VPC está habilitado en el proyecto analytics-prod, el tráfico (1224 bytes) enviado de 10.10.0.2 a 10.50.0.2 se registra desde la VM 10.10.0.2, que es la fuente del flujo. El tráfico (5342 bytes) enviado de 10.50.0.2 a 10.10.0.2 también se registra en la máquina virtual 10.10.0.2, que es el destino del flujo.

En este ejemplo, los registros de flujo de VPC no están activados en el proyecto webserver-test, por lo que la VM 10.50.0.2 no registra ningún registro.

reportero	connection.src_ip	connection.dest_ip	bytes_sent	Anotaciones
fuente	10.10.0.2	10.50.0.2	1224	src_instance.* src_vpc.*
destino	10.50.0.2	10.10.0.2	5342	dest_instance.* dest_vpc.*

Flujos de VM a VM a través de Private Service Connect

Registros de flujo de VPC anota los flujos entre los consumidores de Private Service Connect y los servicios publicados. En el siguiente ejemplo se describe cómo anota Registros de flujo de VPC los registros de las máquinas virtuales de consumidor y productor.

El tráfico a los servicios publicados de Private Service Connect se registra tanto en las VMs de consumidor como en las de productor, siempre que ambas VMs estén en subredes que tengan habilitados los registros de flujo de VPC. En este ejemplo, la VM de consumidor, 10.10.0.2, envía una solicitud de 1224 bytes al endpoint de Private Service Connect, 10.10.0.3. En la VPC del productor, la dirección IP de origen de la solicitud se traduce a una dirección IP de la subred del adjunto de servicio, que, en este ejemplo, es 10.40.0.2. La dirección IP de destino de la solicitud se traduce a la dirección IP del balanceador de carga de red de paso a través interno, 10.50.0.3. A continuación, la solicitud llega a la máquina virtual de backend, 10.50.0.2, que también está en una subred que tiene el registro habilitado. A su vez, 10.50.0.2 responde a la solicitud con una respuesta que contiene 5342 bytes. Tanto la solicitud como la respuesta se registran en las máquinas virtuales que envían la solicitud y las que responden. Los registros de la VM del consumidor están disponibles en el proyecto del consumidor, y los registros de la VM del productor están disponibles en el proyecto del productor.

Según la VM del consumidor (10.10.0.2)
Solicitud/respuesta	connection.src_ip	connection.dest_ip	bytes_sent	Anotaciones
solicitud	10.10.0.2	10.10.0.3	1224	src_instance.* src_vpc.* psc.reporter psc.psc_endpoint.* psc.psc_attachment.*
responder	10.10.0.3	10.10.0.2	5342	dest_instance.* dest_vpc.* psc.reporter psc.psc_endpoint.* psc.psc_attachment.*

Según lo informado por la VM de productor (10.50.0.2)
Solicitud/respuesta	connection.src_ip	connection.dest_ip	bytes_sent	Anotaciones
solicitud	10.40.0.2	10.50.0.3	1224	dest_instance.* dest_vpc.* psc.reporter psc.psc_attachment.*
responder	10.50.0.3	10.40.0.2	5342	src_instance.* src_vpc.* psc.reporter psc.psc_attachment.*

Flujos de la API de VM a Google

En el caso del tráfico de máquinas virtuales a las APIs de Google a través de la dirección IP externa de la máquina virtual, el acceso privado de Google o un endpoint de Private Service Connect, los registros de flujo de VPC anotan los registros con información de las APIs de Google.

En el siguiente ejemplo se describe cómo anota VPC Flow Logs los registros de una máquina virtual que accede a una API global de Google a través de un endpoint de Private Service Connect.

Las VMs de consumidor informan del tráfico a una API de Google siempre que la VM esté en una subred que tenga habilitados los registros de flujo de VPC. En este ejemplo, la VM de consumidor, 10.10.0.2, envía una solicitud de 1224 bytes al endpoint de Private Service Connect, 10.10.110.10. La solicitud se reenvía al servicio de Google correspondiente, como Cloud Storage. A su vez, Cloud Storage responde a la solicitud con una respuesta que contiene 5342 bytes. Tanto la solicitud como la respuesta se registran desde la VM que realiza la solicitud.

Según la VM del consumidor (10.10.0.2)
Solicitud/respuesta	connection.src_ip	connection.dest_ip	bytes_sent	Anotaciones
solicitud	10.10.0.2	10.10.110.10	1224	src_instance.* src_vpc.* dest_google_service.* psc.reporter psc.psc_endpoint.*
responder	10.10.110.10	10.10.0.2	5342	src_google_service.* dest_instance.* dest_vpc.* psc.reporter psc.psc_endpoint.*

Flujos de máquinas virtuales a través de Cloud Load Balancing

Registros de flujo de VPC anota el tráfico enviado a través de un balanceador de carga de red con paso a través, un balanceador de carga de red de proxy o un balanceador de carga de aplicaciones. En los siguientes ejemplos se da por hecho que estos balanceadores de carga están configurados como balanceadores de carga internos.

Flujos de VM a VM a través de un balanceador de carga de red de paso a través interno

Cuando añades una VM al servicio de backend de un balanceador de carga de red de paso a través interno, Google Cloud se añade la dirección IP del balanceador de carga a la tabla de enrutamiento local de la VM. De esta forma, la VM puede aceptar paquetes de solicitud con destinos definidos en la dirección IP del balanceador de carga. Cuando la VM responde, envía su respuesta directamente. Sin embargo, la dirección IP de origen de los paquetes de respuesta se establece en la dirección IP del balanceador de carga, no en la de la VM que se está balanceando.

Los flujos entre VMs enviados a través de un balanceador de carga de red de paso a través interno se registran tanto en el origen como en el destino.

Según ha informado la VM cliente (192.168.1.2)
Solicitud/respuesta	connection.src_ip	connection.dest_ip	bytes_sent	Anotaciones
solicitud	192.168.1.2	10.240.0.200	1224	src_instance.* src_vpc.* load_balancing.forwarding_rule_project_id load_balancing.reporter load_balancing.type load_balancing.scheme load_balancing.forwarding_rule_name load_balancing.backend_service_name load_balancing.vpc.*
responder	10.240.0.200	192.168.1.2	5342	dest_instance.* dest_vpc.* load_balancing.forwarding_rule_project_id load_balancing.reporter load_balancing.type load_balancing.scheme load_balancing.forwarding_rule_name load_balancing.backend_service_name load_balancing.vpc.*

Según la VM backend (10.240.0.3)
Solicitud/respuesta	connection.src_ip	connection.dest_ip	bytes_sent	Anotaciones
solicitud	192.168.1.2	10.240.0.200	1224	src_instance.* src_vpc.* dest_instance.* dest_vpc.* load_balancing.* (todos los campos excepto url_map_name)
responder	10.240.0.200	192.168.1.2	5342	src_instance.* src_vpc.* dest_instance.* dest_vpc.* load_balancing.* (todos los campos excepto url_map_name)

En la solicitud que el balanceador de carga distribuye a la VM de backend, la dirección IP de origen se define como la dirección IP de la VM de cliente. Esto significa que la VM backend puede proporcionar información sobre src_instance y dest_instance de la VM cliente. Sin embargo, a diferencia de la VM de backend, la VM de cliente no puede añadir información sobre src_instance y dest_instance de la VM de backend a su informe porque envía la solicitud a la dirección IP del balanceador de carga y recibe la respuesta de esta, no de la VM de backend.

El tráfico de la VM pasa por un balanceador de carga de red con proxy interno o por un balanceador de carga de aplicaciones interno

Las VMs de cliente registran el tráfico que fluye a través de un balanceador de carga de red con proxy interno o un balanceador de carga de aplicaciones interno, siempre que la VM de cliente esté en una subred que tenga habilitados los registros de flujo de VPC. Por ejemplo, una VM cliente con la dirección IP 10.10.0.2 envía una solicitud de 1224 bytes al endpoint del balanceador de carga, 10.10.0.3. A continuación, la solicitud llega a un backend. A su vez, el backend responde a la solicitud con una respuesta que contiene 5342 bytes. Tanto la solicitud como la respuesta se registran en la VM del cliente. Los registros de la VM cliente están disponibles en el Google Cloud proyecto al que pertenece la VM.

Según la VM del cliente (10.10.0.2)
Solicitud/respuesta	connection.src_ip	connection.dest_ip	bytes_sent	Anotaciones
solicitud	10.10.0.2	10.10.0.3	1224	src_instance.* src_vpc.* load_balancing.forwarding_rule_project_id load_balancing.reporter load_balancing.type load_balancing.scheme load_balancing.url_map_name (for Application Load Balancer) load_balancing.forwarding_rule_name load_balancing.vpc.*
responder	10.10.0.3	10.10.0.2	5342	dest_instance.* dest_vpc.* load_balancing.forwarding_rule_project_id load_balancing.reporter load_balancing.type load_balancing.scheme load_balancing.url_map_name (for Application Load Balancer) load_balancing.forwarding_rule_name load_balancing.vpc.*

Flujos de GKE

En las siguientes secciones se muestran ejemplos de cómo los registros de flujo de VPCs anotan el tráfico de GKE desde y hacia los pods.

Flujo de Pod a ClusterIP

En este ejemplo, el tráfico se envía del pod del 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 seleccionado (10.4.0.3) en el puerto de destino (8080).

En los bordes de los nodos, el flujo se muestrea dos veces con la dirección IP y el puerto traducidos. En ambos puntos de muestreo, identificaremos que el pod de destino está respaldando el servicio cluster-service en el puerto 8080 y anotaremos el registro con los detalles del servicio y del pod. Si el tráfico se dirige a un pod del mismo nodo, no sale del nodo y no se muestrea.

En este ejemplo, se encuentran los siguientes registros.

reportero	connection.src_ip	connection.dst_ip	bytes_sent	Anotaciones
SRC	10.4.0.2	10.4.0.3	1224	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	1224	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 LoadBalancer externo de GKE

El tráfico de una dirección IP externa a un servicio de GKE (35.35.35.35) se dirige a un nodo del clúster (10.0.12.2 en este ejemplo) para enrutarlo. De forma predeterminada, los balanceadores de carga de red de paso a través externos distribuyen el tráfico entre todos los nodos del clúster, incluso entre los que no ejecutan un pod relevante. Es posible que el tráfico tenga que dar saltos adicionales para llegar al pod correspondiente. Para obtener más información, consulta Redes fuera del clúster.

A continuación, el tráfico se enruta desde el nodo (10.0.12.2) al pod del servidor seleccionado (10.4.0.2). Se registran ambos saltos porque se toman muestras de todos los bordes de los nodos. Si el tráfico se dirige a un pod del 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. En el primer salto, identificamos el servicio en función de la IP del balanceador de carga y del puerto del servicio (80). En el segundo salto, identificamos que el pod de destino está respaldando el servicio en el puerto de destino (8080).

En este ejemplo, se encuentran los siguientes registros.

reportero	connection.src_ip	connection.dst_ip	bytes_sent	Anotaciones
DEST	203.0.113.1	35.35.35.35	1224	src_location.* dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.service.*
SRC	10.0.12.2	10.4.0.2	1224	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	1224	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 Ingress de GKE

Una conexión desde una dirección IP externa a un destino de Ingress se termina en el servicio Cloud Load Balancing. La conexión se asigna a un servicio NodePort según la URL. Para atender la solicitud, el balanceador de carga (130.211.0.1) se conecta a uno de los nodos del clúster (10.0.12.2) para enrutarla mediante el NodePort del servicio. De forma predeterminada, al crear un objeto Ingress, el controlador Ingress de GKE configura un balanceador de carga HTTP(S) que distribuye el tráfico entre todos los nodos del clúster, incluso entre los que no ejecutan un pod relevante. Es posible que el tráfico tenga que dar más saltos para llegar al pod correspondiente. Para obtener más información, consulta Redes fuera del clúster. A continuación, el tráfico se dirige desde el nodo (10.0.12.2) al pod del servidor seleccionado (10.4.0.2).

Ambos saltos se registran porque se muestrean todos los bordes de los nodos. En el primer salto, identificamos el servicio en función de su NodePort (60000). En el segundo salto, identificamos que el pod de destino está detrás del servicio en el puerto de destino (8080). Los puntos de muestreo de ambos nodos registran el segundo salto. Sin embargo, en el caso de que el tráfico se dirija a un pod del mismo nodo (10.4.0.3), el segundo salto no se registra porque el tráfico no ha salido del nodo.

En este ejemplo, se encuentran los siguientes registros.

reportero	connection.src_ip	connection.dst_ip	bytes_sent	Anotaciones
DEST	130.211.0.1	10.0.12.2	1224	dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.service.*
SRC	10.0.12.2	10.4.0.2	1224	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	1224	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 Ingress de GKE que usan el balanceo de carga nativo de contenedores

Las solicitudes de una dirección IP externa a un destino de Ingress que usa el balanceo de carga nativo de contenedores se terminan en el balanceador de carga. En este tipo de Ingress, los pods son objetos principales para el balanceo de carga. A continuación, el balanceador de carga (130.211.0.1) envía una solicitud directamente a un pod seleccionado (10.4.0.2). Identificamos que el pod de destino está detrás del servicio en el puerto de destino (8080).

En este ejemplo, se encuentra el siguiente registro.

reportero	connection.src_ip	connection.dst_ip	bytes_sent	Anotaciones
DEST	130.211.0.1	10.4.0.2	1224	dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.pod.* dest_gke_details.service.*

Pod a flujos externos

La suplantación de IP modifica el tráfico de un pod (10.4.0.3) a una IP externa (203.0.113.1) para que los paquetes se envíen desde la IP del nodo (10.0.12.2) en lugar de desde la dirección 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.

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

En este ejemplo, se encuentra el siguiente registro.

reportero	connection.src_ip	connection.dst_ip	bytes_sent	Anotaciones
SRC	10.0.12.2	203.0.113.1	1224	src_instance.* src_vpc.* src_gke_details.cluster.* dest_location.* internet_routing_details.*

Flujos de conectividad híbrida

En el caso de la conectividad híbrida a través de las asignaciones de VLAN para túneles de Cloud Interconnect y Cloud VPN, Registros de flujos de VPC anota los siguientes flujos:

• Flujos entre instancias de VM, incluidas las instancias usadas como nodos de GKE, y los endpoints locales
• Flujos entre servicios de Google y endpoints locales
• Flujos de tránsito entre endpoints locales

En el siguiente ejemplo se describe cómo Registros de flujo de VPC anota los flujos entre una instancia de VM de una red de VPC y un endpoint local. La red está conectada al endpoint a través de una vinculación de VLAN para Cloud Interconnect.

En el caso de los flujos entre una VM que está en una red de VPC y un endpoint local con una dirección IP interna, los registros de flujo se notificanGoogle Cloud únicamente. Los siguientes recursos registran los registros de flujo:

• La VM. Registra los flujos de la subred a la que está conectada la VM si tiene habilitados los registros de flujo de VPC.
• La pasarela que conecta la red de VPC con el endpoint local. Registra los flujos si la puerta de enlace (en este ejemplo, la vinculación de VLAN) tiene habilitados los registros de flujo de VPC.

En el diagrama anterior, el endpoint local 10.30.0.2 envía una solicitud de 1224 bytes a la VM 10.0.0.2 de la red de VPC. A su vez, la VM 10.0.0.2 responde a la solicitud con una respuesta que contiene 5243 bytes. Tanto la solicitud como la respuesta se registran desde la vinculación de VLAN y la VM.

Según lo informado por la vinculación de VLAN
Solicitud/respuesta	connection.src_ip	connection.dest_ip	bytes_sent	Anotaciones
solicitud	10.30.0.2	10.0.0.2	1224	src_gateway.* dest_instance.* dest_vpc.*
responder	10.0.0.2	10.30.0.2	5342	src_instance.* src_vpc.* dest_gateway.*

Según lo notificado por la VM (10.0.0.2)
Solicitud/respuesta	connection.src_ip	connection.dest_ip	bytes_sent	Anotaciones
solicitud	10.30.0.2	10.0.0.2	1224	src_gateway.* dest_instance.* dest_vpc.*
responder	10.0.0.2	10.30.0.2	5342	src_instance.* src_vpc.* dest_gateway.*

Flujos entre redes de VPC de distintos proyectos

Si los registros de flujo de VPCs están configurados para una organización y las anotaciones entre proyectos están habilitadas (opción predeterminada), los flujos de tráfico entre redes de VPCs de diferentes proyectos se anotan de la misma forma que los flujos de tráfico entre redes de VPCs del mismo proyecto. Los registros de estos flujos proporcionan información sobre ambos extremos de la conexión.

Si las anotaciones entre proyectos están inhabilitadas, los registros de registro solo proporcionan información sobre el reportero del flujo de tráfico.

Anotaciones entre proyectos habilitadas

En el siguiente ejemplo se describe cómo Registros de flujo de VPC anota los registros de los flujos entre máquinas virtuales de diferentes proyectos cuando las anotaciones entre proyectos están habilitadas. Las anotaciones entre proyectos están disponibles para los flujos de tráfico a través de VPC compartida, el peering de redes de VPC y Network Connectivity Center.

La VM 10.0.0.2 envía una solicitud de 1224 bytes a la VM 10.0.0.1.2. A su vez, VM 10.0.0.1.2 responde a la solicitud con una respuesta que contiene 5342 bytes. Tanto la solicitud como la respuesta se registran en las máquinas virtuales que envían la solicitud y las que responden.

Según lo indicado por la VM que realiza la solicitud (10.0.0.2)
Solicitud/respuesta	connection.src_ip	connection.dest_ip	bytes_sent	Anotaciones
solicitud	10.0.0.2	10.0.1.2	1224	src_instance.* src_vpc.* dest_instance.* dest_vpc.*
responder	10.0.1.2	10.0.0.2	5342	src_instance.* src_vpc.* dest_instance.* dest_vpc.*

Según la VM que responde (10.0.1.2)
Solicitud/respuesta	connection.src_ip	connection.dest_ip	bytes_sent	Anotaciones
solicitud	10.0.0.2	10.0.1.2	1224	src_instance.* src_vpc.* dest_instance.* dest_vpc.*
responder	10.0.1.2	10.0.0.2	5342	src_instance.* src_vpc.* dest_instance.* dest_vpc.*

Anotaciones entre proyectos inhabilitadas

En el siguiente ejemplo se describe cómo los registros de flujo de VPC anotan los registros de flujo entre VMs de proyectos cuando las anotaciones entre proyectos están inhabilitadas.

La VM 10.0.0.2 envía una solicitud de 1224 bytes a la VM 10.0.0.1.2. A su vez, VM 10.0.0.1.2 responde a la solicitud con una respuesta que contiene 5342 bytes. Tanto la solicitud como la respuesta se registran en las máquinas virtuales que envían la solicitud y las que responden. Sin embargo, no se proporciona información sobre la otra VM.

Según lo indicado por la VM que realiza la solicitud (10.0.0.2)
Solicitud/respuesta	connection.src_ip	connection.dest_ip	bytes_sent	Anotaciones
solicitud	10.0.0.2	10.0.1.2	1224	src_instance.* src_vpc.*
responder	10.0.1.2	10.0.0.2	5342	dest_instance.* dest_vpc.*

Según la VM que responde (10.0.1.2)
Solicitud/respuesta	connection.src_ip	connection.dest_ip	bytes_sent	Anotaciones
solicitud	10.0.0.2	10.0.1.2	1224	dest_instance.* dest_vpc.*
responder	10.0.1.2	10.0.0.2	5342	src_instance.* src_vpc.*

Siguientes pasos

• Configurar registros de flujo de VPC
• Acceder a los registros de flujo