Virtual Private Networks
Tags: gcp, vpc
Published: 2023-04-04 02:32:20

Al iniciar la ruta para convertirnos en arquitectos o ingenieros en la nube de GCP, hay un tema fundamental que puede brindarnos una perspectiva clara de cómo los distintos componentes de nuestros proyectos se comunican entre sí. Este conocimiento resulta esencial para desarrollar una comprensión profunda de la arquitectura en la nube y es una habilidad indispensable para cualquier profesional que busque destacarse en este campo. En este artículo, exploraremos este tema con detenimiento y descubriremos cómo puede ayudarnos a construir soluciones en la nube de manera más efectiva.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/qr4oyyo2lzi184n5n9p6.png)
**Temas previos:**

- Estructura de directorios y proyectos en GCP

**Índice:**

1. Definiciones de VPC, rutas y reglas de firewall en GCP
2. Buenas practicas 
3. Diseños comunes de redes en GCP
4. Precios

## Que es una VPC?

Una VPC (Virtual Private Cloud) en GCP es un ambiente de red virtual, que le permite crear y administrar la comunicación de sus aplicaciones. 
Con una VPC, puede tener un control completo sobre su red y su topología incluyendo sus rangos de direcciones IP, subredes, enrutadores y reglas de firewall proporcionando una conectividad global y administrada, lo que le permite conectarse a otros recursos de GCP, como máquinas virtuales, bases de datos y servicios de almacenamiento.

## Que son las Rutas y las reglas de firewall en GCP?

En términos generales, una ruta es un conjunto de direcciones IP que permiten conectar con un destino específico. En Google Cloud es fundamental comprender que cada red tiene rutas por defecto que permiten el tráfico entre las instancias de la misma red. Asimismo, cada red tiene una ruta predeterminada para dirigir paquetes fuera de la red, sin embargo, es posible crear rutas especiales que anulen las rutas predeterminadas, aunque es importante tener en cuenta que crear una ruta no garantiza que el paquete llegue al siguiente paso especificado.
Es necesario tener en cuenta el manejo de las direcciones IP para nuestros servicios. Cada servicio tiene dos direcciones IP: una externa que permite la comunicación con fuentes externas a la red y que es efímera, lo que significa que cambia cada vez que se destruye o se recrea el servicio, y otra interna que solo se puede utilizar dentro de la red y está asociada al nombre del servicio y no cambia.

Las rutas emparejan paquetes mediante las direcciones IP de destino. No obstante, no se produce tráfico sin una regla de firewall que lo permita.

Un firewall es una herramienta que controla el tráfico de red que entra y sale de nuestros recursos en la nube. En GCP, podemos configurar reglas de firewall para servidores de máquinas virtuales (VMs), instancias de Kubernetes, bases de datos y otros recursos.

Las reglas de firewall permiten o bloquean el tráfico entrante o saliente (Ingress o Egress). Además, podemos crear reglas de firewall para redireccionar el tráfico a otra dirección IP o puerto. Estas reglas son útiles para especificar el tráfico permitido desde direcciones IP específicas, así como el puerto y el protocolo que deseamos permitir.

## Buenas prácticas

Es importante tener en cuenta que el diseño de la red VPC debe ser considerado desde el inicio del proceso de configuración organizativa en Google Cloud, ya que varias opciones de diseño a nivel organizativo no se pueden revertir fácilmente más adelante en el proceso.

Mantener simple la topología de la red es importante para garantizar la mantenibilidad, fiabilidad y el buen entendimiento de nuestra arquitectura.

**Asignación de nombres:**

Al asignar los nombres a nuestros componentes de red se deben tener en cuenta ciertas sintaxis sugeridas para mantener un mejor entendimiento de nuestros proyectos:

- **Red VPC** sintaxis: `{company name}-{description(App or BU)-label}-{environment-label}-{seq#}` ejemplo: `acmeco-hr-dev-vpc-1`
- **Subred** sintaxis: `{company-name}-{description(App or BU)-label}-{region/zone-label}` ejemplo: `acmeco-hr-na-ne1-dev-subnet`
- **Regla de firewall** sintaxis: `{company-name}-{description(App or BU)-label}{source-label}-{dest-label}-{protocol}-{port}-{action}` ejemplo: `acmeco-hr-internet-internal-tcp-80-allow-rule`
- **Ruta IP** sintaxis: `{priority}-{VPC-label}-{tag}-{next hop}` ejemplo: `1000-acmeco-hr-dev-vpc-1-int-gw`

