Networking

Redes en Linux

Resumen

Esta guía de estudio independiente explica cómo Linux asigna direcciones, elige una ruta, resuelve nombres y comprueba cada etapa. No es material oficial ni está afiliada a la Linux Foundation. La idea central es separar capas: una interfaz puede estar activa sin ruta, una ruta puede existir aunque DNS falle y un servicio puede escuchar aunque el firewall bloquee. Diagnosticar por capas evita atribuir a la red fallos del host.

Objetivos de aprendizaje

• Interpretar direcciones IPv4/IPv6, prefijos y máscaras.
• Configurar y verificar direcciones, enlaces y rutas con ip.
• Distinguir puerto en escucha, conexión y servicio accesible.
• Delimitar alcance y saltos con ping y traceroute.
• Explicar DNS y el papel de /etc/hosts y /etc/resolv.conf.
• Interpretar DHCP, MTU y el filtrado del host dentro de un diagnóstico por capas.

Prerrequisitos y conexiones

Se asume familiaridad con la terminal y los servicios; repasa Command Line y Administración de sistemas. Prepara Resolución de problemas.

Direcciones, interfaces y prefijos

Una interfaz es el punto por el que el host envía y recibe tramas: eth0, ens3, wlan0 o lo. ip link show muestra su estado; ip addr show añade direcciones. Loopback lo usa 127.0.0.1 y ::1, y debe estar activa para la comunicación local. ip -br address ofrece una vista compacta para inventario y soporte.

Una dirección IPv4 lleva un prefijo que indica cuántos bits identifican la red. En 192.0.2.10/24, 24 bits son red y 8, host; la máscara es 255.255.255.0, la red 192.0.2.0 y la difusión 192.0.2.255. En IPv6 el prefijo habitual de subred es /64, aunque se permiten otros tamaños.

ip -br link
ip -br address
sudo ip addr add 192.0.2.10/24 dev eth0
sudo ip link set eth0 up
ip addr show dev eth0

Los cambios con ip son temporales: desaparecen al reiniciar o recrear la interfaz. La configuración persistente depende de la distribución; Ubuntu Server suele usar Netplan y otras usan NetworkManager o archivos propios. Comprueba el estado activo con ip, no solo el archivo: una interfaz puede quedar sin dirección tras un cambio fallido.

IPv6 puede configurarse de forma estática o automática. ip -6 addr show muestra direcciones y estados: tentative indica detección de duplicados y deprecated que no se usa para conexiones nuevas. El origen depende de la ruta y de las políticas del kernel. ping -6 ::1 confirma que la pila local funciona.

nmcli frente a ip

ip habla con el kernel: refleja y modifica el estado vigente sin persistencia. nmcli gestiona NetworkManager, que guarda los perfiles y los reaplica en cada arranque. La combinación habitual es diagnosticar con ip y cambiar de forma duradera con nmcli.

Tarea	ip	nmcli
Ver direcciones	ip -br address	nmcli device status
Activar el enlace	sudo ip link set eth0 up	nmcli device connect eth0
Asignar dirección	sudo ip addr add 192.0.2.10/24 dev eth0	nmcli con mod perfil ipv4.addresses 192.0.2.10/24
Puerta de enlace	sudo ip route add default via 192.0.2.1	nmcli con mod perfil ipv4.gateway 192.0.2.1
Ver el estado	ip route show	nmcli con show --active

Si cambias con ip y reinicias, la dirección desaparece; si cambias con nmcli y reinicias, persiste. Cuando ambos se contradicen —por ejemplo, NetworkManager reescribe lo que fijaste a mano al reconectar—, gana la fuente que gestiona la interfaz. nmcli con show lista los perfiles y sus propiedades para comprobar qué quedó realmente guardado.

DHCP y configuración automática

DHCP asigna dirección, máscara, puerta de enlace y servidores DNS desde un ámbito configurado en el servidor. La secuencia del cliente tiene cuatro mensajes: descubrimiento, oferta, solicitud y confirmación; después el servidor renueva la concesión antes de que venza y puede retirarla cuando el ámbito lo decide. En el equipo, el resultado se ve igual que en una asignación estática: la dirección en ip -br address y la ruta por defecto en ip route show.

Los fallos típicos son un ámbito agotado, un servidor fuera de la VLAN del cliente o un agente relay que no reenvía las peticiones. journalctl -u NetworkManager -n 50 muestra los intentos del gestor; si la interfaz termina con una dirección 169.254.0.0/16, el autollamado indica que ningún servidor respondió. Comprueba el ámbito y el camino hasta el servidor antes de culpar al equipo.

VLAN y dominios de enlace

