Cloud Computing Fundamentals 5.2 - Conceptos Finales de Networking para la Nube

La Recepcionista y La Guía Telefónica

Repaso rápido

Comprender conceptos fundamentales de redes te prepara para construir buenas arquitecturas en la nube, y para diagnosticar fallos cuando tus recursos no se están comunicando entre sí como deberían o estás esperando tráfico desde el afuera y tu recurso rechaza conexiones cuando no debería.

En la parte anterior vimos algunos de estos conceptos organizados en bloques:

• En el Bloque 1 vimos sobre lo que es una dirección IP, su composición (Calle vs Casa), máscara de subred, notación CIDR y cómo estos elementos nos permiten definir subnets, concepto clave del networking dentro de AWS, sobre todo dentro de lo que es la VPC (Virtual Private Cloud).
• En el Bloque 2 tratamos los Puertos y Sockets, que nos permiten definir el perímetro de seguridad a través de componentes como el Security Group y NACL (Network Access Control Lists). También vimos sobre protocolos, como TCP vs UDP, y cómo cambia la oferta de servicios en AWS según la Capa del Modelo OSI a utilizar.

Hoy continuamos con los bloques finales, y con el cierre definitivo de la serie Cloud Computing Fundamentals.

Bloque 3: La Recepcionista (Traducción de Direcciones y Salida a Internet)

1. IPs Privadas y Públicas

En la parte anterior de esta serie vimos que la dirección IP nos indica la calle y la casa de nuestra red, y que mediante subnets podíamos aislar ciertas zonas.

Sin embargo, para dar el salto hacia cómo se comunica esto con la Internet global, tenemos que hacer una distinción vital: existen direcciones IP privadas y direcciones IP públicas.

Si quisiéramos ser exactos, tu red interna (ya sea el Wi-Fi de tu casa o tu VPC en AWS) funciona como un gran edificio corporativo privado.

• La IP Privada (El número de interno): Dentro del edificio, cada oficina tiene un número de interno telefónico corto (por ejemplo, el Interno 402).
  • Si la oficina 402 quiere hablar con la 405, marcan el interno y se comunican sin problemas. Estas son tus IPs Privadas. Así es como tu notebook puede, por ejemplo, comunicarse con tu PC de escritorio que está en otra parte de la casa.
  • Estas IPs privadas son gratis, las usás como querés dentro de tu terreno, pero no existen en el mundo exterior. Nadie desde la calle puede agarrar su celular y marcar "402" esperando que conteste tu oficina.
• La IP Pública (El número oficial): Para que alguien de afuera pueda llamar al edificio, la empresa contrata un número de teléfono oficial, único a nivel mundial (por ejemplo, +54 11 5555-0000). Esta es tu IP Pública. Son limitadas, te las tiene que asignar un proveedor y son las únicas que pueden viajar libremente (son "ruteables") por la Internet global.

Entonces, ¿qué ocurre si la base de datos que tenés escondida en tu Subnet Privada (Interno 402) necesita salir a Internet para descargar una actualización de seguridad? No puede usar su IP privada porque Internet no sabría cómo devolverle el paquete.

Aquí es donde entra en acción el NAT (Network Address Translation).

2. NAT (Network Address Translation)

Antes de que nuestro proveedor de Internet (ISP) pueda redireccionar el paquete, la IPv4 de origen privada debe ser traducida a una dirección pública.

Aquí es donde entra en acción el NAT (Network Address Translation). NAT es utilizado para traducir entre direcciones públicas y privadas y se suele llevar a cabo en el router que conecta la red interna con la red del ISP.

Para explicar, a nivel muy elemental, cómo funciona NAT, vamos con la analogía de la Recepcionista.

Nuestra red es un edificio corporativo. Cada empleado tiene un número de interno telefónico privado (la IP Privada).

Si un empleado quiere pedir una pizza para almorzar, no puede darle su número de interno al restaurante, porque nadie desde la calle puede marcar un interno directamente. En cambio, el empleado llama a la recepcionista (el Router con NAT), quien pide la pizza utilizando el número telefónico público y oficial del edificio (la IP Pública).

Cuando el repartidor llega con la pizza, la recepcionista sabe exactamente a qué empleado y oficina (interno privado) entregársela.

