2.4Resolución de problemas de red (ping, ipconfig, traceroute)
Lo esencial en 30 segundos
- ipconfig muestra la configuración local (dirección, máscara, puerta de enlace, DNS): si es anómala (169.254), se corrige aquí antes de ir más lejos.
- ping prueba si un destino responde, de la puerta de enlace a una dirección externa y luego a un nombre: cada prueba confirma un eslabón.
- tracert sigue el camino salto a salto y revela dónde se corta el trayecto; un ping fallido no es más que un indicio, pues el ICMP puede estar filtrado.
Mini-caso hilado — Sofiane lleva a cabo la secuencia de diagnóstico
Sofiane, técnico de soporte de nivel 1 en una pyme de distribución en Argel, recibe un «ya no hay Internet» en contabilidad. Aplica el método de lo más cercano a lo más lejano: ipconfig muestra una config sana (192.168.1.23, puerta de enlace 192.168.1.1); ping 192.168.1.1 responde (la red local es accesible); pero ping 8.8.8.8 cae en «tiempo de espera agotado». Deduce que la avería está aguas arriba de la puerta de enlace (box, línea o ISP). Lanza tracert para situar el salto que bloquea, y luego eleva la información al nivel 2 adjuntando sus registros. Anota el reflejo: anotar siempre los resultados en cada etapa.
Caso autónomo de esta sección: reaparece en el curso, el esquema, el script y el reto de 48 h de la sección 2.4.
1. ipconfig — mi configuración local
ipconfig muestra la dirección IP, la máscara, la puerta de enlace y los servidores DNS de la máquina. Si esta configuración falta o es anómala (169.254), el problema está aquí: inútil ir más lejos antes de corregirlo. Es el primer eslabón que Sofiane controla.
2. ping — ¿responde?
ping prueba si un destino responde. Se hace ping primero a la puerta de enlace (¿es accesible la red local?), luego a una dirección externa (¿es accesible Internet?), y luego a un nombre (¿funciona el DNS?). Cada prueba confirma un eslabón de la cadena.
3. tracert — el camino, salto a salto
tracert (traceroute) muestra la ruta seguida para alcanzar un destino, etapa por etapa. Revela dónde se interrumpe el trayecto: en su casa, en el proveedor o más allá. Procediendo en orden (ipconfig → puerta de enlace → IP externa → nombre → tracert), se sabe siempre hasta dónde funciona la conectividad — y por tanto dónde se sitúa la avería.
🔎 Ejemplo concreto — 🔎 Ejemplo concreto — Una secuencia de diagnóstico
Ante un «ya no hay Internet», Sofiane despliega la secuencia:
> ipconfig - 192.168.1.23 (config OK)
> ping 192.168.1.1 - respuesta (puerta de enlace OK)
> ping 8.8.8.8 - tiempo de espera agotado <- aqui se atasca
Lectura : config + red local sanas, Internet inaccesible
Diagnostico: averia aguas arriba de la puerta de enlace (box/linea/ISP)Lectura: la configuración y la red local están sanas, pero Internet es inaccesible.
Lección: el problema está aguas arriba de la puerta de enlace; tracert precisará en qué salto se bloquea.
Vocabulario de la sección
- ipconfig
- Muestra la configuración IP local: dirección, máscara, puerta de enlace y servidores DNS.
Ejemplo sencillo: Sofiane lee 192.168.1.23 como primer reflejo de resolución de problemas.
Lo que no es: un comando que prueba si un destino responde.
Reflejo: ver mi config → ipconfig.
- ping
- Prueba si un destino responde en la red.
Ejemplo sencillo: Sofiane hace ping a la puerta de enlace y luego a una dirección externa.
Lo que no es: el comando que sigue el camino salto a salto.
Reflejo: ¿responde? → ping.
- tracert / traceroute
- Muestra el camino salto a salto hacia un destino y el punto donde se detiene.
Ejemplo sencillo: Sofiane lanza tracert para situar el salto que bloquea.
Lo que no es: el comando que muestra la configuración local.
Reflejo: dónde se corta → tracert.
- Ping de la puerta de enlace
- Prueba que confirma que la red local es accesible antes de apuntar más lejos.
Ejemplo sencillo: La puerta de enlace 192.168.1.1 responde: la LAN está sana.
Lo que no es: una prueba sobre un servidor remoto fuera de la red local.
Reflejo: ¿red local OK? → ping puerta de enlace.
- Método cercano→lejano
- Diagnosticar desde el equipo local hacia la red remota, etapa por etapa.
Ejemplo sencillo: Sofiane sigue el orden ipconfig, puerta de enlace, IP externa, nombre, tracert.
Lo que no es: probar servidores al azar sin orden.
Reflejo: de lo cercano a lo lejano, siempre.
En la práctica — En la práctica — Localizar la avería de lo local a lo remoto
- ipconfig: confirme una configuración sana (dirección, máscara, puerta de enlace, DNS), como Sofiane.
- ping a la puerta de enlace (red local), luego a una IP externa (Internet), luego a un nombre (DNS).
- Deduzca dónde se sitúa la avería: config, LAN, Internet o DNS.
- Si un servicio remoto sigue inaccesible, lance tracert para ver dónde se corta el camino.
Script paso a paso — la secuencia de diagnóstico de Sofiane (5 min)
1) ipconfig: verifique dirección, máscara, puerta de enlace y DNS. 2) ping a la puerta de enlace (p. ej. 192.168.1.1): ¿es accesible la red local? 3) ping a una IP externa (p. ej. 8.8.8.8): ¿es accesible Internet? 4) ping a un nombre (p. ej. example.com): ¿funciona el DNS? 5) Si un servicio remoto sigue inaccesible, tracert para situar el salto que bloquea. Anote cada resultado.
Un ping fallido sigue siendo un indicio, no un veredicto: el ICMP puede estar filtrado, sobre todo en los servidores grandes.
Modelo copiar-pegar — mi secuencia de resolución de problemas
1) ipconfig 192.168.1.23 -> config sana ?
2) ping 192.168.1.1 -> puerta de enlace (LAN) responde ?
3) ping 8.8.8.8 -> IP externa (Internet) responde ?
4) ping example.com -> nombre (DNS) se resuelve ?
5) tracert -> donde se corta el camino ?
Concluir: config | LAN | Internet | DNS | caminoConfig local anómala
ipconfig muestra 169.254: Sofiane corrige el direccionamiento antes incluso de probar más lejos.
Puerta de enlace muda
ping a la puerta de enlace sin respuesta: el problema está en la red local (cable/switch).
Nombre KO, IP OK
La IP externa responde pero el nombre no: Sofiane pasa a la pista DNS.
Camino cortado
tracert se detiene en un salto preciso: Sofiane sitúa el corte en el ISP o más allá.
✓ Buenas prácticas
- Diagnosticar siempre de lo cercano a lo lejano.
- Un ping fallido ≠ máquina muerta (el ICMP puede estar filtrado).
- Lanzar tracert solo si un servicio remoto sigue inaccesible.
✗ Errores frecuentes
- Concluir «servidor averiado» ante un ping filtrado.
- Saltarse
ipconfigy probar al azar. - Olvidar probar el nombre después de la dirección (DNS).
Puntos clave
- Orden: ipconfig → ping puerta de enlace → ping Internet → ping a un nombre → tracert.
- Config local ausente (169.254) → corregir aquí primero.
- Ping por nombre KO pero por IP OK → DNS.
- tracert revela dónde se corta el camino.
Reto 48 h — aplícalo mañana
Como Sofiane, despliegue la secuencia completa en su equipo: ipconfig, luego ping a la puerta de enlace, luego ping a una IP externa, luego ping a un nombre. Anote los cuatro resultados y concluya en una frase: ¿en qué eslabón se detiene la conectividad en su caso? Termine con un tracert hacia un destino externo.
- Conozco el orden de los comandos: ipconfig, ping, tracert.
- Sé interpretar un ping por nombre y por IP.
- Localizo una avería desde el equipo local hasta la red remota.
Preguntas frecuentes
¿En qué orden lanzar los comandos?
ipconfig, luego ping a la puerta de enlace, luego ping a la IP externa, luego ping a un nombre, luego tracert si hace falta — de lo más cercano a lo más lejano.
Un ping falla — ¿está forzosamente averiada la máquina?
No: muchos servidores y cortafuegos ignoran el ping (ICMP). Un ping KO es un indicio, no un veredicto; cruce con otras pruebas.
¿En qué orden diagnosticar una avería de red de lo más cercano a lo más lejano?