Una VLAN separa dominios de broadcast sobre el mismo medio: las interfaces del host se crean como subinterfaces —eth0.100 para la VLAN 100— y el switch transporta los tramas etiquetados. ip -d link show revela el tipo y el identificador de VLAN de cada subinterfaz. Una dirección configurada en eth0 no responde si la etiqueta correcta no llega desde el switch: la interfaz puede estar UP y el tráfico seguir incompleto.

Al diagnosticar, distingue tres planos: que la subinterfaz exista y esté activa, que tenga dirección dentro del prefijo correcto y que el switch entregue los tramas de esa VLAN. Un error de etiqueta se manifiesta como ausencia de vecinos en el enlace, no como fallo en la tabla de rutas.

Rutas, puerta de enlace y decisión de envío

El kernel consulta la tabla de rutas para decidir interfaz y siguiente salto. ip route show las lista; default via 192.0.2.1 dev eth0 envía por eth0 el tráfico sin coincidencia más específica. Una ruta directa como 192.0.2.0/24 dev eth0 indica que esa subred se alcanza en el enlace local, sin router intermedio.

Gana el prefijo más específico: /32 o /128 sobre /24, y esta sobre la ruta por defecto. ip route get 198.51.100.20 muestra la decisión para un destino, con interfaz y origen; es más preciso que leer la tabla. ip neigh relaciona IP locales con MAC, y FAILED o INCOMPLETE sugiere que el host no responde en el enlace.

ip route show
ip route get 198.51.100.20
sudo ip route add 198.51.100.0/24 via 192.0.2.1 dev eth0
sudo ip route add default via 192.0.2.1 dev eth0

Antes de añadir una ruta, comprueba que la puerta de enlace pertenece a una subred alcanzable. Una ruta por defecto con gateway inalcanzable no mejora nada: el kernel acepta la entrada pero no envía paquetes. ping -c 4 192.0.2.1 verifica el primer salto; si falla, revisa cable, VLAN, interfaz y router antes de tocar rutas lejanas.

Puede haber varias rutas por defecto con distinta métrica; el kernel prefiere la menor y cambia si desaparece. Con varias interfaces, una ruta por defecto mal elegida hace que las respuestas salgan por una interfaz distinta de la que recibió la petición. ip route get con la dirección remota revela ese escenario.

MTU y tamaño de trama

Cada enlace admite un MTU predeterminado —1500 bytes en Ethernet— y los equipos intermedios no suelen aceptar tramas mayores. ip link show muestra el MTU de cada interfaz y sudo ip link set dev eth0 mtu 1400 lo reduce temporalmente. Si un origen envía tramas más grandes que el MTU del camino, el router intermedio las descarta o las fragmenta según el protocolo y sus políticas.

Una pista clásica: funciona el tráfico pequeño y se corta o se congela la transferencia grande. ping -M do -s 1472 198.51.100.20 envía paquetes con el bit de «no fragmentar»: 1472 de datos más 8 de cabecera ICMP y 20 de IP suman 1500. Si con ese tamaño no hay respuesta y con -s 1400 sí, el MTU del camino es menor que el del origen. Baja el MTU de la interfaz o corrige el dispositivo que anuncia un valor incompatible; el servicio remoto no tiene por qué enterarse.

ip link show
ping -M do -s 1472 198.51.100.20
ping -M do -s 1400 198.51.100.20
sudo ip link set dev eth0 mtu 1400

Puertos, sockets y servicios

ss inspecciona sockets del kernel y sustituye a netstat. ss -tulpn muestra TCP y UDP en escucha con procesos y puertos; requiere privilegios para ver procesos ajenos. ss -tan lista conexiones TCP y ss -s resume sockets por tipo. Un servicio puede estar activo en systemd sin escuchar en el puerto esperado.

ss -tulpn
ss -tan state established
ss -s

Interpreta la dirección local. 127.0.0.1:5432 solo acepta conexiones locales; 0.0.0.0:5432 escucha en todas las interfaces IPv4; [::]:5432 hace lo equivalente en IPv6. Si el puerto aparece en 127.0.0.1, el problema remoto es la dirección de escucha. Si está en 0.0.0.0 y no responde, revisa firewall y rutas.

ping comprueba alcance con ICMP y mide ida y vuelta. ping -c 4 192.0.2.1 envía cuatro paquetes; sin -c continúa hasta interrumpirlo. Que ICMP falle no demuestra que TCP falle: algunos equipos lo filtran. traceroute -n 198.51.100.20 muestra los saltos sin resolver nombres. Una fila * * * indica que ese salto no respondió, no que el destino sea inalcanzable.

TCP frente a UDP