¿Sabes qué es lo más loco? Que vos, y cada hogar con internet, tienen su propia "recepcionista", que es el router hogareño. Asi que cada vez que usas internet, estás usando NAT. De hecho, es gracias a NAT que estás pudiendo leer este blog post.

El servidor que aloja este artículo no tiene idea de tu IP privada, solo de tu IP pública, la IP de tu router. Cuando entraste a https://elingenieroconsciente.com, hiciste una petición desde tu máquina usando tu IP privada.

Esta petición llego al router, mediante NAT hizo la traducción y largó la petición a la red de tu ISP. El ISP llevó la petición hasta el servidor, el servidor respondió a la IP indicada en el paquete, y una vez la respuesta del servidor llegó a tu router, el router te lo devolvió a tu máquina. Nunca nadie supo de tu "número de interno", pero el paquete te llego en tiempo y forma y específicamente a la máquina que usaste para entrar al blog.

¿Magia negra? Sí, lo es (?

El Concepto Aplicado en AWS: Internet Gateway y NAT Gateway

En la consola de AWS, el concepto de conectividad hacia el exterior lo vas a materializar mediante dos componentes dentro de tu VPC (Virtual Private Cloud):

• Internet Gateway (IGW): Es la puerta principal de tu red. Si configurás una Subnet para que tenga una ruta directa al IGW y a tus servidores (instancias EC2) les asignás IPs públicas, estás creando una Subnet Pública.
  • Es bidireccional: tus servidores pueden salir a Internet, y los clientes en Internet pueden conectarse a ellos (ideal para un servidor web o un balanceador de carga).
• NAT Gateway: ¿Te acordás de la regla de oro que mencionamos de jamás poner tu base de datos en una Subnet Pública? Nuestra base de datos vive feliz, oculta y segura en una Subnet Privada. Sin embargo, de vez en cuando, el sistema operativo de esa base de datos necesita salir a Internet para descargar actualizaciones de seguridad.
  • Como no tiene IP pública ni conexión directa al IGW, desplegamos un NAT Gateway en la Subnet Pública y le indicamos a la base de datos que envíe su tráfico hacia allí.
  • El NAT Gateway recibe la petición privada de la base de datos, la "traduce" utilizando su propia IP pública, va a buscar la actualización y se la devuelve. La magia arquitectónica aquí es que el NAT Gateway es unidireccional para las conexiones nuevas: permite que tus recursos privados salgan a Internet, pero bloquea completamente cualquier intento de conexión que alguien desde Internet quiera iniciar hacia ellos.
  • Ojo igual, que el NAT Gateway es bastante carito. Por eso AWS provee otras vías de comunicación cuando necesitamos que recursos desplegados usando distintos servicios de AWS se comuniquen entre sí (como una instancia EC2 escribiendo datos en un bucket de S3 o una tabla de DynamoDB). Ahora, si un recurso sí o sí tiene que hablar con la internet pública, necesitamos NAT Gateway.

Bloque 4: La Guía Telefónica (Capa de Aplicación y la Identidad en la Web)

1. Clientes y Servidores

Hemos mencionado varias veces el término "servidor", y seguramente lo hayas leído más de una vez en cursos, artículos, etc.

El término servidor hace referencia a un host que ejecuta aplicaciones de software que proveen información o servicios a otros hosts conectados a la red. Aunque usamos estos servicios todos los días para acceder al correo, comprar en tiendas en línea, o leer blog posts super interesantes de un tal "Ingeniero Consciente", la mayoría de aplicaciones de internet se basan en complejas interacciones entre servidores y clientes, de las cuales rara vez somos conscientes.

Para comunicarnos a nivel de aplicación (Capa 7 del Modelo OSI), las computadoras y routers son extremadamente felices utilizando direcciones IP (ej: 198.51.100.24).

El problema es que nosotros, torpes humanos, somos generalmente malos para recordar números aleatorios. Es mucho más sencillo manejarnos por nombres. Por eso se inventó DNS.

2. DNS (Domain Name System)

El Domain Name System o DNS es un sistema que traduce nombres de dominio legibles (como example.com ) en direcciones IP entendibles por máquinas.

Para entender cómo funciona el DNS por dentro, nos apoyaremos en la analogía de la guía teléfonica. Imaginate que querés llamar por teléfono a un contacto pero no sabés su número exacto.

1. Tu Libreta Personal (Caché Local): Antes de marcar, revisás la agenda de tu teléfono. En el mundo web, tu navegador consulta su propia memoria caché. Si ya visitaste la página hace poco, el número ya está ahí guardado y la llamada sale directo.
2. Llamar al Operador (DNS Resolver): Si no tenés el número guardado, marcás al operador de asistencia (el Resolver DNS, que suele ser el de tu ISP o uno público como el 8.8.8.8). Le decís: "Hola, necesito llamar a elingenieroconsciente.com" (guiño, guiño).
3. El Recepcionista Central (Root Server): Si el operador tampoco tiene el número anotado en su escritorio, llama a la Recepción Central del país (Root Server). La recepción le dice: "No tengo el número de esa persona en particular, pero acá tenés el contacto de la oficina que maneja a todos los que terminan en .com".
4. El Registro Regional (TLD Server): El operador llama a la oficina del .com (TLD Server). Allí revisan sus tomos y dicen: "El dueño del dominio elingenieroconsciente.com contrató sus registros en la oficina autoritativa X. Acá tenés su dirección".
5. El Notario Oficial (Servidor Autoritativo): El operador consulta al Servidor Autoritativo final, quien tiene el libro oficial de la empresa. Este le confirma: "El número exacto de elingenieroconsciente.com es 198.51.100.24".
6. Respuesta y Memorización (Caché): El operador te devuelve el número a tu teléfono y, para no hacer todo ese recorrido la próxima vez que alguien pregunte, se anota el resultado en una tarjetita en su escritorio durante unas horas (el famoso TTL o Time To Live).

Una vez que tu navegador recibe la IP 198.51.100.24, entabla la comunicación mediante el protocolo HTTP (generalmente usando el puerto 80 o 443).

Dentro de esta guía telefónica, la información se guarda en distintos formatos llamados Registros DNS:

• Registro A: Es la anotación directa de un nombre a un número IPv4 (Ej: "Elias Velázquez" = 198.51.100.24).
• Registro CNAME: Es un alias o apodo que apunta a otro nombre (Ej: Si buscás "El Ingeniero Consciente", el registro te dice "Andá a buscar la entrada de Elias Velázquez y usá ese número").

El Concepto Aplicado en AWS

En el ecosistema de AWS, toda la gestión de dominios y tráfico en la capa de aplicación se controla mediante *Amazon Route 53.

Lo que hace fascinante a Route 53 es que no es simplemente un lugar estático donde guardás tus Registros A o CNAME y te olvidás. Es un servicio altamente disponible y programable que toma decisiones de enrutamiento dinámicas e inteligentes:

• Basado en la Salud (Health Checks): Route 53 puede vigilar constantemente tu servidor principal. Si el servidor deja de responder, Route 53 desvía de manera automática a tus usuarios hacia tu servidor secundario o de respaldo (Disaster Recovery).
• Basado en Geografía o Latencia: Si tenés clientes en Argentina y en Japón, Route 53 puede identificar desde dónde viene la petición del usuario y derivarlo al servidor de AWS que se encuentre geográficamente más cerca de él, reduciendo los tiempos de carga al mínimo.

Conclusión

Y un día hemos llegado al final. Se terminó "Cloud Computing Fundamentals". Si leíste cada post, dejame transmitirte un enorme y sincero "¡Gracias!". Abarcar todos los conceptos que vimos en cada publicación fue un esfuerzo de búsqueda, investigación, organización y más.

Todos los temas que vimos a lo largo de toda esta serie ahora forman parte de nuestra cajita de herramientas, componen la guía básica y esencial para poder ir a fondo con el proveedor que forma uno de los pilares de "El Ingeniero Consciente": Amazon Web Services.

Es momento de entrar a fondo, y para ser sincero, me emociona por fin poder comenzar con una nueva serie de blog posts, que es algo así como iniciar un viaje nuevo.

En "AWS Fundamentals", el nombre con el que decidí bautizar la serie que se viene, vamos a ver:

• Qué es realmente AWS, una breve historia de sus inicios y cómo dar los primeros pasos
• Vamos a analizar muchos servicios esenciales, con IAM y CloudWatch a la cabeza, seguido por pesos pesados como EC2, Lambda, S3, SNS, SQS y más!
• Y para cada servicio explicado, vamos a abordar sus características clave, conceptos esenciales, costos, trade-offs y todo lo que nos permita utilizaro con eficiencia y seguridad en mente

¡Hora de arrancar con AWS! 🚀