Redes de VPC

Una red de nube privada virtual (VPC) es una versión virtual de una red física que se implementa en la red de producción de Google mediante Andromeda.

Una red de VPC hace lo siguiente:

  • Proporciona conectividad a las instancias de máquina virtual de Compute Engine.
  • Ofrece balanceadores de carga de red con paso a través internos nativos y sistemas proxy para balanceadores de carga de aplicaciones internos.
  • Se conecta a redes on-premise mediante túneles de Cloud VPN y asignaciones de VLAN para Cloud Interconnect.
  • Distribuye el tráfico de los Google Cloud balanceadores de carga externos a los backends.

Los proyectos pueden contener varias redes de VPC. A menos que crees una política de organización que lo prohíba, los proyectos nuevos empiezan con una red predeterminada (una red de VPC de modo automático) que tiene una subred en cada región.

Redes y subredes

Los términos subred y subred son sinónimos. Se usan indistintamente en la consola, los comandos Google Cloud gcloud y la documentación de la API.

Una subred no es lo mismo que una red (VPC). Las redes y las subredes son tipos de recursos diferentes en Google Cloud.

Para obtener más información, consulta Subredes.

Instancias de máquina virtual

Una instancia de máquina virtual (VM) de Compute Engine es una máquina virtual alojada en la infraestructura de Google. Los términos instancia de Compute Engine, instancia de VM y VM son sinónimos. Se usan indistintamente en la Google Cloud consola, la referencia de la CLI de Google Cloud y la documentación de la API.

Las instancias de VM incluyen clústeres de Google Kubernetes Engine (GKE), instancias del entorno flexible de App Engine y otros Google Cloud productos creados en VMs de Compute Engine.

Para obtener más información, consulta el artículo sobre instancias de máquina virtual de la documentación de Compute Engine.

Especificaciones

Las redes de VPC tienen las siguientes propiedades:

  • Las redes de VPC, incluidas las rutas que tengan asociadas y sus reglas de cortafuegos, son recursos globales. y no están vinculadas a una región o a una zona en particular.

  • Las subredes son recursos regionales.

  • Cada subred define los siguientes intervalos de direcciones IP:

    • Las subredes solo IPv4 y de doble pila definen un intervalo de direcciones IPv4, mientras que las subredes de doble pila también definen un intervalo de direcciones IPv6.
    • Las subredes solo IPv6 definen un intervalo de direcciones IPv6.

    Para obtener más información, consulta Tipos de subredes.

  • El tráfico hacia las instancias y procedente de ellas se puede controlar con reglas de cortafuegos de red. Las reglas se implementan en las propias VMs, por lo que el tráfico solo se puede controlar y registrar cuando sale de una VM o llega a ella.

  • Los recursos de una red de VPC pueden comunicarse entre sí mediante direcciones IPv4 internas, direcciones IPv6 internas o direcciones IPv6 externas, de acuerdo con las reglas de cortafuegos de red aplicables. Para obtener más información, consulta la sección sobre la comunicación dentro de la red.

  • Las instancias con direcciones IPv4 o IPv6 internas pueden comunicarse con las APIs y los servicios de Google. Para obtener más información, consulta el artículo sobre las opciones de acceso privado a servicios.

  • La red se puede gestionar de forma segura usando roles de Gestión de Identidades y Accesos (IAM).

  • Una organización puede usar la VPC compartida para mantener una red de VPC en un proyecto del host común. Las entidades de gestión de identidades y accesos autorizadas de otros proyectos de la misma organización pueden crear recursos que usen subredes de la red VPC compartida.

  • Las redes de VPC se pueden conectar a otras redes de VPC de diferentes proyectos u organizaciones mediante el emparejamiento entre redes de VPC.

  • Las redes de VPC se pueden conectar de forma segura con entornos híbridos usando Cloud VPN o Cloud Interconnect.

  • Las redes de VPC admiten tráfico GRE, incluido el tráfico de Cloud VPN y Cloud Interconnect. Las redes de VPC no admiten GRE para Cloud NAT ni para las reglas de reenvío de balanceo de carga y reenvío de protocolos. La compatibilidad con GRE te permite finalizar el tráfico GRE en una VM desde Internet (dirección IP externa) y Cloud VPN o Cloud Interconnect (dirección IP interna). El tráfico desencapsulado se puede reenviar a un destino accesible. GRE te permite usar servicios como el servicio de acceso seguro perimetral (SASE) y SD-WAN.

  • Las redes de VPC admiten direcciones unicast IPv4 e IPv6. Las redes de VPC no admiten direcciones de difusión ni de multidifusión dentro de la red.

    Para obtener más información sobre los intervalos de subredes IPv6, consulta Subredes.

