Primero la pregunta, después el comando
Un comando de red es útil cuando responde una pregunta concreta. Antes de ejecutarlo decide qué quieres comprobar: ¿tengo dirección?, ¿qué gateway usaré?, ¿puedo resolver el vecino?, ¿qué ruta se selecciona?, ¿el DNS responde?, ¿hay un socket escuchando?
Este enfoque evita interpretar salidas sin contexto. Dos comandos distintos pueden mostrar información relacionada pero no equivalente: una tabla ARP/ND no sustituye a una tabla de rutas, y una resolución DNS correcta no demuestra que el servicio destino acepte conexiones.
Windows: configuración e interfaces
ipconfig /all muestra direcciones, prefijos/máscaras, gateways, servidores DNS y datos del adaptador. Get-NetIPConfiguration y Get-NetAdapter ofrecen una vista moderna desde PowerShell.
Si sospechas un problema de DHCP, comprueba si la dirección procede del rango esperado y si existen gateway y DNS. Una dirección IPv4 autoconfigurada 169.254.0.0/16 suele indicar que el host no obtuvo una concesión DHCP válida para esa interfaz, aunque el diagnóstico debe confirmar la causa.
Windows: rutas y vecinos
route print muestra la tabla de rutas; PowerShell dispone de Get-NetRoute. arp -a permite ver entradas ARP IPv4, mientras Get-NetNeighbor cubre vecinos IPv4/IPv6.
Cuando un destino falla, busca primero si se considera local o remoto. Si es remoto, identifica qué ruta y gateway se usarán. Si es local, comprobar el estado del vecino puede revelar que la resolución de Capa 2 no está completándose.
Windows: ping, tracert y Test-NetConnection
ping comprueba alcance ICMP y latencia aproximada. tracert intenta mostrar saltos intermedios. Test-NetConnection host -Port 443 es especialmente útil para probar un puerto TCP concreto desde PowerShell.
No uses ping como veredicto universal: algunos dispositivos filtran ICMP. Si investigas HTTPS, probar TCP/443 aporta evidencia más cercana al servicio real.
Windows: DNS
nslookup permite consultas básicas. PowerShell añade Resolve-DnsName, que expone con claridad registros, servidores y tipos de respuesta.
Compara una consulta por nombre con una prueba directa a la IP. Si la IP funciona y el nombre no, centra la investigación en DNS, caché, suffixes, resolver configurado o delegación.
Linux: interfaces y direcciones
En Linux moderno, ip link muestra estado de interfaces y ip addr direcciones IPv4/IPv6. ip -s link añade contadores que pueden revelar errores y descartes.
El paquete iproute2 sustituye en gran parte a utilidades históricas como ifconfig y route. Éstas pueden seguir instaladas, pero conviene aprender la salida de ip porque representa mejor los objetos actuales del kernel.
Linux: rutas y vecinos
ip route muestra rutas IPv4 y ip -6 route las IPv6. ip route get 203.0.113.10 puede mostrar qué decisión tomaría el kernel para un destino concreto.
ip neigh muestra la caché de vecinos, tanto ARP para IPv4 como Neighbor Discovery para IPv6. Estados incompletos o fallidos son una pista de que el problema está antes del routing remoto.
Linux: ping, tracepath y traceroute
ping y ping -6 prueban ICMP. tracepath puede mostrar camino y cambios de MTU sin requerir siempre privilegios especiales; traceroute ofrece más opciones según implementación.
Las respuestas de saltos intermedios dependen de políticas y rate limits. Interpreta el conjunto de la prueba, no un asterisco aislado.
Linux: sockets y puertos
ss -lntup permite inspeccionar sockets en escucha y conexiones según permisos. Es útil cuando el problema está en el propio servidor: una red puede estar perfectamente operativa mientras la aplicación no escucha en la dirección o puerto esperados.
Para conectividad TCP desde un cliente puedes usar herramientas como nc cuando estén instaladas, pero registra siempre qué host y puerto probaste y diferencia «conexión rechazada» de «timeout».
Linux: DNS y resolver
dig permite consultar registros y servidores concretos. resolvectl, en sistemas con systemd-resolved, muestra el estado del resolver por interfaz y puede ejecutar consultas.
Una consulta explícita a un servidor ayuda a separar «ese DNS funciona» de «mi sistema está usando ese DNS». La ruta, VPN o configuración por interfaz puede cambiar qué resolver se consulta realmente.
macOS: equivalentes útiles
macOS incluye ifconfig, netstat -rn, route -n get default, arp -a, ping y traceroute. Para DNS, scutil --dns muestra la configuración efectiva y dig permite consultas.
En equipos con varias interfaces, VPN o servicios de privacidad es especialmente importante revisar la configuración efectiva en lugar de asumir que el DNS o gateway visibles en una sola interfaz son los que usa cada flujo.
Captura desde CLI: tcpdump y TShark
tcpdump permite capturas rápidas en sistemas Unix-like. tshark es la interfaz de línea de comandos de Wireshark y comparte su motor de disección y filtros de visualización.
Los filtros de captura y de visualización no son el mismo lenguaje. En TShark, -f aplica un filtro de captura basado en pcap y -Y un display filter de Wireshark. Si necesitas análisis detallado, guarda una captura y ábrela después en Wireshark.
Tabla mental por pregunta
Dirección/configuración → ipconfig /all o ip addr. Ruta → route print, Get-NetRoute o ip route. Vecino → arp -a, Get-NetNeighbor o ip neigh. DNS → Resolve-DnsName, nslookup o dig. Puerto TCP → Test-NetConnection o una herramienta de conexión equivalente. Captura → tcpdump/tshark.
Esta tabla no sustituye al método de troubleshooting; sólo reduce el tiempo entre hipótesis y evidencia.
Precauciones y permisos
Algunas herramientas necesitan privilegios elevados y una captura puede contener credenciales, cookies, direcciones internas o datos personales. Recoge sólo lo necesario, controla el acceso a los ficheros y elimina datos sensibles antes de compartirlos.
No ejecutes cambios destructivos ni limpiezas de caché como primer paso. Observar antes de modificar conserva evidencia y evita ocultar la causa.
Siguiente paso
Cuando los comandos no expliquen el fallo, pasa a Wireshark para observar paquetes. Si la evidencia muestra descartes por política, revisa ACL, firewall y NAT/PAT.
Cómo interpretar resultados sin sacar conclusiones demasiado pronto
Una salida sólo tiene valor dentro de una hipótesis. Si ping responde, has demostrado que existe algún camino ICMP entre dos extremos en ese momento, no que DNS, TCP o la aplicación funcionen. Si traceroute muestra huecos, puede haber rate limiting de ICMP sin pérdida del tráfico final. Si un puerto TCP devuelve «connection refused», la red alcanzó el host pero no existe un servicio aceptando esa conexión o alguna política responde activamente.
Compara además valores actuales con una referencia sana: gateway esperado, prefijo, DNS, métrica de ruta, MTU y estado de interfaz. La diferencia entre dos hosts similares suele ser más informativa que una lista absoluta de parámetros.
Caso práctico: «tengo IP pero no navego»
Un flujo ordenado sería: revisar configuración con ipconfig /all o ip addr; verificar la ruta por defecto; comprobar que el gateway resuelve como vecino; probar una IP conocida; consultar DNS; y finalmente probar el puerto de la aplicación. Cada paso reduce el conjunto de causas posibles.
Si la IP remota responde pero el nombre no, no sigas cambiando rutas: investiga el resolver. Si ni siquiera se alcanza el gateway, DNS todavía no es el problema principal. Este orden es la diferencia entre usar comandos como herramientas de evidencia y ejecutarlos como una receta memorizada.