Si alguna vez ha trabajado en el espacio de redes, o en el soporte técnico, probablemente tenga buenas historias sobre la solución de problemas de una conexión perdida. Inevitablemente, se instala y configura algún sistema nuevo, pero no podemos hacer que el tráfico pase hacia o desde el sistema.
Una de esas historias que recuerdo es algo así.
El caso de uso
Estaba solucionando un problema de una matriz de almacenamiento back-end que acababa de instalar una gran corporación financiera estadounidense muy conocida. El cliente intentaba configurar la replicación de datos desde su sitio de producción (PROD) en Houston a un sitio de recuperación ante desastres (DR) en San Antonio. El sistema de recuperación ante desastres se había implementado durante mucho tiempo y tenía la reputación de ser una buena configuración conocida.
El sitio de producción era completamente nuevo y, por supuesto, la causa de todos nuestros problemas. El verdadero problema era que no podíamos hacer que el tráfico se moviera entre las dos interfaces de replicación que habíamos configurado. Pudimos llegar fuera de la puerta de enlace en el sitio DR, pero no pudimos llegar fuera del sitio PROD. El tráfico llegaba al dispositivo de puerta de enlace y se interrumpía.
Media hora después de solucionar el problema, le pregunté al cliente si tenía un firewall en el sitio de PROD que pudiera estar bloqueando el tráfico en los puertos necesarios. "Por supuesto que no, no hay firewall entre estos sitios". Esta respuesta fue impactante considerando que esta era una de las instituciones financieras más grandes de todo el país. Pero, como sucede con todos los puestos de atención al cliente, debe ser respetuoso y cortés.
Entonces, revisé todos los cheques que se me ocurrieron por mi parte. Cortafuegos de almacenamiento interno desactivado:comprobar. Puertos abiertos de DR a PROD:consultar. ¿Puertos abiertos de PROD a DR? No.
Resulta que después de cuatro horas de resolución de problemas y reconfiguración de interfaces, el cliente dijo:"Déjame llamar a nuestro chico del cortafuegos".
¿Qué chico?
Esa es una posición extraña para haber contratado por considerar que no tiene un firewall entre estos sitios. Pero no fue raro porque, por supuesto, tenían un cortafuegos. Asunto resuelto. Ahora que la pesadilla había terminado, las herramientas que usé para descubrir dónde ocurrió el problema fueron Telnet a la antigua (que podemos cubrir en un artículo posterior) y, por supuesto, traceroute .
El comando
Ahora que puede ver un caso de uso claro para traceroute , hablemos sobre el comando en sí y qué información puede obtener de él. El propósito de este artículo, después de todo, es que obtenga un poco más de conocimiento sobre la utilidad que traceroute ofertas.
La sintaxis es bastante simple. El comando traceroute <x> (x siendo aquí una IP o nombre de host) es la versión más básica y comenzará a enviar paquetes al destino designado. Este resultado le permitirá rastrear la ruta de los paquetes enviados desde su máquina a cada uno de los sistemas entre usted y su destino deseado.
Por ejemplo, si quisiera rastrear la ruta desde mi computadora hasta google.com , ingresaría algo como esto:
[root@rhel8dev ~]# traceroute www.google.com
traceroute to www.google.com (216.58.194.100), 30 hops max, 60 byte packets
1 _gateway (192.168.2.1) 2.396 ms 2.726 ms 3.057 ms
2 145.sub-66-174-43.myvzw.com (66.174.43.145) 119.355 ms 119.315 ms 119.508 ms
3 * * *
4 10.209.189.140 (10.209.189.140) 120.321 ms 119.836 ms 120.009 ms
5 66.sub-69-83-106.myvzw.com (69.83.106.66) 119.042 ms 119.489 ms 119.156 ms
6 2.sub-69-83-107.myvzw.com (69.83.107.2) 120.039 ms 125.954 ms 101.450 ms
7 112.sub-69-83-96.myvzw.com (69.83.96.112) 110.757 ms 108.485 ms 122.108 ms
8 112.sub-69-83-96.myvzw.com (69.83.96.112) 115.028 ms 121.073 ms 125.537 ms
9 116.sub-69-83-96.myvzw.com (69.83.96.116) 121.793 ms 124.769 ms 124.434 ms
10 Bundle-Ether10.GW6.DFW13.ALTER.NET (140.222.237.123) 128.082 ms 128.400 ms 126.509 ms
11 google-gw.customer.alter.net (204.148.43.118) 106.276 ms 107.885 ms 105.718 ms
12 108.170.252.129 (108.170.252.129) 99.725 ms 101.797 ms 108.170.252.161 (108.170.252.161) 101.671 ms
13 108.170.230.109 (108.170.230.109) 101.207 ms 100.515 ms 99.730 ms
14 dfw06s48-in-f100.1e100.net (216.58.194.100) 99.059 ms 94.502 ms 94.015 ms
[root@rhel8dev ~]# El desglose
Analicemos estos resultados en partes más pequeñas. Este comando puede producir una gran cantidad de información y, como dice el refrán, "La mejor forma de comer un elefante es un bocado a la vez:"
[root@rhel8dev ~]# traceroute www.google.com
traceroute to www.google.com (216.58.194.100), 30 hops max, 60 byte packets
1 _gateway (192.168.2.1) 2.396 ms 2.726 ms 3.057 ms Solo estamos viendo el primer salto aquí. Sin embargo, podemos usar este salto para diseccionar la información que se muestra. En primer lugar, vemos lo que realmente se envía y dónde:
traceroute to www.google.com(IP), 30 hops max, 60 byte packets
A partir de este resultado, deducimos que estamos enviando tráfico al objetivo deseado (www.google.com ). Traceroute, por defecto, mide 30 saltos de paquetes de 60 bytes.
A continuación, vemos que se produce el primer salto. Aquí estamos accediendo a la puerta de enlace externa:
1 _gateway (192.168.2.1) 2.396 ms 2.726 ms 3.057 ms
Puede decir aquí dónde aterrizó realmente el salto uno, y luego hay tres valores numéricos. Estos se conocen como Tiempo de ida y vuelta (RTT), que se refiere a la cantidad de tiempo que tarda un paquete determinado en llegar a su destino y enrutar de regreso un mensaje ICMP a la fuente. Por defecto, traceroute enruta tres paquetes de datos para probar cada salto. Puede encontrar más información sobre este proceso en línea, sin embargo, el resumen es que cada paquete enruta un mensaje de error ICMP a la fuente cuando llega a un dispositivo en la red. Esta acción permite traceroute para determinar el RTT de ese paquete y no necesariamente indica un error.
Ahora, veamos los saltos 2 a 4:
2 145.sub-66-174-43.myvzw.com (66.174.43.145) 109.206 ms 109.400 ms 109.423 ms
3 * * *
4 10.209.189.140 (10.209.189.140) 124.793 ms 123.585 ms 124.585 ms Podemos ver algo nuevo aquí. Hop 2 parece normal:un dispositivo recibe tiempos de RTT en el rango de 100 milisegundos. Entonces, se pone interesante. Solo vemos estrellas (*).
¿Qué significan estas estrellas (asteriscos)? ¿Se descartaron los paquetes? ¿Están agotados?
Dejame explicar. Hay dos posibilidades cuando se trata de estas estrellas. En primer lugar, es posible que ICMP/UDP no esté configurado. Si el traceroute el comando se completa con éxito y ve estas estrellas, lo más probable es que el dispositivo afectado no estaba configurado para responder al tráfico ICMP/UDP. Este resultado no significa que no se pasó el tráfico. La segunda posibilidad es que los paquetes se cayeron debido a un problema en la red. Estos resultados suelen ser tiempos de espera de paquetes o el tráfico ha sido bloqueado por un firewall.
Como puede ver en el ejemplo anterior, incluso después de ver estrellas en el salto 2, los paquetes continúan y se enrutan de regreso en el salto 4. Este comportamiento conduce a un traceroute exitoso. como podemos ver que se ha llegado a Google.
La comida para llevar
Traceroute puede ser una herramienta invaluable cuando se trata de solucionar problemas de red. Realmente ayuda a visualizar dónde está ocurriendo realmente el problema. Por supuesto, hay otras operaciones detrás de escena de traceroute que no fueron cubiertos aquí.
Le sugiero encarecidamente que si desea profundizar aún más en esta herramienta, investigue un poco en línea. Hay mucha información sobre Time-to-Live (TTL) y RTT que, en aras del tiempo, no se incluyó en este artículo. Mi objetivo es que ahora tenga una mejor comprensión de cuándo y por qué debe usar traceroute herramienta, y cómo interpretar los datos que ofrece. Para obtener más información sobre conceptos y solución de problemas de redes, consulte nuestros artículos relacionados aquí.