Redes de VPC

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

Una red de VPC hace lo siguiente:

• Proporciona conectividad para tus instancias de máquina virtual (VM) de Compute Engine.
• Ofrece balanceadores de cargas de red de transferencia internos nativos y sistemas de proxy para balanceadores de cargas de aplicaciones internos.
• Se conecta a redes locales mediante túneles de Cloud VPN y adjuntos de VLAN para Cloud Interconnect.
• Distribuye el tráfico de los balanceadores de cargas externos de Google Cloud a los backends.

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

Importante: En esta página, se describen las redes de VPC, que son diferentes de las redes heredadas. Las redes heredadas ya no se pueden crear y no se recomiendan para la producción porque no admiten características de herramientas de redes avanzadas. No se puede convertir una red heredada en una red de VPC. Para ver de qué tipo es una red existente, consulta Visualiza redes.

Redes y subredes

En Google Cloud, los términos en inglés subnet y subnetwork son sinónimos. Se usan en la documentación de la consola de Google Cloud, los comandos de gcloud y las API.

Una subred no es lo mismo que una red (de VPC). Las redes y subredes son diferentes tipos de recursos 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. Este término se usa en la consola de Google Cloud, la referencia de Google Cloud CLI 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 productos de Google Cloud compilados en VMs de Compute Engine.

Para obtener más información, consulta Instancias de máquina virtual en la documentación de Compute Engine.

Especificaciones

Las redes de VPC tienen las siguientes propiedades:

• Las redes de VPC, incluidas sus reglas de firewall y rutas asociadas, son recursos globales. No están asociadas con ninguna región o zona en particular.

• Las subredes son recursos regionales.

• Cada subred define un rango de direcciones IPv4. Las subredes en redes de VPC de modo personalizado también pueden tener un rango de direcciones IPv6.

• El tráfico desde y hacia las instancias puede controlarse mediante las reglas de firewall de la red. Las reglas se implementan en las VM. Por lo tanto, el tráfico solo se puede controlar y registrar a medida que sale o llega a una VM.

• Los recursos dentro de una red de VPC pueden comunicarse entre sí mediante direcciones IPv4 internas, direcciones IPv6 internas o direcciones IPv6 externas, sujetas a las reglas de firewall de red aplicables. Si deseas obtener más información, consulta Comunicación dentro de la red.

• Las instancias con direcciones IPv4 o IPv6 internas pueden comunicarse con los servicios y las API de Google. Si deseas obtener más información, consulta Opciones de acceso privado a los servicios.

• La administración de red se puede proteger mediante roles de administración de identidades y accesos (IAM).

• Una organización puede usar VPC compartidas para mantener una red de VPC en un proyecto host en común. Los principales de IAM autorizados pertenecientes a otros proyectos de la misma organización pueden crear recursos que usan subredes de la red de VPC compartida.

• Las redes de VPC pueden conectarse con otras redes de VPC de organizaciones o proyectos diferentes mediante el intercambio de tráfico entre redes de VPC.

• Las redes de VPC pueden conectarse de forma segura en entornos híbridos mediante Cloud VPN o Cloud Interconnect.

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

  Nota: La compatibilidad de GRE para VPN e Interconnect se probó solo con la versión 0 de GRE. Además, la compatibilidad del tráfico de GRE no incluye asistencia de Google Cloud para solucionar problemas de tu red superpuesta.

• Las redes de VPC admiten direcciones IPv4 e IPv6 de unidifusión. Las redes de VPC no son compatibles con direcciones de transmisión o multidifusión dentro de la red.

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

Ejemplo de red de VPC

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

Ejemplo de una red de VPC (haz clic para agrandar).

• La subred Subnet1 está definida 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. Sus direcciones IP provienen del rango de direcciones disponible en la subnet1.
• La subred Subnet2 está definida como 192.168.1.0/24 en la región us-east1.
  • En esta subred, hay dos instancias de VM en la zona us-east1-b. Sus direcciones IP provienen del rango de direcciones disponible en la subnet2.
• La subred 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 instancia en la zona us-east1-c están en la subnet3, y cada una recibe una dirección IP de su rango disponible. Debido a que las subredes son recursos regionales, las instancias pueden asociar sus interfaces de red con cualquier subred de la misma región que contiene sus zonas.