Ejemplo de red de VPC

En el siguiente ejemplo se muestra una red de VPC en modo personalizado con tres subredes en dos regiones:

Ejemplo de red de VPC.
Ejemplo de red de VPC (haz clic en la imagen para ampliarla)
  • Subnet1 se define como 10.240.0.0/24 en la región us-west1.
    • En esta subred hay dos instancias de VM en la zona us-west1-a. Las direcciones IP de ambos proceden del intervalo de direcciones disponibles de subnet1.
  • Subnet2 se define como 192.168.1.0/24 en la región us-east1.
    • En esta subred hay dos instancias de máquina virtual en la zona us-east1-b. Sus direcciones IP proceden del intervalo de direcciones disponibles de subnet2.
  • Subnet3 se define como 10.2.0.0/16, también en la región us-east1.
    • Una instancia de VM en la zona us-east1-b y otra en la zona us-east1-c están en subnet3. Cada una recibe una dirección IP de su intervalo disponible. Como las subredes son recursos regionales, las instancias pueden tener sus interfaces de red asociadas a cualquier subred de la misma región que contenga sus zonas.

Restricciones de las políticas de organización

  • Todos los proyectos nuevos utilizan una red VPC predeterminada al principio. Puedes inhabilitar la creación de redes predeterminadas creando una política de organización con la restricción compute.skipDefaultNetworkCreation. Los proyectos que hereden esta política no tendrán una red predeterminada.

  • Puedes controlar las siguientes configuraciones de IPv6 mediante políticas de organización:

    • Inhabilitar el uso de IPv6 externo de VPC: si se asigna el valor true, la restricción constraints/compute.disableVpcExternalIpv6 impide configurar subredes con intervalos de IPv6 externos.

    • Inhabilitar el uso de IPv6 interno de VPC: si se define como true, la restricción constraints/compute.disableVpcInternalIpv6 te impide configurar subredes con intervalos de IPv6 internos.

    • Inhabilitar todo el uso de IPv6: si se define como true, la restricción constraints/compute.disableAllIpv6 inhabilita la creación o la actualización de cualquier subred u otro recurso de red implicado en el uso de IPv6.

Para obtener más información sobre las restricciones, consulta Restricciones de las políticas de la organización.

Modo de creación de subred

Google Cloud ofrece dos tipos de redes de VPC, que se determinan en función de su modo de creación de subredes:

  • Cuando se crea una red de VPC en modo automático, se crea automáticamente una subred de cada región. Estas subredes creadas automáticamente usan un conjunto de intervalos IPv4 predefinidos que se ajustan al bloque 10.128.0.0/9 CIDR. A medida que haya nuevas Google Cloud regiones disponibles, se añadirán automáticamente nuevas subredes de esas regiones a las redes de VPC en modo automático mediante un intervalo de IPs de ese bloque. Además de las subredes creadas automáticamente, puedes añadir más subredes manualmente a las redes VPC en modo automático de las regiones que elijas mediante intervalos de IP que no sean 10.128.0.0/9.

  • Cuando se crea una red VPC demodo personalizado, no se crean subredes automáticamente. Este tipo de red te ofrece un control total sobre sus subredes e intervalos de IP. Tú decides qué subredes quieres crear en las regiones que elijas mediante los intervalos de IP que especifiques.

Puedes cambiar una red VPC del modo automático al modo personalizado. Se trata de una conversión unidireccional: las redes de VPC en modo personalizado no se pueden cambiar a redes de VPC en modo automático. Para ayudarte a decidir qué tipo de red se adapta mejor a tus necesidades, consulta las consideraciones sobre las redes VPC de modo automático.

Red predeterminada

A menos que decidas inhabilitarla, todos los proyectos nuevos utilizan una red predeterminada al principio. La red predeterminada es una red de VPC automática, en la que se han establecido previamente reglas de cortafuegos IPv4. La red predeterminada no tiene reglas de cortafuegos IPv6 predefinidas.

