Siempre me ha dado risa que la gente piense que un firewall es un muro de ladrillos literal o que un load balancer reparte pesas en el gimnasio. Son conceptos que aparecen todo el tiempo cuando estás configurando un VPS, levantando un sitio, o simplemente tratando de entender por qué tu conexión va lenta. Acá va una guía directa, sin floro, de los conceptos de networking que me hubiera gustado que alguien me explicara cuando empecé.
VPN: no es solo para ver Netflix de otro país
Cuando empecé a trabajar con servidores remotos, pensaba que las VPN eran solo para saltar geobloqueos. Pero en la práctica, una VPN te permite conectarte a una red privada desde cualquier lugar como si estuvieras físicamente ahí. Si administrás un servidor en un datacenter o tenés un proyecto en la universidad que requiere acceso a recursos internos, la VPN es tu puerta de entrada segura.
La advertencia que me tocó aprender a las malas: una VPN mal configurada —usando protocolos viejos como PPTP o contraseñas débiles— es tan peligrosa como no tener nada. Usá WireGuard o OpenVPN con autenticación robusta, y si podés, activá MFA. No confíes solo en que «está encriptado»; verificá que la configuración sea sólida.
Firewall: más que un portón con guardia
El firewall filtra tráfico basado en reglas. La clave está en entender que no se trata solo de bloquear puertos; se trata de conocer el estado de las conexiones. Un firewall stateful rastrea sesiones activas, lo que significa que no solo mira si un paquete «parece legítimo», sino que verifica si corresponde a una conversación real.
Mi regla personal: todo bloqueado por defecto. Solo abro lo que necesito, cuando lo necesito, y documento por qué. Parece exagerado hasta que descubrís que un servicio olvidado expuesto a internet fue el punto de entrada de un ataque. Mantené las reglas limpias, auditá cada tanto, y eliminá lo que no usás.
NAT y VLAN: separar para proteger
NAT permite que varios dispositivos compartan una sola IP pública. Es lo que hace tu router en casa y lo que permite no exponer cada máquina interna directamente a internet. Pero ojo: NAT no es seguridad. Es conveniencia de direccionamiento. No confundamos las dos cosas.
VLAN, por otro lado, te permite dividir una red física en segmentos lógicos. En mi experiencia, separar el tráfico de proyectos distintos mediante VLANs evita que un problema en un lado contamine al otro. Es como tener habitaciones separadas en una casa: si se prende fuego una, las otras no se queman inmediatamente.
Load Balancer: distribución inteligente
Un load balancer reparte el tráfico entre varios servidores. El algoritmo más simple es round-robin (uno tras otro), pero en producción real necesitás health checks: si un servidor deja de responder, el load balancer debe sacarlo automáticamente del grupo antes de que los usuarios se den cuenta.
Además, muchos load balancers modernos manejan terminación TLS (desencriptan HTTPS para aliviar carga a los backends), cachean contenido estático, y aplican rate limiting contra ataques. No es solo «repartir»; es el primer filtro de defensa de tu aplicación.
API vs REST API: cuando el protocolo importa
Una API es cualquier interfaz programática. REST API es un tipo específico que usa HTTP con verbos claros: GET para leer, POST para crear, PUT para actualizar, DELETE para eliminar. No toda API es REST, y no toda API REST está bien implementada. He visto supuestas «REST APIs» que usan POST para todo, violando el principio básico de semántica HTTP.
Si estás construyendo o consumiendo APIs, mi recomendación: usá autenticación OAuth 2.0 con scopes granulares, implementá rate limiting por endpoint, y validá estrictamente los inputs. Un endpoint sin validación es una invitación abierta a inyecciones y escalada de privilegios.
Modelo OSI: siete capas para diagnosticar
El modelo OSI tiene siete capas: física, enlace de datos, red, transporte, sesión, presentación y aplicación. Cuando algo no funciona, la pregunta correcta no es «¿reiniciaste el router?», sino «¿en qué capa falla?».
DNS no resuelve (capa 7), TCP no establece conexión (capa 4), o simplemente el cable está desconectado (capa 1). Saber aislar el nivel de falla ahorra horas de troubleshooting aleatorio. Es como ir al médico: no tratás todo con paracetamol; primero diagnosticás.
HTTP, DNS, TCP y UDP: el tráfico real
HTTP es el protocolo de la web, pero HTTP/2 y HTTP/3 cambiaron las reglas con multiplexación y QUIC sobre UDP. DNS parece simple hasta que un ataque de envenenamiento de cache te redirige a un sitio falso. TCP garantiza entrega ordenada y confiable; UDP prioriza velocidad sobre confiabilidad.
En la práctica, esto significa que streaming de video, DNS queries y llamadas VoIP usan UDP porque la latencia importa más que retransmitir un paquete perdido. Pero un pico de tráfico UDP hacia puertos altos puede ser un ataque de amplificación DNS. Y conexiones TCP SYN que nunca completan (SYN flood) son el clásico ataque de denegación de servicio. Si entendés el handshake de tres vías de TCP, podés identificar estos patrones en tus logs.
La recomendación final
Estos conceptos no son solo teoría para aprobar un examen. Son herramientas que usás todo el tiempo, aunque no te des cuenta. Configurar una regla de firewall sin entender stateful inspection, o desplegar un load balancer sin health checks, o diseñar una API sin rate limiting, son decisiones que parecen funcionar hasta que dejan de funcionar en el peor momento.
Mi consejo: dominá estos fundamentos antes de agregar complejidad. No tiene sentido implementar arquitecturas avanzadas si tu segmentación básica está mal hecha o si no entendés cómo funciona la capa de red que todo sostiene. La red es el piso; si se mueve, todo lo que construyas encima se resquebraja. Empezá por acá, y el resto se hace más fácil.