Restricciones de las políticas de la organización

• Cada proyecto nuevo comienza con una red de VPC predeterminada. Si deseas inhabilitar la creación de redes predeterminadas, crea una política de la 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 con políticas de la organización:

  • Inhabilitar el uso de IPv6 externa de VPC: Si se establece como verdadero, la restricción constraints/compute.disableVpcExternalIpv6 te impide configurar subredes de pila doble con rangos de IPv6 externos.

  • Inhabilitar el uso de IPv6 interna de VPC: Si se configura como verdadero, la restricción constraints/compute.disableVpcInternalIpv6 te impide configurar subredes de pila doble con rangos de IPv6 internos.

  • Inhabilitar todo el uso de IPv6: Si se configura como verdadero, la restricción constraints/compute.disableAllIpv6 inhabilita la creación de recursos involucrados en el uso de IPv6 o la actualización a ellos.

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

Modo de creación de subred

Google Cloud ofrece dos tipos de redes de VPC, determinadas por su modo de creación de subred:

• Cuando se crea una red de VPC de modo automático, se crea de forma automática una subred de cada región dentro de ella. Estas subredes creadas de forma automática usan un conjunto de rangos de IPv4 predefinidos que se ajustan al bloque CIDR 10.128.0.0/9. A medida que las nuevas regiones de Google Cloud estén disponibles, las subredes nuevas de esas regiones se agregarán automáticamente a las redes de VPC de modo automático mediante un rango de IP de ese bloque. Además de las subredes creadas automáticamente, puedes agregar más subredes de forma manual a las redes de VPC de modo automático en las regiones que elijas mediante rangos de IP fuera de 10.128.0.0/9.

• Cuando se crea una red de VPC de modo personalizado, no se crean subredes de forma automática. Este tipo de red te proporciona control total sobre sus subredes y rangos de IP. Tú decides qué subredes crear en las regiones que elijas mediante los rangos de IP que especifiques.

Puedes cambiar una red de VPC del modo automático al modo personalizado. Esta es una conversión unidireccional. Las redes de VPC de modo personalizado no se pueden cambiar al modo automático. Para ayudarte a decidir qué tipo de red satisface tus necesidades, consulta las consideraciones para las redes de VPC de modo automático.

Red predeterminada

Cada proyecto nuevo comienza con una red predeterminada, a menos que decidas inhabilitarla. La red predeterminada es una red de VPC de modo automático con reglas de firewall IPv4 ya propagadas. La red predeterminada no tiene reglas de firewall IPv6 prepropagadas.

Consideraciones para las redes de VPC de modo automático

Las redes de VPC de modo automático son fáciles de configurar y usar, y son adecuadas para casos prácticos con estos atributos:

• La creación automática de subredes en cada región es útil.

• Los rangos de IP predefinidos de las subredes no se superponen con los rangos que usarías con otros fines (por ejemplo, conexiones de Cloud VPN a recursos locales).

Sin embargo, las redes de VPC de modo personalizado son más flexibles y se ajustan mejor a la producción. Los siguientes atributos destacan casos prácticos en los que se recomienda o requiere el uso de redes de VPC de modo automático:

• La creación automática de una subred en cada región no es necesaria.

• La creación automática de subredes a medida que surgen nuevas regiones podría generar una superposición con las direcciones IP usadas por las subredes manuales o rutas estáticas, o podría interferir en la planificación general de la red.

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

• Planeas conectar tu red de VPC a otra red:

  • Debido a que las subredes de cada red de VPC de modo automático usan el mismo rango predefinido de direcciones IP, no puedes conectar redes de VPC de modo automático entre sí mediante el intercambio de tráfico entre redes de VPC o Cloud VPN.

  • Debido a que el rango de CIDR 10.128.0.0/9 del modo automático es parte del espacio de direcciones de uso frecuente RFC 1918, las redes fuera de Google Cloud pueden usar un rango de CIDR superpuesto.

• Deseas crear subredes con rangos de IPv6. Las redes de VPC de modo automático no son compatibles con subredes de pila doble.

Importante: Las redes de producción deberían planearse con anticipación. Se recomienda que uses redes de VPC de modo personalizado en producción.

Rangos de subredes IPv4