Consideraciones sobre las redes de VPC en modo automático

Las redes de VPC en modo automático son fáciles de configurar y usar, y se adaptan bien a los casos prácticos con estos atributos:

  • Es útil que las subredes se creen automáticamente en cada región.

  • Los intervalos de IP predefinidos de las subredes no se solapan con los intervalos de IP que usarías para otros fines (por ejemplo, conexiones de Cloud VPN a recursos on-premise).

Sin embargo, las redes de VPC en modo personalizado son más flexibles y se adaptan mejor a la producción. Los siguientes atributos destacan los casos prácticos en los que se recomiendan o se requieren redes de VPC en modo personalizado:

  • No es necesario que se cree automáticamente una subred en cada región.

  • Si se crean automáticamente subredes nuevas a medida que haya nuevas regiones disponibles, podría haber solapamientos con las direcciones IP que usan las subredes o las rutas estáticas creadas manualmente, o bien podría interferir en la planificación general de tu red.

  • Necesitas tener control total sobre las subredes creadas en tu red de VPC, incluidas las regiones y los intervalos de direcciones IP utilizados.

  • Tienes previsto conectar tu red de VPC a otra red:

    • Como las subredes de todas las redes de VPC en modo automático usan el mismo intervalo predefinido de direcciones IP, no puedes conectar redes de VPC en modo automático entre sí mediante el emparejamiento entre redes de VPC o Cloud VPN.

    • Como el intervalo CIDR del modo automático 10.128.0.0/9 forma parte del espacio de direcciones RFC 1918, que se usa con frecuencia, las redes que no sean Google Cloud pueden usar un intervalo CIDR superpuesto.

  • Quieres crear subredes con intervalos IPv6. Las redes de VPC en modo automático no admiten subredes con intervalos IPv6.

Intervalos de subred IPv4

Cada subred tiene un intervalo de direcciones IPv4 principal. Las direcciones internas principales de los siguientes recursos proceden del intervalo principal de la subred: instancias de VM, balanceadores de carga internos y reenvío de protocolos interno. También puedes añadir intervalos de direcciones IP secundarias a una subred, que solo se utilizan en los intervalos de IP de alias. Sin embargo, puedes configurar intervalos de IP de alias para las instancias a partir del intervalo principal o secundario de una subred.

Cada intervalo IPv4 principal o secundario de todas las subredes de una red de VPC debe ser un bloque CIDR válido único. Consulta los límites por red para saber cuántos intervalos de IP secundarios puedes definir.

Tus subredes IPv4 no tienen por qué formar un bloque CIDR contiguo predefinido, pero puedes hacerlo si quieres. Por ejemplo, las redes de VPC en modo automático crean subredes que se ajustan a un intervalo de IPs en modo automático predefinido.

Cuando creas una subred en una red de VPC en modo personalizado, eliges el intervalo de IPv4 que quieres usar. Para obtener más información, consulta los intervalos válidos, los intervalos de subred prohibidos y las limitaciones de los intervalos de subred IPv4.

En cada intervalo de subred IPv4 principal hay cuatro direcciones IP que no se pueden usar. Para obtener más información, consulta Direcciones no utilizables en intervalos de subredes IPv4.

Las redes de VPC en modo automático se crean con una subred por región en el momento de la creación y reciben automáticamente nuevas subredes en nuevas regiones. Las subredes solo tienen intervalos IPv4 y todos los intervalos de subred caben en el bloque 10.128.0.0/9 CIDR. Las partes no utilizadas de 10.128.0.0/9 se reservan paraGoogle Cloud usos futuros. Para obtener información sobre qué intervalo de IPv4 se usa en cada región, consulta Intervalos de subred de IPv4 en modo automático.

Intervalos de subred IPv6