Aspecto	TCP	UDP
Sesión	handshake de tres vías antes de intercambiar datos	sin sesión; cada datagrama es independiente
Orden y pérdida	reordena y retransmite lo que no llega	no reordena ni retransmite
Cabecera	20 bytes mínimo, con números de secuencia	8 bytes, sin control de flujo
Uso habitual	HTTP, SSH, SMTP, transferencias	DNS, DHCP, NTP, tráfico en tiempo real
Estados en ss	LISTEN, ESTABLISHED, TIME_WAIT	sin estados equivalentes; ss -ulnp lista la escucha

ss -tan filtra conexiones TCP y ss -uan las de UDP. Un servicio UDP no responde a la prueba que funciona con TCP: para comprobarlo hace falta una herramienta que hable ese protocolo, no solo un puerto visto en la lista de escucha. TIME_WAIT después de cerrar una conexión es normal y no indica una fuga: el kernel mantiene el estado unos segundos para descartar paquetes tardíos que podrían confundirse con una sesión nueva.

Filtrado en el host

El firewall del host decide qué paquetes llegan hasta el proceso. En distribuciones recientes las reglas viven en nftables; nft list ruleset las muestra y las utilidades de sintaxis clásica operan sobre el mismo subsistema. Consultar es inocuo: sudo nft list ruleset y sudo iptables -L -n solo leen la tabla.

Las reglas se evalúan en orden dentro de cada cadena y las primeras coincidencias ganan, de modo que el resto puede no revisarse. Una política de entrada DROP acompañada de permisos explícitos para SSH y HTTP es más predecible que una política ACCEPT con negaciones concretas después. Tras cada cambio, verifica desde fuera: ss -tulpn confirma que el proceso escucha, pero no que el paquete llegue, y guardar la regla en el gestor de configuración evita que el reinicio la pierda.

sudo nft list ruleset
sudo iptables -L -n
ss -tulpn

Resolución de nombres y DNS

Linux resuelve según /etc/nsswitch.conf; lo habitual es probar files y luego dns. files consulta /etc/hosts. dns usa los servidores de /etc/resolv.conf, con directivas nameserver, search y options. Si un gestor de red genera ese archivo, editarlo a mano no persiste.

El DNS es una base jerárquica y distribuida. Un resolutor pregunta a servidores recursivos, que recorren la jerarquía hasta una respuesta autoritativa y la almacenan según el TTL. A asocia IPv4 y AAAA, IPv6; CNAME crea alias; MX señala correo; NS delega zonas; PTR resuelve de forma inversa. Los RFC 1034 y 1035 describen el diseño y los formatos.

getent hosts example.com
cat /etc/resolv.conf
cat /etc/hosts
ping -c 2 example.com

getent hosts usa la misma ruta que las aplicaciones, por lo que es más representativo que leer un archivo. Si ping 198.51.100.20 funciona pero ping example.com no, hay IP y el fallo está en DNS. Revisa /etc/resolv.conf, los servidores y el dominio de búsqueda; un search incorrecto convierte nombres cortos en FQDN inesperados.

Vecinos, ARP y descubrimiento IPv6

Para enviar una trama en el enlace local, el host necesita la dirección MAC del destino o de su router. En IPv4 eso lo resuelve ARP; en IPv6, el Protocolo de Descubrimiento de Vecinos (NDP). ip neigh show presenta la tabla de vecinos y ip -6 neigh show la equivalente para IPv6. Los estados REACHABLE, STALE, DELAY, PROBE y FAILED describen la confianza con la que el kernel conserva cada entrada.

Una entrada FAILED significa que la resolución no obtuvo respuesta; no prueba que el servicio remoto esté caído, porque el problema puede estar en el enlace, en la VLAN o en el filtrado del switch. sudo ip neigh flush dev eth0 borra las entradas de una interfaz y fuerza una nueva resolución, útil cuando se ha cambiado un router o una dirección y el caché conserva datos viejos. En IPv6, ip -6 neigh permite comprobar si el vecino responde a la solicitud de descubrimiento; si la dirección es tentative, el host aún está verificando que no exista un duplicado y no la usa para tráfico nuevo.

Pruebas de puerto y captura de tráfico

ss dice qué escucha el host; para comprobar si un puerto remoto acepta conexiones hace falta generar tráfico. nc -vz 198.51.100.20 443 intenta una conexión TCP y distingue entre rechazo, tiempo de espera y éxito. La interpretación importa: un rechazo inmediato suele indicar que el paquete llegó y no había servicio o que una regla respondió con un rechazo; un tiempo de espera apunta a filtrado silencioso o a una ruta que no devuelve respuesta.

Para ver el tráfico real, tcpdump captura paquetes en una interfaz. sudo tcpdump -i eth0 -nn port 443 muestra direcciones y puertos sin resolver nombres, lo que evita confundir un fallo de DNS con un fallo de conexión. -c 20 limita la captura y -w salida.pcap la guarda para analizarla después. Capturar en el cliente y en el servidor al mismo tiempo revela en qué punto desaparece el paquete: si sale del cliente y no llega al servidor, el problema está en el camino; si llega y no hay respuesta, el filtrado o el servicio son los sospechosos.