Cada subred tiene un rango de direcciones IPv4 principal. Las direcciones internas principales para los siguientes recursos provienen del rango principal de la subred: instancias de VM, balanceadores de cargas internos y reenvío de protocolo interno. De manera opcional, puedes agregar rangos de direcciones IP secundarias a una subred, que solo usan los rangos de alias de IP. Sin embargo, puedes configurar rangos de alias de IP para instancias del rango principal o secundario de una subred.

Cada rango de IPv4 principal o secundario para todas las subredes en una red de VPC debe ser un bloque CIDR válido. Consulta los límites por red para conocer la cantidad de rangos de IP secundarios que puedes definir.

No es necesario que las subredes IPv4 formen un bloque CIDR contiguo predefinido, pero puedes configurarlo si así lo deseas. Por ejemplo, las redes de VPC de modo automático sí crean subredes que se ajustan un rango de IP predefinido de modo automático.

Cuando creas una subred en una red de VPC en modo personalizado, eliges qué rango de IPv4 usar. Para obtener más información, consulta rangos válidos, rangos de subredes prohibidos y Limitaciones para rangos de subredes IPv4.

Hay cuatro direcciones IP inutilizables en cada rango de subred IPv4 principal. Para obtener más información, consulta Direcciones no utilizables en rangos de subredes IPv4.

Las redes de VPC de modo automático se crean con una subred por región en el momento de la creación y reciben subredes nuevas de forma automática en las regiones nuevas. Las subredes solo tienen rangos IPv4, y todos los rangos de subredes se ajustan al bloque CIDR 10.128.0.0/9. Las partes no usadas de 10.128.0.0/9 están reservadas para el uso futuro de Google Cloud. Para obtener información sobre qué rango de IPv4 se usa en qué región, consulta Rangos de subredes IPv4 de modo automático.

Rangos de subredes IPv6

Cuando creas una subred de pila doble en una red de VPC de modo personalizado, eliges si la subred está configurada con un rango de subred IPv6 interno o un rango de subred IPv6 externo.

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

  • Las ULA se usan para la comunicación entre VM dentro de las redes de VPC. Las ULA para IPv6 son análogas a las direcciones RFC 1918 para IPv4. No se puede acceder a las ULA desde Internet ni se pueden enrutar de forma pública.

• Los rangos de subredes IPv6 externas usan direcciones de unidifusión globales (GUA).

  • Las GUA se pueden usar para la comunicación entre VM dentro de las redes de VPC y, también, se pueden enrutar en Internet.

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

Redes que admiten subredes de pila doble

Puedes crear subredes de pila doble en una red de VPC de modo personalizado.

Las subredes de doble pila no son compatibles con las redes de VPC de modo automático, incluida la red predeterminada. Las subredes de pila doble no son compatibles con redes heredadas.

Si tienes una red de VPC de modo automático a la que deseas agregar subredes de pila doble, puedes hacer lo siguiente:

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

2. Crear subredes nuevas de pila doble o convertir las subredes existentes a pilas dobles.

Rutas y reglas de firewall

Rutas

Las rutas definen rutas de acceso para instancias salientes (tráfico de salida). Para obtener detalles sobre los tipos de ruta de Google Cloud, 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 Cloud Routers. Los Cloud Routers administran sesiones de BGP para los productos de conectividad de Google Cloud.

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

Anuncios de ruta y direcciones IP internas

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

• Direcciones IPv4 internas regionales

  Se usan para rangos de direcciones IPv4 de subred principales y secundarios.

• Direcciones IPv6 internas y externas regionales

  Se usan para rangos de direcciones IPv6 de subred internos y externos.

• Direcciones IPv4 internas globales

  Se usa en extremos de Private Service Connect para las API de Google

Si conectas redes de VPC con intercambio de tráfico entre redes de VPC, los rangos de subred que usan direcciones IPv4 privadas siempre se intercambian. Puedes controlar si se intercambian los rangos de subredes que usan direcciones IPv4 públicas de uso privado. Las direcciones IPv4 internas globales nunca se intercambian mediante el intercambio de tráfico. Para obtener detalles adicionales, consulta la documentación del intercambio de tráfico entre redes de VPC.

Cuando conectas una red de VPC a otra red, como una red local, con un producto de conectividad de Google Cloud como Cloud VPN, Cloud Interconnect o el dispositivo de router, haz lo siguiente:

• Puedes anunciar las direcciones IP internas de la red de VPC en otra red (como una red local).
• Aunque la conectividad entre una red de VPC y otra red (como una red local) puede usar el enrutamiento privado proporcionado por un producto de conectividad de Google Cloud, las direcciones IP de la otra red también pueden enrutarse públicamente. Ten esto en cuenta si una red local usa direcciones IP que se pueden enrutar de forma pública.
• Las instancias de VM en una red de VPC que contiene rangos de subredes con direcciones IP públicas utilizadas de forma privada no pueden conectarse a recursos externos que usan esas mismas direcciones IP públicas.
• Ten mucho cuidado cuando anuncias direcciones IP públicas usadas de forma privada en otra red (como una red local), en especial cuando la otra red puede anunciar esas direcciones IP públicas a Internet.

Reglas de firewall

Las políticas de firewall jerárquicas y las reglas de firewall de VPC se aplican a los paquetes enviados a instancias de VM y desde estas instancias (y a los recursos que dependen de las VM, como los nodos de Google Kubernetes Engine). Ambos tipos de firewalls controlan el tráfico incluso si se encuentra entre VM en la misma red de VPC.

Para supervisar qué regla de firewall permitió o rechazó una conexión en particular, consulta Registro de reglas de firewall.

Comunicaciones y acceso

Comunicación dentro de la red

Las rutas de subredes generadas por el sistema definen las rutas para enviar tráfico entre instancias dentro de la red mediante direcciones IP internas. Para que una instancia pueda comunicarse con otra, deben configurarse las reglas de firewall adecuadas, ya que cada red tiene una regla de firewall implícita que rechaza el tráfico de entrada.

Excepto en el caso de la red predeterminada, debes crear de forma explícita reglas de firewall de entrada de prioridad más alta para permitir que las instancias se comuniquen entre sí. La red predeterminada incluye varias reglas de firewall, además de las implícitas, incluida 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 apliques a las nuevas redes de VPC de modo automático que crees mediante la consola de Google Cloud.

Requisitos de acceso a Internet

Se deben cumplir los siguientes criterios para que una instancia tenga acceso a Internet de salida:

• La red debe tener una ruta de puerta de enlace de Internet predeterminada o una ruta personalizada cuyo rango de IP de destino sea el más general (0.0.0.0/0). Esta ruta define la ruta de acceso a Internet. Para obtener más información, consulta Rutas.

• Las reglas de firewall deben permitir el tráfico de salida desde la instancia. A menos que esté anulada por una regla de prioridad más alta, la regla implícita para el tráfico de salida permite el tráfico saliente desde todas las instancias.

• Debe cumplirse una de las siguientes condiciones:

  • La instancia debe tener una dirección IP externa. Una dirección IP externa se puede asignar a una instancia cuando se crea o después de crearla.

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

Comunicaciones y acceso para App Engine

Las reglas de firewall de VPC se aplican a los recursos que se ejecutan en la red de VPC, como las VM de Compute Engine. Para las instancias de App Engine, las reglas de firewall funcionan de la siguiente manera:

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

• Entorno flexible de App Engine: Se aplican las reglas de firewall de VPC y de App Engine al tráfico de entrada. El tráfico entrante solo se admite si ambos tipos de reglas de firewall lo permiten. Para el tráfico saliente, se aplican las reglas de firewall de VPC.

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

Traceroute para direcciones IP externas

Por motivos internos, Google Cloud aumenta el contador de TTL de los paquetes que recorren los siguientes saltos en la red de Google. Es posible que herramientas como traceroute y mtr proporcionen resultados incompletos porque el TTL no vence en algunos de los saltos. Los saltos que están dentro de la red de Google pueden estar ocultos cuando envías paquetes de instancias de Compute Engine a destinos en Internet.

La cantidad de saltos ocultos varía según 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. Si faltan saltos en un resultado de traceroute o de mtr, no significa que se perderá el tráfico saliente.

No hay ninguna solución para este comportamiento. Debes tenerlo en cuenta si configuras la supervisión de terceros que se conecta a una dirección IP externa asociada con una VM.