Cuando creas una subred con un intervalo IPv6 en una red de VPC en modo personalizado, puedes elegir si la subred se configura con un intervalo de subred IPv6 interno o externo.

  • Los intervalos de subredes IPv6 internas usan direcciones locales únicas (ULA).

    • Las ULAs se usan para la comunicación entre máquinas virtuales dentro de las redes de VPC. Las ULA de IPv6 son análogas a las direcciones RFC 1918 de IPv4. No se puede acceder a las ULAs desde Internet y no se pueden enrutar públicamente.

  • Los intervalos de subred IPv6 externos usan direcciones unicast globales (GUAs).

    • Las GUAs se pueden usar para la comunicación entre máquinas virtuales dentro de las redes de VPC y también se pueden enrutar en Internet.

Para obtener más información sobre los intervalos de subredes IPv6, consulta Subredes.

Redes que admiten subredes con intervalos de direcciones IPv6

Puedes crear subredes con intervalos de direcciones IPv6 en una red VPC de modo personalizado. Para obtener más información, consulta Trabajar con subredes.

Las subredes con intervalos de direcciones IPv6 no se admiten en los siguientes casos:

  • Redes de VPC de modo automático, incluida la red predeterminada
  • Redes antiguas

Si tienes una red de VPC automática a la que quieres añadir subredes con intervalos de direcciones IPv6, puedes hacer lo siguiente:

  1. Convierte la red de modo automático en modo personalizado.

  2. Crea subredes de doble pila o solo IPv6 nuevas. También puedes convertir subredes solo IPv4 en subredes de doble pila.

Rutas y reglas de cortafuegos

Rutas

Las rutas definen las rutas de los paquetes que salen de las instancias (tráfico de salida). Para obtener más información sobre los Google Cloud tipos de rutas, consulta Rutas.

Modo de enrutamiento dinámico

Cada red de VPC tiene un modo de enrutamiento dinámico asociado que controla el comportamiento de todos sus routers de Cloud. Los routers de Cloud Router gestionan las sesiones BGP de los Google Cloud productos que usan Cloud Router.

Para ver una descripción de las opciones del modo de enrutamiento dinámico, consulta Modo de enrutamiento dinámico en la documentación de Cloud Router.

Anuncios de rutas y direcciones IP internas

Las siguientes direcciones IP se anuncian en una red de VPC:

Si conectas redes de VPC mediante el emparejamiento entre redes de VPC, siempre se intercambian los intervalos de subred que usan direcciones IPv4 privadas. Puedes controlar si se intercambian los intervalos de subred que usan direcciones IPv4 públicas utilizadas de forma privada y si se intercambian los intervalos de subred IPv6 internos y externos. Las direcciones IPv4 internas globales nunca se intercambian mediante el peering. Para obtener más información, consulta la documentación sobre el emparejamiento entre redes de VPC.

Cuando conectas una red de VPC a otra red, como una red on-premise, mediante un producto de conectividad Google Cloud , como Cloud VPN, Cloud Interconnect o Router appliance, ocurre lo siguiente:

  • Puedes anunciar las direcciones IP internas de la red de VPC a otra red (por ejemplo, una red local).
  • Aunque la conectividad entre una red VPC y otra red (como una red local) puede usar el enrutamiento privado que proporciona unGoogle Cloud producto de conectividad, las direcciones IP de la otra red también pueden ser enrutables públicamente. Tenlo en cuenta si una red local usa direcciones IP enrutables públicamente.
  • Las instancias de VM de una red de VPC que contenga intervalos de subred con direcciones IP públicas utilizadas de forma privada no podrán conectarse a recursos externos que usen esas mismas direcciones IP públicas.
  • Tenga especial cuidado al anunciar direcciones IP públicas usadas de forma privada en otra red (como una red local), sobre todo si la otra red puede anunciar esas direcciones IP públicas en Internet.

Reglas de cortafuegos

Tanto las políticas de cortafuegos de jerarquía como las reglas de cortafuegos de VPC se aplican a los paquetes enviados a las instancias de VM y desde ellas (así como a los recursos que dependen de las VMs, como los nodos de Google Kubernetes Engine). Ambos tipos de cortafuegos controlan el tráfico, aunque sea entre máquinas virtuales de la misma red de VPC.

Para monitorizar qué regla de cortafuegos ha permitido o denegado una conexión concreta, consulta Registro de reglas de cortafuegos.

Comunicaciones y acceso

Comunicación dentro de la red

