Al cerrar el módulo 5 sabías diseñar el direccionamiento de una red como la de Grupo Meridiano de punta a punta. Pero una red bien diseñada también falla: Marta no llega a la intranet, un ping se pierde a mitad de camino, el DNS resuelve raro. En este módulo vamos a convertir lo que sabes en un método de diagnóstico, y el primer paso es sistematizar el botiquín. Las herramientas de esta lección ya han ido apareciendo puntualmente a lo largo del curso (ping en el módulo 2, arp -a con Ethernet, nslookup con DNS, ss con los sockets, ip route con TCP/IP); ahora las afilamos: qué opciones importan, cómo leer sus salidas como un profesional y — sobre todo — cuándo usar cada una. Trabajaremos siempre en paralelo Windows/Linux, porque en Meridiano (y en casi cualquier empresa) conviven ambos: los PC de Marta y Ana son Windows, el servidor de la intranet (192.168.10.10) es Linux.

1. Ver la configuración propia: ipconfig /all vs ip addr + ip route
2. ping a fondo: opciones, TTL, pérdida y jitter
3. traceroute/tracert: ver el camino salto a salto
4. arp -a: confirmar la capa 2
5. nslookup y dig: interrogar al DNS con precisión
6. netstat/ss: repaso operativo
7. curl: el comprobador de la capa de aplicación
8. Tabla final: síntoma → primera herramienta

Antes de culpar a la red, mira tu propia configuración. Es el equivalente a comprobar que el coche tiene gasolina antes de llamar a la grúa. En Windows, el comando es ipconfig /all (el /all es importante: sin él no verás la MAC, el servidor DHCP ni los DNS).

En el PC de Marta, en Valencia:

Lectura línea a línea, en el orden en que un profesional la mira:

• Dirección IPv4: ¿es la esperada? 192.168.10.21 es la reserva DHCP de Marta (asociada a su MAC 5c:26:0a:4b:91:d3, como vimos en el módulo 2). Si aquí apareciera 169.254.x.x (APIPA, módulo 5), el diagnóstico casi está hecho: el DHCP no respondió.
• Máscara de subred: /24 correcto. Recuerda el caso de la máscara /25 mal puesta del módulo 5: una máscara errónea produce fallos asimétricos muy confusos.
• Puerta de enlace predeterminada: sin ella, no hay salida de la red local. Vacía o incorrecta = el caso de Jon en el módulo 3.
• Servidores DNS: si la IP y la gateway están bien pero "no funciona internet", el sospechoso habitual es este campo.
• DHCP habilitado / concesión: te dice si la IP es dinámica y cuándo caduca. Útil para saber si un ipconfig /release + /renew tiene sentido.

En Linux, la misma información se reparte en dos comandos que ya presentamos en el módulo 4. En el servidor de la intranet:

• state UP y LOWER_UP: el interfaz está administrativamente activo y tiene link físico (cable/portadora). Si falta LOWER_UP, estás ante un problema de capa 1 — el cable de Ana del módulo 3.
• inet 192.168.10.10/24: IP y máscara en notación CIDR, en una sola línea.
• default via 192.168.10.1: la ruta por defecto, es decir, la gateway.
• Los DNS en Linux se consultan aparte: cat /etc/resolv.conf (o resolvectl status en sistemas con systemd-resolved).

Ese orden no es casual: es "capa 1 primero" (módulo 3) aplicado a tu propia máquina.

ping (módulo 2) envía ICMP Echo Request y espera Echo Reply. Es la herramienta de conectividad por excelencia, pero su salida dice mucho más que "responde / no responde".

Diferencia clave entre sistemas: Windows envía 4 paquetes y para; Linux envía indefinidamente hasta que pulsas Ctrl+C.

El ping continuo (-t) es oro para problemas intermitentes: lo dejas corriendo mientras reproduces el fallo. Y las opciones de tamaño + no fragmentar son exactamente lo que usamos en el módulo 4 para diagnosticar el problema de MTU en la VPN con Bilbao.

Marta hace ping a la intranet y al PC de Jon en Bilbao:

Lectura experta:

• TTL=64 desde la intranet: recuerda del módulo 2 que cada router resta 1 al TTL. Los valores iniciales típicos son 64 (Linux), 128 (Windows) y 255 (equipos de red). TTL=64 sin restar nada te dice dos cosas: el servidor está en tu misma red (0 saltos) y probablemente es Linux.
• TTL=126 desde Bilbao: 128 − 126 = 2 saltos → el PC de Jon es Windows (partió de 128) y hay 2 routers en medio (el de Valencia y el de Bilbao, a través del túnel VPN). El TTL te permite inferir saltos y sistema operativo sin tocar el destino.
• Tiempos: <1 ms en LAN es normal; ~40 ms a Bilbao por la VPN, razonable. Fíjate en el cuarto paquete: 112 ms. Esa variación entre tiempos se llama jitter, y es la que arruina videollamadas y VoIP aunque la media sea buena.
• Pérdida de paquetes: 0% es lo esperable en LAN. Un 2–5% sostenido ya degrada notablemente TCP (retransmisiones) y destroza el tiempo real. La veremos "en persona" en la lección 06-02.

Y la advertencia más importante: "Tiempo de espera agotado" NO demuestra que el host esté caído. Muchos firewalls (incluido el de Windows por defecto ante redes "públicas") filtran ICMP: el host está vivo y sirviendo, pero no contesta pings. Lo vimos en el módulo 3 con el caso "puerto cerrado vs host caído". Regla práctica: un ping que responde confirma conectividad; un ping que no responde solo es un indicio que hay que contrastar (por ejemplo, con curl al servicio real, más abajo).

Herramienta nueva. Cuando el ping falla "a mitad de camino", quieres saber dónde se corta la ruta. tracert (Windows) y traceroute (Linux) te muestran cada router intermedio.

Su funcionamiento es una idea brillante construida sobre el TTL del módulo 2:

1. Envía un paquete con TTL=1. El primer router lo recibe, resta 1, llega a 0, lo descarta… y devuelve un ICMP "Time Exceeded" con su propia IP como remitente. Primer salto identificado.
2. Envía otro con TTL=2: muere en el segundo router, que se delata igual.
3. Repite con TTL=3, 4, 5… hasta que el paquete llega al destino, que responde normalmente.

Traza de Marta hacia Bilbao (por la VPN) y hacia Internet:

Cómo leerla:

• -d (Windows) / -n (Linux) desactiva la resolución DNS inversa de cada salto: la traza va mucho más rápida y en diagnóstico casi siempre lo quieres así.
• Hacia Bilbao solo hay 3 saltos: el túnel VPN encapsula el tráfico, así que todos los routers de Internet que hay físicamente entre Valencia y Bilbao son invisibles — el túnel se comporta como un cable virtual entre .10.1 y .20.1. Coincide con lo que dedujimos del TTL=126 del ping (2 routers).
• Hacia Internet aparecen la gateway, el ISP (10.140.2.1, una dirección privada de la red del operador — CG-NAT, módulo 5) y saltos públicos.
• Los asteriscos * en el salto 4 no significan avería: ese router simplemente no responde a las sondas (por política, o por prioridad baja del plano de control), pero reenvía el tráfico — la prueba es que el salto 5 responde. Preocúpate cuando los asteriscos aparecen en un salto y en todos los siguientes hasta el final: ahí sí se corta la ruta, y el último salto que respondió es tu mejor pista de dónde está el problema.
• Detalle técnico que a veces importa: Windows sondea con ICMP Echo; Linux, por defecto, con UDP a puertos altos (usa traceroute -I para forzar ICMP). Algunos firewalls tratan distinto cada tipo, así que la misma traza puede diferir entre sistemas.

¿Cuándo usar traceroute? Cuando la conectividad extremo a extremo falla o es lenta y necesitas localizar el tramo: si de Valencia a Bilbao la traza muere después de 192.168.10.1, el problema está en la VPN o más allá; si ni siquiera aparece el salto 1, el problema es local.

Ya conoces ARP del módulo 2: traduce IPs a MACs dentro de la red local. Como herramienta de diagnóstico, arp -a responde a una pregunta muy concreta: "¿mi equipo ha conseguido hablar en capa 2 con ese vecino?"