Consultas DNS directas e inversas

dig consulta el DNS sin depender de la configuración del sistema y muestra la respuesta completa: sección de respuesta, TTL, servidor que respondió y código de estado. dig example.com A pide la dirección IPv4; dig example.com MX consulta el correo; dig +short example.com reduce la salida a los datos. dig @192.0.2.53 example.com obliga a preguntar a un servidor concreto, lo que separa un problema del resolutor local de un problema de la zona.

La consulta inversa dig -x 198.51.100.20 busca el nombre asociado a una IP mediante el registro PTR. Un PTR ausente o incoherente no rompe la navegación, pero afecta a correo y a registros. Comparar dig example.com con getent hosts example.com distingue la respuesta del DNS de la ruta que usan las aplicaciones: si dig responde y getent no, revisa /etc/nsswitch.conf y /etc/hosts antes de culpar al servidor.

Reglas de enrutamiento y origen

Además de la tabla principal, el kernel admite tablas adicionales y reglas que deciden cuál consultar. ip rule show lista esas reglas por prioridad; ip route show table main muestra la tabla principal. Una regla puede seleccionar una tabla según la dirección de origen, la interfaz de entrada o una marca, lo que permite que un equipo con varias redes use una salida distinta para cada una.

ip route get 198.51.100.20 from 192.0.2.10 combina destino y origen y muestra la decisión resultante, incluida la tabla aplicada. Este detalle explica fallos que la tabla principal no revela: una respuesta puede salir por una interfaz distinta de la que recibió la petición si las reglas no están alineadas. Al depurar, comprueba reglas y tablas en ese orden, y recuerda que los cambios con ip rule también son temporales salvo que los persista el gestor de red.

Ejemplos prácticos

Un servidor nuevo no responde en su dirección prevista. ip -br address muestra eth0 en UP pero sin IPv4. Se añade 192.0.2.10/24, se comprueba ip route get 198.51.100.20 y se hace ping -c 2 192.0.2.1. Luego ss -tulpn confirma 0.0.0.0:8080. Si funciona en local pero no en remoto, revisa ruta de retorno y firewall.

Un equipo resuelve nombres internos pero no externos. /etc/hosts contiene la entrada interna y /etc/resolv.conf apunta a un servidor que no responde. getent hosts example.com falla y ping 198.51.100.20 funciona: la IP es correcta y DNS no. Corregir el resolver y repetir getent confirma la solución.

Errores frecuentes

• Confundir interfaz activa con conectividad completa.
• Asignar un prefijo incorrecto y romper el acceso al gateway.
• Añadir una ruta por defecto sin comprobar que el gateway responde.
• Interpretar 127.0.0.1 como escucha en toda la red.
• Declarar caído un host porque ping no responde e ICMP está filtrado.
• Editar /etc/resolv.conf cuando el gestor lo regenera.

Puntos clave para el examen

• ip addr, ip link y ip route muestran y modifican el estado; los cambios son temporales.
• El prefijo define la subred; la ruta más específica gana.
• ip route get confirma la decisión para un destino.
• ss -tulpn muestra puertos; 0.0.0.0 no equivale a 127.0.0.1.
• ping prueba ICMP y traceroute muestra saltos; ninguno sustituye probar la aplicación.
• DNS combina hosts, resolv.conf y la jerarquía; getent hosts prueba la ruta real.

Recursos externos

• ip(8)
• ss(8)
• ping(8)
• traceroute(8)
• RFC 1034: Domain Names - Concepts and Facilities
• RFC 1035: Domain Names - Implementation and Specification

Autoevaluación

1. ¿Qué significa 192.0.2.10/24? Respuesta: Los primeros 24 bits identifican la red 192.0.2.0 y los últimos 8, el host; la máscara es 255.255.255.0.

2. ¿Cómo se comprueba por dónde saldrá un paquete hacia 198.51.100.20? Respuesta: Con ip route get 198.51.100.20, que muestra interfaz, siguiente salto y origen según la tabla y las políticas.

3. ¿Qué diferencia hay entre 127.0.0.1:8080 y 0.0.0.0:8080? Respuesta: El primero solo acepta conexiones locales; el segundo escucha en todas las interfaces IPv4 si el firewall lo permite.

4. ¿Por qué ping puede fallar aunque el servicio web funcione? Respuesta: Porque ICMP puede estar filtrado y no es el mismo protocolo que TCP/HTTP. Prueba el puerto y solicita el recurso.

5. ¿Qué archivo define los servidores DNS y qué otro puede resolver antes? Respuesta: /etc/resolv.conf define los servidores; /etc/hosts puede resolver antes según /etc/nsswitch.conf.