Com s'utilitza l'ordre traceroute a Linux

Podeu utilitzar Linux traceroute ordre per detectar el tram lent del viatge d'un paquet de xarxa i solucionar problemes de connexions de xarxa lentes. Us mostrarem com fer-ho!

Com funciona la traceroute

Quan aprecies com traceroute funciona, facilita la comprensió dels resultats. Com més complicada sigui la ruta que ha de fer un paquet de xarxa per arribar a la seva destinació, més difícil és identificar on es poden produir desacceleracions.

La xarxa d'àrea local (LAN) d'una organització petita pot ser relativament senzilla. Probablement tindrà almenys un servidor i un enrutador o dos. La complexitat augmenta en una xarxa d’àrea àmplia (WAN) que comunica entre diferents ubicacions o a través d’Internet. Aleshores, el paquet de xarxa troba (i és reenviat i encaminat per) un munt de maquinari, com ara encaminadors i passarel·les.

Les capçaleres de metadades dels paquets de dades descriuen la seva longitud, d’on provenien, cap a on va, el protocol que utilitza, etc. L'especificació del protocol defineix la capçalera. Si podeu identificar el protocol, podeu determinar l’inici i el final de cada camp de la capçalera i llegir les metadades.

traceroute utilitza el conjunt de protocols TCP / IP i envia paquets de protocols User Datagram. La capçalera conté el camp Temps de vida (TTL), que conté un valor enter de vuit bits. Malgrat el que el seu nom indica, representa un recompte, no una durada.

Un paquet viatja des del seu origen fins al seu destí a través d’un enrutador. Cada vegada que el paquet arriba a un encaminador, disminueix el comptador TTL. Si el valor TTL arriba a un, l’encaminador que rep el paquet disminueix el valor i s’adona que ara és zero. El paquet es descarta i no es reenvia al següent salt del seu viatge perquè s'ha "esgotat el temps".

L’encaminador envia un missatge de protocol de missatge d’Internet (ICMP) Time Exceded de nou a l’origen del paquet per fer-li saber que el paquet s’ha esgotat. El missatge de temps excedit conté la capçalera original i els primers 64 bits de dades del paquet original. Això es defineix a la pàgina sis de Sol·licitud de comentaris 792.

Per tant, si traceroute envia un paquet, però, a continuació, estableix el valor TTL a un, el paquet només arribarà fins al primer encaminador abans de descartar-lo. Rebrà un missatge ICMP sobrepassat el temps del router i podrà registrar el temps que ha trigat el viatge d’anada i tornada.

A continuació, repeteix l'exercici amb TTL establert a 2, que fallarà després de dos salts. traceroute augmenta el TTL a tres i torna a intentar-ho. Aquest procés es repeteix fins que s'arriba a la destinació o es prova el nombre màxim de salts (30, per defecte).

Alguns routers no juguen bé

Alguns routers tenen errors. Intenten reenviar paquets amb un TTL de zero en lloc de descartar-los i augmentar el missatge ICMP sobrepassat el temps.

Segons Cisco, alguns proveïdors de serveis d'Internet (ISP) limiten el nombre de missatges ICMP que transmeten els seus enrutadors.

Alguns dispositius estan configurats per no enviar paquets ICMP. Sovint, això garanteix que el dispositiu no pugui ser forçat involuntàriament a participar en una denegació de servei distribuïda, com un atac de barrufets.

traceroute té un temps d'espera predeterminat per a respostes de cinc segons. Si no rep cap resposta en aquests cinc segons, l'intent s'abandona. Això vol dir que s’ignoren les respostes de routers molt lents.

Instal·lació de traceroute

traceroute ja estava instal·lat a Fedora 31, però s’ha d’instal·lar a Manjaro 18.1 i Ubuntu 18.04. Instal · lar traceroute a Manjaro utilitzeu l'ordre següent:

sudo pacman -Sy traceroute

Instal · lar traceroute a Ubuntu, utilitzeu l'ordre següent:

sudo apt-get install traceroute

Utilitzant traceroute

Com hem explicat més amunt, traceroute's El propòsit és obtenir una resposta del router a cada salt des del vostre ordinador fins a la destinació. Alguns poden tenir els llavis atapeïts i no regalen res, mentre que altres probablement vessaran les mongetes sense cap mena de dubte.

Com a exemple, executarem un traceroute al lloc web del castell de Blarney, a Irlanda, seu del famós Blarney Stone. La llegenda diu que si beses la pedra de Blarney, seràs beneït amb el "regal del gab." Esperem que els encaminadors que trobem al llarg del camí siguin adequadament garrulosos.

Escrivim l'ordre següent:

traceroute www.blarneycastle.ie

La primera línia ens proporciona la informació següent:

  • La destinació i la seva adreça IP.
  • El nombre de llúpols traceroute ho intentarà abans de rendir-se.
  • La mida dels paquets UDP que estem enviant.

Totes les altres línies contenen informació sobre un dels salts. Abans d’explorar els detalls, però, podem veure que hi ha 11 salts entre l’ordinador i el lloc web del castell de Blarney. Hop 11 també ens diu que vam arribar al nostre destí.

El format de cada línia de salt és el següent:

  • El nom del dispositiu o, si el dispositiu no s’identifica, l’adreça IP.
  • L'adreça IP.
  • El temps que va trigar anada i tornada en cadascuna de les tres proves. Si hi ha un asterisc, vol dir que no hi ha hagut cap resposta per a aquesta prova. Si el dispositiu no respon en absolut, veureu tres asteriscs i no hi haurà cap nom ni adreça IP del dispositiu.