• Hay entrada con MAC para la gateway (.10.1) y la intranet (.10.10): la resolución ARP funcionó, luego la capa 1 y la capa 2 hasta esos equipos están confirmadas. Si un ping a .10.10 fallara pero su entrada ARP existiera y fuera reciente, el problema estaría por encima de la capa 2 (firewall, por ejemplo).
• En Linux, ip neigh muestra además el estado: REACHABLE (confirmado), STALE (antiguo, se revalidará) o FAILED/INCOMPLETE.
• Una entrada incompleta (Linux: INCOMPLETE; Windows: la entrada directamente no aparece tras intentar el ping) significa que se pidió "¿quién tiene 192.168.10.10?" y nadie contestó: el host está apagado, desconectado o en otra VLAN (recuerda: la VLAN 20 de invitados de Meridiano no ve ARP de la VLAN 10 corporativa).
• Matiz importante: ARP solo sirve para la propia subred. Para 192.168.20.7 nunca verás su MAC en Valencia; verás tráfico hacia la MAC de la gateway.

Truco de campo: arp -a inmediatamente después de un ping fallido a un vecino es la forma más rápida de separar "problema de capa 2" de "host que filtra ICMP".

nslookup apareció en el módulo 2 con los tipos A/AAAA/CNAME/MX. Como herramienta de diagnóstico, su valor está en dos capacidades: pedir tipos concretos de registro y preguntar a un servidor concreto, saltándote la configuración local.

Interpretación — y es un patrón que verás mil veces:

• Las dos primeras líneas de cada consulta te dicen a quién estás preguntando. La primera consulta usa el DNS configurado (el router de Meridiano, que resuelve la zona interna).
• Añadir una IP al final (... 8.8.8.8) fuerza la consulta a ese servidor. Que Google no conozca intranet.grupomeridiano.example aquí es normal: es un nombre interno que solo existe en el DNS de la empresa. Pero esta técnica es la clave para responder "¿el problema es mi DNS o el nombre en general?": si tu DNS falla y 8.8.8.8 resuelve, el problema es tu servidor DNS, no el dominio.
• Para un tipo concreto: nslookup -type=MX grupomeridiano.example.

En Linux, la herramienta preferida de los profesionales es dig, más detallada:

• El 3600 es el TTL del registro (¡otro TTL distinto al de IP!): segundos que la respuesta puede vivir en cachés. Explica el clásico "he cambiado el DNS pero unos usuarios van al servidor viejo y otros al nuevo": las cachés con el registro antiguo lo servirán hasta agotar su TTL.
• Sintaxis para servidor concreto en dig: dig @8.8.8.8 grupomeridiano.example MX.
• En Windows, ipconfig /displaydns muestra la caché DNS local y ipconfig /flushdns la vacía — el primer remedio cuando sospechas de una respuesta cacheada obsoleta.

Estas dos las trabajamos a fondo en la lección 04-04 (sockets, LISTEN/ESTABLISHED/TIME_WAIT, EADDRINUSE); aquí solo fijamos su papel en el botiquín: responden a "¿el servicio está escuchando y quién está conectado?". Las invocaciones que debes tener en memoria muscular:

Mnemotecnia de ss -tlnp: tcp, listening, numérico, procesos. Si un curl a un servidor falla, la comprobación en el servidor es siempre esta: sin un socket en LISTEN, no hay nada que conecte. El detalle fino (estados, colas, TIME_WAIT) está en 04-04.

Todo lo anterior comprueba capas 1–4. Pero "la intranet no va" puede ser un fallo de capa 7 con todas las capas inferiores perfectas. curl hace peticiones HTTP/HTTPS reales desde la terminal (viene de serie en Linux y en Windows 10+), y con -v (verbose) te enseña cada fase por separado — exactamente el flujo DNS→TCP→TLS→HTTP que diseccionamos en el módulo 4:

El poder diagnóstico está en dónde se detiene la salida:

Fíjate en que Connection refused (RST inmediato: hay host, no hay servicio) frente a timeout (nadie contesta) es la misma distinción "puerto cerrado vs host caído" del módulo 3 — curl te la sirve etiquetada.