Las rutas de subred generadas por el sistema definen las rutas para enviar tráfico entre instancias de la red mediante direcciones IP internas. Para que una instancia pueda comunicarse con otra, también se deben configurar las reglas de cortafuegos adecuadas, ya que todas las redes tienen una regla de cortafuegos de denegación implícita para el tráfico de entrada.

A excepción de la red predeterminada, debes crear explícitamente reglas de cortafuegos de entrada de mayor prioridad para permitir que las instancias se comuniquen entre sí. La red predeterminada incluye varias reglas de cortafuegos, además de las implícitas, como la regla default-allow-internal, que permite la comunicación entre instancias dentro de la red. La red predeterminada también incluye reglas de entrada que permiten protocolos como RDP y SSH.

Las reglas que vienen con la red predeterminada también se presentan como opciones para que las apliques a las nuevas redes de VPC de modo automático que crees con la consola Google Cloud .

Requisitos de acceso a Internet

Para que una instancia tenga acceso a Internet saliente, debe cumplir los siguientes criterios:

  • La red debe tener una ruta de gateway de Internet predeterminada válida o una ruta personalizada cuya intervalo de IPs de destino sea el más general (0.0.0.0/0 para IPv4 y ::/0 para IPv6). Esta ruta define la ruta a Internet. Para obtener más información, consulta Tipos de rutas.

  • Las reglas de cortafuegos deben permitir el tráfico saliente de la instancia. A menos que se anule por una regla de mayor prioridad, la regla de permiso implícita para el tráfico de salida permite el tráfico saliente de todas las instancias.

  • Debe cumplirse una de las siguientes condiciones:

    • La instancia debe tener una dirección IP externa. Se puede asignar una dirección IP externa a una instancia cuando se crea o después de que se haya creado.

    • La instancia debe poder usar Cloud NAT o un proxy basado en instancias que sea el destino de una ruta 0.0.0.0/0estática o ::/0.

Comunicaciones y acceso de App Engine

Las reglas de cortafuegos de VPC se aplican a los recursos que se ejecutan en la red de VPC, como las VMs de Compute Engine. En el caso de las instancias de App Engine, las reglas de cortafuegos funcionan de la siguiente manera:

  • Entorno estándar de App Engine: Solo se aplican las reglas de cortafuegos de App Engine al tráfico de entrada. Como las instancias del entorno estándar de App Engine no se ejecutan en tu red de VPC, las reglas de cortafuegos de VPC no se aplican a ellas.

  • Entorno flexible de App Engine: tanto las reglas de cortafuegos de App Engine como las de VPC se aplican al tráfico de entrada. El tráfico entrante solo se permite si lo permiten ambos tipos de reglas de cortafuegos. En el caso del tráfico saliente, se aplican las reglas de cortafuegos de VPC.

Para obtener más información sobre cómo controlar el acceso a las instancias de App Engine, consulta Seguridad de aplicaciones.

Traceroute a direcciones IP externas

Por motivos internos, Google Cloud aumenta el contador TTL de los paquetes que atraviesan los siguientes saltos en la red de Google. Herramientas como traceroute y mtr pueden proporcionar resultados incompletos porque el TTL no caduca en algunos de los saltos. Los saltos que se encuentran dentro de la red de Google pueden ocultarse cuando envías paquetes desde instancias de Compute Engine a destinos en Internet.

El número de saltos ocultos varía en función de los niveles de servicio de red de la instancia, la región y otros factores. Si solo hay unos pocos saltos, es posible que todos estén ocultos. El hecho de que falten saltos en un resultado de traceroute o mtr no significa que se haya descartado el tráfico saliente.

No hay ninguna solución alternativa para este comportamiento. Debes tenerlo en cuenta si configuras una monitorización de terceros que se conecte a una dirección IP externa asociada a una VM.

Límites de rendimiento de salida

Puedes consultar información sobre el rendimiento de la red en la página Ancho de banda de la red de la documentación de Compute Engine.

Tamaño del paquete

Puede consultar información sobre el tamaño de los paquetes en Unidad máxima de transmisión.

Unidad máxima de transmisión

Para obtener más información sobre el ajuste de la unidad de transmisión máxima (MTU) de una red de VPC y sus VMs conectadas, consulta Unidad de transmisión máxima.

Para obtener información sobre cómo cambiar la MTU de una red de VPC o migrar VMs entre redes de VPC con ajustes de MTU diferentes, consulta Cambiar el ajuste de MTU de una red de VPC.