Importante: Las estadísticas de pérdida de sondeo son un componente de las pruebas de traceroute. Analiza con atención los resultados de las pruebas. De forma predeterminada, traceroute y mtr usan el sondeo basado en ICMP. Por lo general, la generación de respuestas del sondeo ICMP tiene un límite de frecuencia (o está inhabilitada) en los routers que se ubican en la ruta de la red del sondeo y puede causar que falten respuestas de sondeo. Cuando se produce este comportamiento, es posible que descubras una pérdida de sondeo en los saltos de enrutamiento intermedios. Sin embargo, esto no debería reflejar el rendimiento de extremo a extremo. Si buscas la pérdida de paquetes, el único salto que suele ser importante es el salto de destino.

Límites de capacidad de procesamiento de salida

La información sobre la capacidad de procesamiento de la red está disponible en la página Ancho de banda de red que se encuentra en la documentación de Compute Engine.

Tamaño del paquete

Puedes obtener información sobre el tamaño del paquete en Unidad de transmisión máxima.

Unidad de transmisión máxima

Para obtener más información sobre la configuración 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 diferentes configuraciones de MTU, consulta Cambia la configuración 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 de IPv4.
• Paquetes de datos IPv4 entre Internet y las VMs: son los protocolos ICMP, IPIP, TCP, UDP, GRE, ESP, AH y SCTP.
• Paquetes de datos IPv6 entre VMs y entre Internet y las VMs: los protocolos AH, ESP, GRE, ICMP, ICMPv6, IPIP, SCTP, TCP y UDP, y encabezados de extensiones de fragmentos y opciones de destino. Sin embargo, no se admite la ubicación del encabezado de opciones de destino después del encabezado de fragmentos en un paquete de datos IPv6.
• Reenvío de protocolos: los protocolos AH, ESP, GRE, ICMP, ICMPv6, SCTP, TCP y UDP

Para permitir paquetes de datos de los protocolos compatibles, debes configurar reglas de firewall o reglas de reenvío de protocolos según tus requisitos.

Rendimiento de la red

Latencia

La latencia medida entre regiones para las redes de Google Cloud se puede encontrar en nuestro panel de transmisiones en vivo. En el panel, se muestran las métricas del rendimiento de la capacidad de procesamiento y la latencia mediana entre regiones de Google Cloud, y la metodología para reproducir estos resultados con PerfKit Benchmarker.

Por lo general, Google Cloud mide las latencias de ida y vuelta de menos de 55 μs en el percentil 50 y las latencias finales de menos de 80 μs en el percentil 99 entre instancias de VM c2-standard-4 en la misma zona.

Por lo general, Google Cloud mide las latencias de ida y vuelta de menos de 45 μs en el percentil 50 y las latencias finales de menos de 60 μs en el percentil 99 entre las instancias de VM c2-standard-4 en la misma red de latencia baja (política de posición de “compactación”). La política de posición de compactación reduce la latencia de la red, ya que garantiza que las VMs se encuentren físicamente dentro de la misma red de latencia baja.

Metodología: La latencia dentro de la zona se supervisa con un sistema de sondeo de caja negra que ejecuta comparativas de TCP_RR de netperf de forma continua entre un par de VMs de tipo c2 en cada zona en que las instancias de c2 estén disponibles. Recopila resultados de P50 y P99 para la configuración con y sin política de posición de compactación. La comparativa de TCP_RR mide el rendimiento de las solicitudes y las respuestas mediante la medición de la tasa de transacciones. Si tus aplicaciones requieren la mejor latencia posible, se recomiendan las instancias de c2.

Pérdida de paquetes

Google Cloud hace un seguimiento de la pérdida de paquetes entre regiones mediante la medición regular de la pérdida de ida y vuelta entre todas las regiones. El objetivo es que el promedio global de esas mediciones sea inferior al 0.01%.

Metodología: Un sistema de sondeo de VM a VM de caja negra supervisa la pérdida de paquetes para cada par de zonas mediante pings y agrega los resultados en una métrica de pérdida global. Se realiza un seguimiento de esta métrica con un período de un día.

¿Qué sigue?

• Crea, modifica o borra redes y subredes de VPC.

Pruébalo tú mismo

Si es la primera vez que usas Google Cloud, crea una cuenta para evaluar el rendimiento de VPC en situaciones reales. Los clientes nuevos también obtienen $300 en créditos gratuitos para ejecutar, probar y, además, implementar cargas de trabajo.

Probar la VPC gratis