## Diseños comunes de redes en GCP

Los diseños de redes y arquitecturas se basan en los requerimientos de cada proyecto. 

En primer lugar, las podemos ver según su clasificación en GCP:

1. Subredes regionales: son subredes que abarcan toda una región de GCP y permiten la comunicación entre recursos en diferentes zonas de disponibilidad dentro de esa región. 
2. Subredes zonales: son subredes que se limitan a una sola zona de disponibilidad dentro de una región de GCP. Los recursos creados en una subred zonal solo pueden comunicarse con otros recursos en la misma zona. 
3. Subredes privadas: son subredes configuradas sin dirección IP pública y solo se pueden acceder a ellas mediante una conexión VPN o Interconnect dedicado.
4. Subredes con configuración personalizada: son subredes que se pueden personalizar para ajustar la configuración de red, como los rangos de direcciones IP, los puertos abiertos y las etiquetas de red.
5. Subredes secundarias: son subredes adicionales que se pueden crear dentro de una subred existente. Cada subred secundaria tiene su propio rango de direcciones IP y puede tener su propia configuración de red.

En segundo lugar, existen diseños en términos de algunos atributos de calidad que encontramos en las normas [ISO 25010](https://iso25000.com/index.php/en/iso-25000-standards/iso-25010/):

1. Fiabilidad

En términos de fiabilidad en el apartado de disponibilidad tenemos un patrón donde buscamos tener nuestras aplicaciones en múltiples zonas desde la misma subred, en este caso tenemos 2 instancias de la misma aplicación, esto nos mejora la disponibilidad sin incurrir en complejidades de seguridad.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/z0b0uay7gdb8j92rex8w.png)

1.1 Disponibilidad global: En el caso de que nuestras aplicaciones requieran el acceso y disponibilidad en diferentes regiones del mundo se puede contemplar el diseño de redundancia de nuestras aplicaciones en diferentes regiones. Podemos aplicar un loadbalancer global para dirigir el tráfico a la instancia que este más cerca de nuestros usuarios.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ky3we0vkotxnzky2uhrq.png)

1. Seguridad: Una forma de garantizar la conexión segura de nuestras instancias de cómputo hacia el internet público es a través del servicio de GCP Cloud NAT, es un servicio de traducción de direcciones de red que permite provisionar instancias de aplicaciones sin direcciones IP públicas de forma eficiente y controlada.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/n9uav9uibl4oj3bqgi05.png)

## Precios

Dentro del diseño de VPC se tiene que tener en consideración cómo funciona el cobro del flujo de datos bidireccional:

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6bh1suxi7htb2hi5fjie.png)

La siguiente información sale de la documentación de GCP a continuación listare los puntos más relevantes que se deben tener en cuenta a la hora de pensar en nuestra infraestructura de red:

1. No se cobra por el tráfico de salida que va hacia la red de GCP, a menos que se procese a través de un recurso, como un balanceador de carga.
2. Las respuestas a las solicitudes se cobran como tráfico de salida.
3. No se cobra por el tráfico de salida a la misma zona siempre y cuando se haga a través de la dirección IP interna de una instancia.
4. El tráfico de salida a productos de Google, como YouTube, maps, drive, o a un servicio diferente de GCP dentro de la misma región, no se cobra.
5. Se cobra por el tráfico de salida entre zonas en la misma región, el tráfico de salida dentro de una zona si el tráfico es a través de la dirección IP externa de una instancia, y el tráfico de salida entre regiones.
6. Se cobra por las direcciones IP externas estáticas y efímeras y que el precio puede cambiar.
7. Se recomienda el uso de la calculadora de precios de GCP para estimar el costo de una colección de recursos junto con la [documentación](https://cloud.google.com/vpc/network-pricing).

En futuros post expondré los diferentes tipos de optimización de costos en GCP.

Espero que esta pequeña introducción te de las bases de que son y cómo funcionan las VPC, estas son las bases que soportan el funcionamiento y comunicación de los demás servicios de nuestras soluciones en GCP.