Traceroute en Linux: vea dónde se bloquea una conexión antes de culpar al servidor.

Cuando un sitio web o servidor deja de responder, lo primero que solemos pensar es que la máquina remota es la culpable. Pero no siempre es así. La interrupción podría originarse en tu red local, tu router, el filtrado entre dos proveedores, un cortafuegos o, simplemente, una ruta de red incorrecta.

trazarruta Su propósito es precisamente examinar la ruta que siguen tus paquetes. No proporciona una verdad absoluta, pero ayuda a saber por dónde empezar a solucionar problemas antes de reiniciar un servicio que no lo solicitó.

Instale traceroute si falta el comando.

En ciertas distribuciones, trazarruta No viene instalado por defecto. Primero, compruebe si está presente.

comando -v traceroute
traceroute --versión

Si falta el comando, instale el paquete adecuado para su distribución.

sudo apt update
sudo apt install traceroute

sudo dnf install traceroute
sudo pacman -S traceroute

En un servidor de producción, prefiero instalar la herramienta correctamente en lugar de ejecutar un comando obtenido aleatoriamente de un contenedor o un binario de terceros. Deberías poder repetir la prueba más adelante, en las mismas condiciones.

Inicie un primer traceroute limpio.

Para probar la ruta a un dominio, simplemente utilice:

traceroute linuxencaja.net

La salida muestra una lista de saltos. Cada línea suele corresponder a un enrutador atravesado. Generalmente se muestra el número de salto, el nombre o la dirección IP del enrutador y, a continuación, varios tiempos de respuesta.

Para evitar una resolución DNS lenta durante el diagnóstico, agregue -norteEsta suele ser la primera prueba que realizo cuando quiero ir rápido.

traceroute -n linuxencaja.net

Si el nombre de dominio en sí parece sospechoso, comience por separar el problema de DNS del problema de red. La guía sobre el Caché DNS en Linux Este paso se considera completado correctamente, especialmente si la máquina detecta una dirección IP antigua y no otra.

Lee las estrellas sin sacar conclusiones precipitadas.

las estrellas * * * Estos errores no implican automáticamente que la red esté dañada. Indican principalmente que el nodo no responde como se espera a los paquetes utilizados por traceroute. Muchos enrutadores filtran o limitan estas respuestas.

Lo importante es el resto de la ruta. Si un salto muestra estrellas, pero los saltos subsiguientes responden y el destino final también responde, es probable que este enrutador intermedio no sea culpa tuya.

Por otro lado, si el traceroute siempre se detiene en el mismo lugar y no hay respuesta después, hay un área que inspeccionar: puerta de enlace local, ruta del operador, VPN, firewall, filtrado de host o falla en el lado de destino.

traceroute -n 8.8.8.8
traceroute -n 1.1.1.1
traceroute -n your-server.example

Comparar varios destinos evita pistas falsas. Si todo está bloqueado en el primer o segundo salto, revise su red local. Si solo un servidor específico está bloqueando el acceso, es más probable que el problema esté relacionado con esa ruta, ese proveedor o un filtro específico.

Elija ICMP o TCP según el contexto.

Por defecto, traceroute puede usar paquetes que no necesariamente se parecen al tráfico de la aplicación que estás intentando diagnosticar. Si estás probando un sitio web, una prueba TCP al puerto 443 podría ser más útil.

sudo traceroute -T -p 443 linuxencaja.net

Para una prueba ICMP, cercana al espíritu de silbido, usar -I.

sudo traceroute -I 8.8.8.8

Las páginas del manual de trazarruta Y silbido En ellos se detallan estos modos. En la práctica, recuerdo principalmente esto: si el navegador falla con HTTPS, prueba también con TCP 443. Un traceroute por UDP o ICMP podría revelar información diferente.

Comprueba la ruta local antes de culpar a internet.

Si los saltos iniciales son inconsistentes, verifique la ruta que está utilizando su máquina. Esto es fundamental en un servidor con múltiples interfaces, una VPN, una ruta estática o una dirección IP secundaria.

ruta IP
ip route get 8.8.8.8
ip route get 1.1.1.1

obtener ruta ip Muestra la interfaz, la puerta de enlace y, a veces, la dirección de origen utilizada para llegar a un destino. Si el resultado no coincide con lo esperado, traceroute simplemente confirma una ruta local incorrecta.

Antes de modificar una ruta de forma remota, mantenga una sesión SSH abierta y asegúrese de tener acceso a la consola. Una ruta predeterminada incorrecta puede desconectarlo del servidor más rápido que un servicio reiniciado de forma deficiente.

Distinguir entre latencia, pérdida y filtrado

Un único salto con alta latencia no basta para demostrar que el enrutador es el responsable. Algunos enrutadores responden lentamente a los paquetes de diagnóstico, pero continúan reenviando el tráfico con normalidad.

Lo que más me interesa es una degradación que persista en todos los saltos posteriores, o una pérdida visible de calidad hasta el destino final. Ahí es cuando se puede empezar a hablar de un problema real con la ruta o el destino.

ping -c 5 linuxencaja.net
ping -c 5 8.8.8.8
traceroute -n -q 3 linuxencaja.net

Si necesitas comprobar los puertos abiertos en el lado del servidor, no mezcles todo en traceroute. Usa en su lugar Utilice ss o netstat para comprobar los puertos abiertos en Linux.Traceroute muestra la ruta. ss muestra qué es lo que realmente está escuchando en la máquina.

Cuándo usar tracepath en su lugar

ruta de seguimiento Esto puede ser útil cuando se desea una prueba rápida sin opciones avanzadas. A menudo está disponible a través del paquete. iutils y también puede informar información relacionada con la MTU de la ruta.

tracepath linuxencaja.net
tracepath 1.1.1.1

La página del manual de ruta de seguimiento Sigue siendo una buena referencia si quieres entender sus limitaciones. Para un diagnóstico preciso en un puerto o modo en particular, sigo recurriendo a trazarruta.

El método que utilizo antes de cambiar una configuración

Cuando falla una conexión, realizo las comprobaciones en este orden:

• Pruebe el DNS con una dirección IP y un nombre de dominio;
• tirar traceroute -n a varios destinos;
• pruebe el modo apropiado, por ejemplo -T -p 443 para HTTPS;
• control obtener ruta ip de la máquina en cuestión;
• compruebe el puerto del lado del servidor con ss si la carretera llega con éxito a su destino;
• Observe el salto donde la ruta se detiene antes de abrir un ticket de operador o de alojamiento.

Con este método, se evita el error clásico: reiniciar un servidor o manipular el cortafuegos cuando el problema reside en la red local. Y si el problema se repite, al menos tendrá un registro claro del salto, el puerto probado y la ruta local utilizada.

sudo apt update && sudo apt upgrade