Revisem el que tenim a continuació:

  • Salt 1: El primer port d'escala (sense cap joc de paraules) és el router DrayTek Vigor Router de la xarxa local. Així és com els nostres paquets UDP surten de la xarxa local i entren a Internet.
  • Salt 2: Aquest dispositiu no ha respost. Potser es va configurar per no enviar mai paquets ICMP. O potser sí que va respondre, però va ser massa lenttraceroute s'ha acabat el temps.
  • Salt 3: Un dispositiu va respondre, però no vam obtenir el seu nom, només l’adreça IP. Tingueu en compte que hi ha un asterisc en aquesta línia, cosa que significa que no hem rebut resposta a les tres sol·licituds. Això podria indicar la pèrdua de paquets.
  • Llúpol 4 i5: Llúpols més anònims.
  • Salt 6: Aquí hi ha molt de text perquè un dispositiu remot diferent gestionava cadascuna de les nostres sol·licituds UDP. Es van imprimir els noms (bastant llargs) i les adreces IP de cada dispositiu. Això pot passar quan trobeu una xarxa "molt poblada" en la qual hi ha molt maquinari per gestionar grans volums de trànsit. Aquest salt es troba dins d’un dels ISP més grans del Regne Unit. Per tant, seria un miracle menor que el mateix maquinari remot gestionés les nostres sol·licituds de connexió.
  • Salt 7: Aquest és el salt que han fet els nostres paquets UDP en sortir de la xarxa d’ISP.
  • Salt 8: De nou, obtenim una adreça IP però no el nom del dispositiu. Les tres proves van tornar amb èxit.
  • Llúpol 9i 10: Dos llúpols anònims més.
  • Salt 11: Hem arribat al lloc web del castell de Blarney. El castell es troba a Cork, Irlanda, però, segons la geolocalització de l'adreça IP, el lloc web es troba a Londres.

Per tant, era una bossa mixta. Alguns dispositius jugaven a la pilota, alguns responien però no ens van dir el seu nom i d’altres van romandre completament anònims.

Tot i això, vam arribar a la destinació, sabem que es troba a 11 llúpols i el temps d’anada i tornada del viatge va ser de 13,773 i 14,715 mil·lisegons.

Ocultar noms de dispositius

Com hem vist, incloure de vegades noms de dispositius condueix a una visualització desordenada. Per facilitar la visualització de les dades, podeu utilitzar el fitxer -n opció (sense mapatge).

Per fer-ho amb el nostre exemple, escrivim el següent:

traceroute -n blarneycastle.ie

Això fa que sigui més fàcil seleccionar un gran nombre per a horaris d’anada i tornada que puguin indicar un coll d’ampolla.

El salt 3 comença a semblar una mica sospitós. L'última vegada, només va respondre dues vegades i, aquesta vegada, només va respondre una vegada. En aquest escenari, està fora del nostre control, és clar.

Tanmateix, si investigueu la vostra xarxa corporativa, valdria la pena aprofundir una mica més en aquest node.

Definició del valor d'espera de la traceroute

Potser si ampliem el període d’espera per defecte (cinc segons), obtindrem més respostes. Per fer-ho, utilitzarem el fitxer -w opció (temps d'espera) per canviar-la a set segons. (Tingueu en compte que es tracta d’un número de coma flotant.)

Escrivim l'ordre següent:

traceroute -w 7.0 blarneycastle.ie

Això no va fer gaire diferència, de manera que les respostes probablement s’estan esgotant. És probable que els llúpols anònims siguin intencionadament secrets.

Configuració del nombre de proves

Per defecte, traceroute envia tres paquets UDP a cada salt. Podem utilitzar el -q (nombre de consultes) opció per ajustar-la cap amunt o cap avall.

Per accelerar el traceroute prova, escrivim el següent per reduir el nombre de paquets de sonda UDP que enviem a un:

traceroute -q 1 blarneycastle.ie

Això envia una sola sonda a cada salt.

Configuració del valor TTL inicial

Podem establir el valor inicial de TTL en alguna cosa diferent d’un i ometre algun salt. Normalment, els valors TTL s’estableixen a un per al primer conjunt de proves, dos per al següent conjunt de proves, etc. Si el posem a cinc, la primera prova intentarà saltar cinc i saltar els llúpols d'un a quatre.

Com que sabem que el lloc web de Blarney Castle és a 11 llúpols d’aquest ordinador, escrivim el següent per anar directament al salt 11:

traceroute -f 11 blarneycastle.ie

Això ens proporciona un bon informe resum sobre l'estat de la connexió amb la destinació.

Sigues considerat

traceroute és una gran eina per investigar l’encaminament de la xarxa, comprovar la velocitat de la connexió o identificar els colls d’ampolla. Windows també té un fitxer tracert ordre que funciona de manera similar.

Tanmateix, no voleu bombardejar dispositius desconeguts amb torrents de paquets UDP i desconfieu d’incloure’ls traceroute en scripts o treballs desatesos.

La càrrega traceroute pot col·locar en una xarxa pot afectar negativament el seu rendiment. A menys que estigueu en una situació de solucionar-ho ara, és possible que vulgueu utilitzar-lo fora de l'horari laboral normal.


$config[zx-auto] not found$config[zx-overlay] not found