Networking Linux Sin Leer un Libro de 500 Paginas

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 dificil de entender. El problema es que intentamos aprenderlo como teoria ” 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

Dia 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.

Leccion: Networking no es teoria. Es flujo. Los paquetes tienen una direccion, y si no saben hacía donde ir, nada funciona.

Los 5 chequeos ” Siempre en este orden

1. La interfaz (no Google)

ip addr show

Preguntas que responder:

La interfaz está UP?
Tiene la IP correcta?
Es la interfaz que crees que es?

Error comun: Debuggear eth0 durante 30 minutos cuando el trafico va por ens192. Los nombres de interfaz cambiaron con systemd/udev ” ya no siempre son eth0. Pueden ser ens192, enp0s3, eno1, etc.

Por que va primero: Si la interfaz está down o tiene IP mal, todo lo demas es irrelevante. No hay capa 2 sin capa 1.

2. La ruta (donde se esconden la mayoria de los problemas)

ip route

Esto es donde la mayoria 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 que 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 asi:

default via 192.168.1.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.8

Si 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 tambien falla.

4. DNS (aburrido hasta que rompe todo)

cat /etc/resolv.conf

Verifica 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.com

Si 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 (ultimo, no primero)

iptables -L -n
# o si usas firewalld:
firewall-cmd --list-all

El firewall es culpado primero en la mayoria 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 estan 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 rapida

# 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 legacy

Nota 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 area donde mas 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.