GCP Virtual Network – Soluciones en la nube

También conocida como una red de nube privada virtual o Virtual Private Cloud (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.

Relación entre proyecto, red virtual, región, subred y zonas de disponibilidad

De acuerdo con la imagen de abajo y la arquitectura jerárquica de niveles de administracion de Google Cloud Platform (GCP), una cuenta en GCP (Tenant) en lo que respecta a segmentación de cargas de trabajo (Workloads) estaba basado en proyectos (Projects), así un Tenant puede estar compuesta por múltiples Proyectos (Este puede estar ligado a un entorno individual como Producción, Preproducción, Desarrollo, una aplicación critica, …, etc.), Los proyectos pueden contener varias redes de VPC (A menos que crees una política de la organización que la prohíba), una VPC es extendida en todas las regiones (Una región es un punto de presencia de GCP en un país determinado con mas de un centros de datos físico), una subnet es extendido en todas las zonas de disponibilidad (Centro de datos fiscos en un país/región) de una región dada.
Los proyectos nuevos comienzan con una red predeterminada (una red de VPC en modo automático) que tiene una subned (subred) en cada región.

Estructura dependiente, para crear una subred se necesita crear primero una red virtual y fijar en que región crearla, para crear una red virtual se necesita fijar primero en que proyecto se va crear. La subred se extiende en todas las zonas de disponibilidad de la región en la que se fue creado.

Redes Virtuales y subredes

En Google Cloud, los términos en inglés subnet y subnetwork son sinónimos. Una subred no es lo mismo que una red (de VPC). Las redes y subredes son diferentes tipos de recursos en Google Cloud.
Las redes de nube privada virtual (VPC) son recursos globales. Cada red de VPC consta de uno o más rangos de direcciones IP llamados subredes. Las subredes son recursos regionales y tienen rangos de direcciones IP asociados. Una red debe tener, al menos, una subred para que pueda ser usada.

Ilustración de múltiples VPC en un proyecto. VPC de varios tipos, por default, personalizado, .., etc, extendido mediante subredes en múltiples regiones. «Las IPs están ligadas a las subredes mas no a la VPC».

Tipos de subredes

Las redes de VPC admiten los siguientes tipos de subredes:

Subredes solo IPv4 (pila única) con rangos de subred solo IPv4
Subredes IPv4 e IPv6 (pila doble) con rangos de subred IPv4 e IPv6

Una sola red de VPC puede contener cualquier combinación de estos tipos de subredes.
Cuando creas una subred, especificas qué tipo de pila usar. También puedes actualizar una subred IPv4 existente para configurarla como una subred de pila doble.
Las subredes de pila doble solo son compatibles con las redes de VPC de modo personalizado. Las subredes de pila doble no son compatibles con redes de VPC de modo automático ni con redes heredadas.

Propósitos de las subredes

Las subredes se pueden usar para diferentes propósitos:

Subredes regulares: Este es el tipo de subred predeterminado. Los usuarios crean subredes regulares o se crean de forma automática en redes de VPC de modo automático para usarlas con instancias de VM. Las subredes regulares tienen un propósito de PRIVATE en gcloud CLI o en la API. El propósito es NONE en la consola de Google Cloud.
Subredes de Private Service Connect: Es una subred que se usa para publicar un servicio administrado mediante Private Service Connect.
Subredes de solo proxy: Una subred de solo proxy que se usará con balanceadores de cargas regionales basados en Envoy.
Subredes NAT privadas: Una subred que está reservada para que se use como rango de origen de NAT privada. Esta subred se establece en --purpose=PRIVATE_NAT.

Limitaciones para asignar nombres a subredes

Los nombres de subredes tienen las siguientes limitaciones:

Dentro de un proyecto de Google Cloud, una subred no puede tener el mismo nombre que una red de VPC, a menos que sea miembro de esa red. Dentro de un proyecto, las subredes en la misma región deben tener nombres únicos. Por ejemplo, una red llamada production puede tener varias subredes también llamadas production, siempre que cada una de esas subredes esté en una región única.
No puedes cambiar el nombre ni la región de una subred luego de crearla. Sin embargo, puedes borrar una subred y reemplazarla, siempre y cuando no haya recursos que la usen.

Rangos de subredes IPv4

Las subredes deben tener un rango de direcciones IPv4 principal. Cuando el propósito de una subred es PRIVATE o NONE (Subredes regulares), el rango IPv4 principal puede ser usado por lo siguiente:

Direcciones IPv4 internas principales de las interfaces de red de VM de Compute Engine, incluidos los nodos de GKE (Google Kubernetes Engine).
Rangos de IP de alias de las interfaces de red de las VMs: Se puedes asignar rangos de direcciones IP internas como alias a las interfaces de red de una máquina virtual (VM). Esto es útil si tienes múltiples servicios en ejecución en una VM y deseas asignarle a cada servicio una dirección IP distinta. Los rangos de IP de alias también funcionan con pods de GKE.
Reglas de reenvío usadas por el reenvío de protocolos internos.
Reglas de reenvío usadas por los balanceadores de cargas de aplicaciones internos, los balanceadores de cargas de red de proxy internos y los balanceadores de cargas de red de transferencia internos
Puntos de entrada de la política del servidor entrante de Cloud DNS
Punto final de Private Service Connect para servicios publicados.

De manera opcional, las subredes pueden tener uno o más rangos de direcciones IPv4 secundarios, que solo pueden usar los rangos de alias de IP. Un rango de IP de alias puede provenir del rango IPv4 principal o de un rango IPv4 secundario de una subred.
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. Sin embargo, el rango principal de una subred puede ser 10.0.0.0/24, mientras que el rango principal de otra subred en la misma red puede ser 192.168.0.0/16.

Limitaciones para los rangos de subredes IPv4

Los rangos de subredes IPv4 tienen las siguientes limitaciones:

Cada rango de IPv4 principal o secundario para todas las subredes en una red de VPC debe ser un bloque CIDR válido.
La cantidad de rangos de direcciones IP secundarios que puedes definir se describe en los límites por red.
Después de crear una subred, el rango IPv4 principal para la subred se puede expandir, pero no se puede reemplazar ni reducir.
Puedes quitar y reemplazar el rango de direcciones IPv4 secundario de una subred solo si no hay instancias que usen ese rango.
El tamaño mínimo de rango principal o secundario es de ocho direcciones IPv4. En otras palabras, la máscara de subred más larga que puedes usar es /29.
La máscara de subred más corta que puedes usar es /4. Sin embargo, para la mayoría de los rangos de direcciones IP /4, las validaciones adicionales evitan que crees una subred que sea tan grande. Por ejemplo, un rango de subred no puede superponerse con un rango IPv4 privado ni otro rango reservado. Para minimizar la posibilidad de elegir un rango de subred no válido, te recomendamos que limites el tamaño máximo de la subred a /8.
No puedes crear rangos principales y secundarios para subredes que se superpongan con cualquier rango asignado, cualquier rango principal o secundario de otra subred en la misma red o cualquier rango IPv4 de subredes en redes con intercambio de tráfico. Google Cloud impide la creación de rangos de subredes superpuestos en estas situaciones.
Google Cloud crea las rutas de subred correspondientes para los rangos de IP principal y secundario. Las rutas de subred y, por lo tanto, los rangos de IP de la subred deben tener los rangos de IP más específicos por definición.
- Asegúrate de que los rangos principales y secundarios no entren en conflicto con los rangos de IP locales si conectaste la red de VPC a otra red con Cloud VPN, interconexión dedicada o interconexión de socio.
- Los rangos de IPv4 de subredes no pueden entrar en conflicto con los destinos de las rutas estáticas.
- Evita usar direcciones IPv4 del bloque 10.128.0.0/9 para los rangos de IPv4 principales o secundarios de una subred. Las subredes creadas automáticamente en redes de VPC de modo automático usan direcciones IPv4 de este bloque. Si usas direcciones IP en el bloque 10.128.0.0/9, no puedes conectar la red a una red de VPC de modo automático mediante el intercambio de tráfico entre redes de VPC o túneles de Cloud VPN.
Los rangos de subredes no pueden coincidir con un rango restringido, ni ser más estrechos ni más amplios que uno de estos rangos. Por ejemplo, 169.0.0.0/8 no es un rango de subred válido porque se superpone con el rango de vínculo local 169.254.0.0/16 (RFC 3927), que es un rango restringido.
Los rangos de subred no pueden abarcar un rango RFC (descrito en la tabla anterior) ni un rango de direcciones IP públicas de uso privado. Por ejemplo, 172.0.0.0/10 no es un rango de subred válido porque incluye el rango de direcciones IP privadas 172.16.0.0/12 y las direcciones IP públicas.
Los rangos de subredes no pueden abarcar varios rangos de RFC. Por ejemplo, 192.0.0.0/8 no es un rango de subred válido porque incluye 192.168.0.0/16 (de RFC 1918) y 192.0.0.0/24 (de RFC 6890). Sin embargo, puedes crear dos subredes con diferentes rangos principales, una con 192.168.0.0/16 y otra con 192.0.0.0/24. O bien, puedes usar ambos rangos en la misma subred si haces que uno de ellos sea secundario.