Se hai mai lavorato nello spazio di rete, o in supporto per quella materia, probabilmente hai buone storie sulla risoluzione dei problemi di una connessione persa. Inevitabilmente, viene installato e configurato un nuovo sistema, ma non riusciamo a far passare il traffico da o verso il sistema.
Una di queste storie che posso ricordare è qualcosa del genere.
Il caso d'uso
Stavo risolvendo un problema con un array di storage back-end che era stato appena installato da una grande e nota società finanziaria americana. Il cliente stava tentando di configurare la replica dei dati dal suo sito di produzione (PROD) a Houston a un sito di ripristino di emergenza (DR) a San Antonio. Il sistema di ripristino di emergenza era stato implementato da tempo e aveva la reputazione di essere una buona configurazione nota.
Il sito di produzione era nuovo di zecca e, naturalmente, la causa di tutti i nostri problemi. Il vero problema era che non riuscivamo a far muovere il traffico tra le due interfacce di replica che avevamo configurato. Siamo stati in grado di raggiungere l'esterno del gateway sul sito DR, ma non siamo stati in grado di raggiungere l'esterno del sito PROD. Il traffico raggiungeva il dispositivo gateway e veniva interrotto.
Entro mezz'ora dalla risoluzione dei problemi, ho chiesto al client se disponeva di un firewall sul sito PROD che potrebbe bloccare il traffico sulle porte necessarie. "Certo che no, non c'è nessun firewall tra questi siti." Questa risposta è stata scioccante considerando che questa era una delle più grandi istituzioni finanziarie dell'intero paese. Ma, come tutte le posizioni rivolte ai clienti, devi essere rispettoso ed educato.
Quindi, ho eseguito tutti i controlli che potevo pensare da parte mia. Firewall di archiviazione interna disabilitato:verifica. Porte aperte da DR a PROD:check. Porte aperte da PROD a DR? No.
Si scopre che dopo quattro ore di risoluzione dei problemi e riconfigurazione delle interfacce, il cliente ha detto:"Fammi chiamare il nostro addetto al firewall".
Il tuo che ragazzo?
Questa è una posizione strana da assumere considerando che non hai un firewall tra questi siti. Ma non era strano, perché ovviamente avevano un firewall. Problema risolto. Ora che l'incubo è passato, gli strumenti che ho usato per capire dove si è verificato il problema erano il buon vecchio Telnet (di cui parleremo in un articolo successivo) e, naturalmente, traceroute .
Il comando
Ora che puoi vedere un chiaro caso d'uso per traceroute , parliamo del comando stesso e delle informazioni che puoi ottenere da esso. Lo scopo di questo articolo, dopotutto, è che tu riesca a ottenere un po' più di conoscenza dell'utilità che traceroute offerte.
La sintassi è piuttosto semplice. Il comando traceroute <x> (x qui essendo un IP o un nome host) è la versione più semplice e inizierà a inviare pacchetti alla destinazione designata. Questo risultato ti consentirà di tracciare il percorso dei pacchetti inviati dalla tua macchina a ciascuno dei sistemi tra te e la destinazione desiderata.
Ad esempio, se volessi tracciare il percorso dal mio computer a google.com , inserirei qualcosa del genere:
[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 ~]# Il guasto
Analizziamo questi risultati in morsi più piccoli. Questo comando può produrre molte informazioni e, come si suol dire, "Il modo migliore per mangiare un elefante è un morso alla volta:"
[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 Stiamo solo guardando il primo salto qui. Tuttavia, possiamo utilizzare questo hop per analizzare le informazioni visualizzate. Per prima cosa, vediamo cosa viene effettivamente inviato e dove:
traceroute to www.google.com(IP), 30 hops max, 60 byte packets
Da questo output, deduciamo che stiamo inviando traffico al target desiderato (www.google.com ). Traceroute, per impostazione predefinita, misura 30 hop di pacchetti da 60 byte.
Successivamente, vediamo che si verifica il primo hop. Qui stiamo colpendo il gateway esterno:
1 _gateway (192.168.2.1) 2.396 ms 2.726 ms 3.057 ms
Puoi dire qui dove è effettivamente atterrato il luppolo, e poi ci sono tre valori numerici. Questi sono noti come Round-Trip Time (RTT), che si riferisce alla quantità di tempo che un dato pacchetto impiega per raggiungere la sua destinazione e reindirizzare un messaggio ICMP alla fonte. Per impostazione predefinita, traceroute instrada tre pacchetti di dati per testare ogni hop. Puoi trovare maggiori informazioni su questo processo online, tuttavia, il fatto è che ogni pacchetto instrada un messaggio di errore ICMP all'origine quando raggiunge un dispositivo sulla rete. Questa azione consente traceroute per determinare l'RTT di quel pacchetto e non indica necessariamente un errore.
Ora, diamo un'occhiata ai luppoli da 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 Possiamo vedere qualcosa di nuovo qui. Hop 2 sembra normale:un dispositivo viene colpito con tempi RTT nell'intervallo di 100 millisecondi. Poi, diventa interessante. Vediamo solo stelle (*).
Cosa significano queste stelle (asterischi)? I pacchetti sono stati lasciati cadere? Sono scaduti?
Lasciatemi spiegare. Ci sono due possibilità quando si tratta di queste stelle. Innanzitutto, ICMP/UDP potrebbe non essere configurato. Se il traceroute il comando viene completato correttamente e vengono visualizzate queste stelle, molto probabilmente il dispositivo che è stato colpito non è stato configurato per rispondere al traffico ICMP/UDP. Questo risultato non significa che il traffico non sia stato superato. La seconda possibilità è che i pacchetti siano stati eliminati a causa di un problema sulla rete. Questi risultati sono in genere timeout dei pacchetti o il traffico è stato bloccato da un firewall.
Come puoi vedere nell'esempio sopra, anche dopo aver visto le stelle al hop 2, i pacchetti continuano e vengono reindirizzati al hop 4. Questo comportamento porta a un traceroute riuscito. come possiamo vedere che Google è stato raggiunto.
L'asporto
Traceroute può essere uno strumento prezioso quando si tratta di risolvere i problemi di rete. Aiuta davvero a visualizzare dove si verifica effettivamente il problema. Naturalmente, ci sono altre operazioni in corso dietro le quinte di traceroute che non sono stati trattati qui.
Consiglio vivamente se vuoi dare un'occhiata ancora più approfondita a questo strumento di fare qualche ricerca online. Ci sono molte informazioni su Time-to-Live (TTL) e RTT che, nell'interesse del tempo, non sono state incluse in questo articolo. Il mio obiettivo è che ora tu abbia una migliore comprensione di quando e perché dovresti usare traceroute strumento e come interpretare i dati che offre. Per ulteriori informazioni sulla risoluzione dei problemi di rete e sui concetti, consulta i nostri articoli correlati qui.