Depurar en lugar de adivinar

Depurar una red no consiste en saber mas comandos. Consiste en sustituir las corazonadas por una secuencia de preguntas cuyas respuestas no admitan discusion. El metodo tiene tres reglas. Empieza por la comprobacion que cuesta menos tiempo y descarta mas. Cambia exactamente una cosa cada vez. Y despues de cada prueba, pregunta que demuestra el resultado y que no: una prueba que podria haber pasado por dos motivos distintos no te ha dicho nada.

Lo mas barato primero significa: antes de tocar una configuracion, pregunta si la cosa funciona del todo desde aqui y si funciona desde otro sitio. Comparar dos puntos de observacion cuesta un comando y parte el espacio del problema por la mitad. Pedir al usuario que pruebe otra red, o ejecutar la misma peticion desde otra maquina, suele valer mas que una hora leyendo registros.

La escalera de preguntas, desde abajo: tiene la maquina alguna direccion, y una ruta por defecto? Se resuelve el nombre a una direccion? Responde la direccion en el nivel de IP? Esta abierto el puerto, y responde el servicio en el? Devuelve la aplicacion una respuesta correcta? Cada pregunta la responde una herramienta distinta, y cada respuesta reduce el sospechoso hasta que solo queda una capa. El sentido de la escalera es que al final termina: una buena sesion de diagnostico encoge el conjunto de causas posibles en lugar de agrandarlo.

Cada herramienta demuestra algo estrecho, y usarla para mas que eso es la forma de llegar a conclusiones erroneas. ping demuestra que un host responde a ICMP y que existe un camino en ambos sentidos; no demuestra que haya un servidor web en marcha. dig demuestra que respondio un resolutor y cuanto tiempo esta cacheada la respuesta; no demuestra que la direccion sea alcanzable. curl demuestra que hace toda la pila para una peticion concreta; no demuestra que otros clientes reciban la misma respuesta. ss demuestra que hay escuchando en esta maquina y en que direccion; no demuestra que un cortafuegos deje entrar a alguien.

$ dig api.example.org +short
198.51.100.20

$ dig api.example.org +short
198.51.100.20

$ dig api.example.org @1.1.1.1 +short
203.0.113.7

$ dig api.example.org @8.8.8.8 +short
203.0.113.7Dos resolutores, dos respuestas distintas: una cache y un registro obsoleto, no una red rota.

$ curl -v https://api.example.org/health
*   Trying 198.51.100.20:443...
* connect to 198.51.100.20 port 443 failed: Connection timed out
* Failed to connect to api.example.org port 443: Connection timed out

$ curl -sv https://api.example.org/health -o /dev/null
*   Trying 93.184.216.34:443...
* Connected to api.example.org (93.184.216.34) port 443
* Server certificate: CN=*.example.org
< HTTP/2 200
< content-type: application/jsonEl mismo comando con un tiempo de espera sobre el puerto y con la direccion que si funciona.

ss merece atencion especial porque separa dos fallos que desde fuera parecen identicos: no hay nadie escuchando en el puerto, o hay alguien escuchando pero solo en la direccion de loopback. Un servidor atado a 127.0.0.1 acepta conexiones de la misma maquina y rechaza todas las de fuera, diga lo que diga el cortafuegos. Esa unica distincion explica buena parte de los casos en los que el servicio funciona en local y es inalcanzable desde cualquier otro sitio.

$ ss -tlnp
State   Local Address:Port   Process
LISTEN  127.0.0.1:8080       users:(("node",pid=4127,fd=21))
LISTEN  0.0.0.0:22           users:(("sshd",pid=880,fd=3))

$ curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:8080/
200Un servicio es alcanzable desde la red y el otro solo desde esta maquina.