Networking Linux Sin Leer un Libro de 500 Páginas
Fuente: artículo original de Pawan Natekar en CodeX. Adaptado y ampliado por Sammi De Blas.
El problema real
El problema de networking en Linux no es que sea difícil de entender. El problema es que intentamos aprenderlo como teoría ” capas OSI, diagramas, flechas, palabras fancy. Pero cuando un servidor no llega a la base de datos, nada de eso sirve.
La red falla en capas de realidad, no en capas de libro de texto.
La historia del admin junior
Día normal, el equipo de aplicación escribe: “El servidor no conecta con la BD.”
El junior revisa:
- Servicio corriendo? Si
- Firewall? “Parece bien”
- Reinicia el servicio de red (error crítico)
La red no vuelve. SSH se pierde. El servidor queda inaccesible.
Llega el senior y pregunta una sola cosa: “Comprobaste la ruta?”
No la había comprobado.
Lección: Networking no es teoría. Es flujo. Los paquetes tienen una dirección, y si no saben hacía donde ir, nada funciona.
Los 5 chequeos ” Siempre en este orden
1. La interfaz (no Google)
ip addr showPreguntas que responder:
- La interfaz está UP?
- Tiene la IP correcta?
- Es la interfaz que crees que es?
Error común: Debuggear eth0 durante 30 minutos cuando el tráfico va por ens192. Los nombres de interfaz cambiaron con systemd/udev ” ya no siempre son eth0. Pueden ser ens192, enp0s3, eno1, etc.
Por qué va primero: Si la interfaz está down o tiene IP mal, todo lo demas es irrelevante. No hay capa 2 sin capa 1.
- La ruta (donde se esconden la mayoría de los problemas)
ip routeEsto es donde la mayoría de los problemas de networking se esconden.
Verifica:
- Hay ruta default? Si no, el servidor no sabe como salir a internet o a otras redes
- El gateway es correcto? Un gateway equivocado = paquetes que van al vacio
- Hay rutas conflictivas? Dos rutas para el mismo destino pueden causar comportamiento impredecible
Por qué va segundo: Si Linux no sabe donde enviar los paquetes, no importa cuanto sepas de firewalls o DNS. Sin ruta, no hay comunicación.
La ruta default se ve así:
default via 10.10.10.1 dev ens192
Si no la ves, el servidor no sale a ningun sitio que no sea su propia red.
3. Ping (pero sin confiar ciegamente)
ping -c 3 8.8.8.8Si funciona:
- La capa IP funciona
- El routing funciona
- Tienes salida a internet
Si falla:
- Para de culpar al DNS ” DNS trabaja encima de IP, si IP no llega, DNS tampoco
- Para de tocar el firewall ” el firewall filtra paquetes que ya llegaron, si no llegan, el firewall no es el culpable
- Arregla el routing primero ” siempre
Ping miente a veces: Un ping exitoso no significa que todo funciona. Solo significa que ICMP llega. DNS, HTTP, SSH pueden seguir fallando por otros motivos. Pero si ping falla, todo lo demas también falla.
4. DNS (aburrido hasta que rompe todo)
cat /etc/resolv.confVerifica que los nameservers son correctos. Un error que se ve mucho:
nameserver 127.0.0.1
Si no hay servicio DNS local corriendo, esto significa que el servidor se pregunta a si mismo por las DNS y no tiene respuesta.
Test rápido:
nslookup google.comSi ping 8.8.8.8 funciona pero nslookup google.com falla, estas en infierno DNS ” el routing está bien, pero la resolución de nombres no.
DNS es la capa que todos olvidan hasta que falla, y cuando falla, TODO falla ” SSH por hostname, conectores de BD por nombre, APIs, certificados TLS. Todo depende de DNS.
5. Firewall (último, no primero)
iptables -L -n
# o si usas firewalld:
firewall-cmd --list-allEl firewall es culpado primero en la mayoría de los casos injustamente.
En realidad:
- Si la ruta está mal, el firewall es inocente
- Si DNS no resuelve, el firewall es inocente
- Si la interfaz está down, el firewall es inocente
Solo comprueba el firewall cuando las 4 capas anteriores están verificadas y correctas.
Lo que hacen los seniors diferente
Trazan el paquete mentalmente, siempre:
Interfaz <-’ Ruta <-’ Gateway <-’ DNS <-’ Firewall
Cada. Misma. Vez.
No saltan al paso 5 cuando el problema está en el paso 2. No reinician servicios de red sin saber que hay detras. No asumen que “si ping funciona, todo funciona”.
Pasan de “la red no funciona” a “el paquete se pierde en X punto” en minutos, no horas.
Los mitos que hay que romper
| Mito | Realidad |
|---|---|
| ”Si IP esta, la red funciona” | IP es solo capa 3. Puede tener IP y no tener ruta |
| ”Si ping funciona, todo funciona” | Ping es ICMP. DNS, TCP, puertos especificos pueden seguir fallando |
| ”Es problema del firewall” | Casi nunca es el firewall cuando revisas bien otras capas |
| ”Reinicia el servicio de red” | Esto puede tirar SSH y dejarte sin acceso al servidor |
| ”Los nombres de interfaz siempre son eth0” | Con systemd, pueden ser ens192, enp0s3, eno1… |
Comandos de referencia rápida
# 1. Interfaz
ip addr show
ip link show
# 2. Ruta
ip route
ip route get 8.8.8.8 # Que ruta toma un paquete a 8.8.8.8?
# 3. Ping
ping -c 3 8.8.8.8 # IP reachability
ping -c 3 google.com # DNS + IP reachability
# 4. DNS
cat /etc/resolv.conf
nslookup google.com
dig google.com # Mas detalle que nslookup
host -t A google.com # Rapido y limpio
# 5. Firewall
iptables -L -n -v # Verbose, muestra contadores
firewall-cmd --list-all # Si usas firewalld
nft list ruleset # Si usas nftables
# Extra: ver conexiones activas
ss -tulnp # Puertos abiertos y procesos
ss -s # Resumen de sockets
# Extra: traceroute
traceroute 8.8.8.8 # Ver cada salto hasta el destino
mtr 8.8.8.8 # traceroute continuo (mejor)
# Extra: ARP
ip neigh # Tabla ARP (quien esta en mi LAN?)
arp -a # Version legacyNota sobre el artículo original
El artículo original es parte de una serie escrita desde la perspectiva de un sysadmin trabajando, no de alguien que lee libros. Es práctico y directo — algo que la traducción automática de Medium pierde casi por completo.
Tiene razon en algo fundamental: los sysadmins son los que saben de todo un poco — red, OS, hardware, cloud. No son maestros de ningun domain, pero son los únicos que pueden trazar un problema de extremo a extremo. Y networking es el área donde más admins se bloquean por miedo, no por falta de capacidad.
El flujo (Interfaz → Ruta → Ping → DNS → Firewall) no es nuevo, pero es la disciplina de seguirlo siempre en orden lo que separa a un admin que resuelve en 5 minutos de uno que rompe cosas en 30.
Fuente: artículo original de Pawan Natekar en CodeX. Adaptado y ampliado por Sammi De Blas.