• Concluir "host caído" porque no responde al ping. Los firewalls filtran ICMP constantemente. Contrasta siempre con el servicio real: curl al puerto de la aplicación.
• Olvidar el /all en ipconfig. Sin él no ves DHCP, DNS ni MAC, que es justo lo que suele importar.
• Asustarse por asteriscos sueltos en un traceroute. Un salto mudo con saltos posteriores que responden es cosmético. Solo importa el punto a partir del cual todo son asteriscos hasta el final.
• Ignorar el TTL de las respuestas de ping. Es información gratis: saltos hasta el destino y pista del sistema operativo remoto.
• Probar el DNS solo con el servidor configurado. La consulta a un segundo servidor (nslookup nombre 8.8.8.8) separa en segundos "mi DNS falla" de "el dominio falla".
• Buscar con arp -a la MAC de un equipo de otra subred. ARP no cruza routers; para Bilbao solo verás la MAC de tu gateway.
• Hacer un solo ping y decidir. Los problemas intermitentes exigen ping -t (o -c 100) mirando pérdida y jitter, no un ping suelto.

1. Desde el PC de Marta, ping 192.168.10.10 devuelve respuestas con TTL=64, y ping 192.168.20.1 devuelve respuestas con TTL=254. Razona, para cada caso: ¿cuántos routers hay en medio y qué pista tienes del tipo de sistema que responde?
2. Ana no puede abrir https://intranet.grupomeridiano.example. Ejecuta curl -v y la salida se detiene tras * Trying 192.168.10.10:443... con Connection refused inmediato. Su compañero afirma: "el servidor está caído, ni siquiera está encendido". ¿Tiene razón? ¿Qué indica exactamente ese mensaje y qué comando ejecutarías en el servidor para confirmarlo?
3. Un tracert -d 192.168.20.7 desde Valencia muestra: salto 1 192.168.10.1 OK; saltos 2 a 30, todo asteriscos. Otro día, la misma traza mostraba salto 2 192.168.20.1 y salto 3 el destino. ¿Qué tramo señalarías como averiado y por qué el salto 1 correcto es una pista valiosa?

1. Intranet, TTL=64: los TTL iniciales típicos son 64, 128 o 255. Recibir exactamente 64 significa 0 routers en medio (está en la misma subred, coherente: .10.21 y .10.10 comparten la /24) y sugiere un sistema Linux/Unix (inicial 64). Router de Bilbao, TTL=254: partió de 255 (habitual en equipos de red) y se restó 1 una vez → 1 router en medio (el de Valencia, .10.1; el propio destino no descuenta su salto). Nota cómo el mismo valor de TTL recibido se interpreta relativo al inicial más probable.
2. No tiene razón. Connection refused significa que el host respondió — con un RST: hay máquina viva en 192.168.10.10, pero ningún proceso escucha en el puerto 443 (servicio parado o escuchando en otro puerto). Si el servidor estuviera apagado, el síntoma sería un timeout (nadie contesta), no un rechazo inmediato. Confirmación en el servidor: ss -tlnp | grep 443 — si no hay línea LISTEN, hay que arrancar/revisar el nginx de la intranet. Es la distinción "puerto cerrado vs host caído" del módulo 3.
3. El corte está después de la gateway de Valencia y antes del router de Bilbao: es decir, en el túnel VPN (o en la conexión a Internet que lo transporta). El salto 1 correcto es valioso porque descarta todo el tramo local: el PC de Marta, el cableado, el switch y la gateway funcionan; no tiene sentido revisar nada en la LAN de Valencia. A diferencia de un asterisco suelto, aquí los asteriscos van del salto 2 hasta el final: la ruta se corta de verdad. Siguiente paso: revisar el estado del túnel VPN en el router .10.1.

Ya tienes el botiquín ordenado: ipconfig/ip addr + ip route para tu propia configuración (capa 1 primero), ping leído con ojo experto (TTL, pérdida, jitter, y su gran limitación: ICMP filtrado), traceroute para localizar el tramo que falla reutilizando el truco del TTL, arp -a como confirmación de capa 2, nslookup/dig para interrogar al DNS con precisión de cirujano, ss/netstat para los sockets y curl -v como sonda de la capa de aplicación que separa DNS, TCP, TLS y HTTP en fases visibles. Con la tabla síntoma → herramienta tienes el reflejo inicial para casi cualquier aviso. Pero todas estas utilidades comparten un límite: te dicen que algo falla y dónde, pero no siempre por qué — trabajan sobre resúmenes e inferencias. Cuando necesitas la verdad completa, hay que bajar al nivel donde no se puede mentir: ver los paquetes uno a uno. Eso — Wireshark, tcpdump y el análisis de tráfico, con su marco legal y ético — es la siguiente lección.