Protocolos admitidos

Google Cloud solo admite los siguientes protocolos y encabezados de extensión:

  • Paquetes de datos IPv4 entre VMs: todos los protocolos IPv4.
  • Paquetes de datos IPv4 entre las VMs e Internet: los protocolos ICMP, IPIP, TCP, UDP, GRE, ESP, AH y SCTP.
  • Paquetes de datos IPv6 entre máquinas virtuales y entre máquinas virtuales e Internet: los protocolos AH, ESP, GRE, ICMP, ICMPv6, IPIP, SCTP, TCP y UDP, y los encabezados de extensión Destination Options y Fragments. Sin embargo, no se admite colocar el encabezado de opciones de destino después del encabezado de fragmento en un paquete de datos IPv6.
  • Reenvío de protocolos: los protocolos AH, ESP, GRE, ICMP, ICMPv6, SCTP, TCP y UDP

Para permitir los paquetes de datos de los protocolos admitidos, debe configurar reglas de cortafuegos o reglas de reenvío de protocolos según sus necesidades.

Perfiles de red para casos prácticos específicos

Google Cloud usa el recurso de perfil de red para preconfigurar determinadas propiedades en una red de VPC para un caso práctico específico. Cuando crees tu red, puedes especificar un perfil de red proporcionado por Google Cloud .

El caso de uso admitido por los perfiles de red es ejecutar cargas de trabajo de IA en máquinas con interfaces de red (NICs) que admitan el acceso directo a memoria remoto (RDMA). Google Cloud proporciona un perfil de red RDMA que te permite crear una red de nube privada virtual (VPC) que admita la conectividad RDMA.

Para obtener más información, consulta el resumen de los perfiles de red.

Para obtener más información sobre cómo ejecutar cargas de trabajo de IA en Google Cloud, consulta la documentación de AI Hypercomputer.

Rendimiento de la red

Latencia

Puedes consultar la latencia entre regiones medida de las Google Cloud redes en nuestro panel de control en tiempo real. En el panel de control se muestran la latencia entre regiones mediana y las métricas de rendimiento de la tasa de transferencia de datos de Google Cloud, así como la metodología para reproducir estos resultados con PerfKit Benchmarker.

Google Cloud suele medir latencias de ida y vuelta inferiores a 55 μs en el percentil 50 y latencias de cola inferiores a 80 μs en el percentil 99 entre instancias de VM c2-standard-4 de la misma zona.

Google Cloud Suele medir latencias de ida y vuelta inferiores a 45 μs en el percentil 50 y latencias de cola inferiores a 60 μs en el percentil 99 entre instancias de VM c2-standard-4 en la misma red de baja latencia (política de colocación "compacta"). Una política de emplazamiento compacta reduce la latencia de la red, ya que asegura que las máquinas virtuales se encuentren físicamente en la misma red de baja latencia.

Metodología: la latencia entre zonas se monitoriza mediante un prober de caja negra que ejecuta constantemente la prueba de rendimiento netperf TCP_RR entre un par de VMs de tipo c2 en cada zona en la que hay instancias c2 disponibles. Recoge los resultados de P50 y P99 de la configuración con y sin política de posición compacta. La prueba de rendimiento TCP_RR mide el rendimiento de las solicitudes y respuestas midiendo la tasa de transacciones. Si tus aplicaciones requieren la menor latencia posible, te recomendamos que uses instancias c2.

Pérdida de paquetes

Google Cloud monitoriza la pérdida de paquetes entre regiones midiendo periódicamente la pérdida de ida y vuelta entre todas las regiones. Nuestro objetivo es que la media global de esas mediciones sea inferior al 0,01% .

Metodología: un verificador de VM a VM de caja negra monitoriza la pérdida de paquetes de cada par de zonas mediante pings y agrega los resultados en una métrica de pérdida global. Esta métrica se monitoriza con una ventana de un día.

Siguientes pasos

Pruébalo

Si es la primera vez que utilizas Google Cloud, crea una cuenta para evaluar el rendimiento de VPC en situaciones reales. Los nuevos clientes también reciben 300 USD en crédito gratuito para ejecutar, probar y desplegar cargas de trabajo.

Probar VPC gratis