Traceroute su Linux: scopri dove viene bloccata una connessione prima di dare la colpa al server.

Quando un sito web o un server smette di rispondere, la prima reazione è spesso quella di dare la colpa al computer remoto. Ma non è sempre così. L’interruzione potrebbe avere origine nella rete locale, nel router, nel filtraggio tra due provider, in un firewall o semplicemente in un percorso di rete errato.

traceroute Il suo scopo è proprio quello di esaminare il percorso seguito dai pacchetti. Non fornisce la verità assoluta, ma aiuta a capire da dove iniziare la risoluzione dei problemi prima di riavviare un servizio che non lo ha richiesto.

Installa traceroute se il comando non è presente

Su certe distribuzioni, traceroute Non è installato di default. Innanzitutto, verifica se è presente.

comando -v traceroute
traceroute --version

Se il comando non è presente, installa il pacchetto appropriato per la tua distribuzione.

sudo apt update
sudo apt install traceroute

sudo dnf install traceroute
sudo pacman -S traceroute

Su un server di produzione, preferisco installare lo strumento correttamente piuttosto che eseguire un comando prelevato a caso da un container o da un eseguibile di terze parti. Dovresti essere in grado di ripetere il test in seguito, nelle stesse condizioni.

Avvia un primo traceroute pulito

Per testare il percorso verso un dominio, è sufficiente utilizzare:

traceroute linuxencaja.net

L’output mostra un elenco di hop. Ogni riga corrisponde in genere a un router attraversato. Spesso vengono visualizzati il ​​numero dell’hop, il nome o l’indirizzo IP del router e diversi tempi di risposta.

Per evitare una lenta risoluzione DNS durante la diagnosi, aggiungere -NQuesto è spesso il primo test che eseguo quando voglio andare veloce.

traceroute -n linuxencaja.net

Se il nome di dominio stesso sembra sospetto, inizia separando il problema DNS dal problema di rete. La guida su Cache DNS su Linux Questo passaggio è stato completato correttamente, soprattutto se la macchina visualizza un vecchio indirizzo IP e non un altro.

Interpreta le stelle senza trarre conclusioni affrettate.

Le stelle * * * Questi errori non significano automaticamente che la rete sia guasta. Indicano principalmente che il nodo di destinazione non risponde come previsto ai pacchetti utilizzati da traceroute. Molti router filtrano o limitano queste risposte.

Il punto cruciale è il resto del percorso. Se un hop mostra delle stelle, ma gli hop successivi rispondono e anche la destinazione finale risponde, probabilmente il router intermedio non è colpa tua.

D’altra parte, se il traceroute si interrompe sempre nello stesso punto e non si verifica alcuna risposta in seguito, è necessario esaminare un’area specifica: gateway locale, routing dell’operatore, VPN, firewall, filtro host o guasto sul lato di destinazione.

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

Confrontare più destinazioni evita false piste. Se tutto viene bloccato al primo o al secondo hop, controlla la tua rete locale. Se solo un server specifico blocca il traffico, è più probabile che il problema sia legato a quel percorso, a quel provider o a un filtro specifico.

Scegliere ICMP o TCP a seconda del contesto.

Per impostazione predefinita, traceroute potrebbe utilizzare pacchetti che non assomigliano necessariamente al traffico dell’applicazione che si sta cercando di diagnosticare. Se si sta testando un sito web, un test TCP sulla porta 443 potrebbe essere più informativo.

sudo traceroute -T -p 443 linuxencaja.net

Per un test ICMP, vicino allo spirito di ping, utilizzo -IO.

sudo traceroute -I 8.8.8.8

Le pagine di manuale di traceroute E ping Descrivono dettagliatamente queste modalità. In pratica, ricordo soprattutto questo: se il browser non funziona con HTTPS, prova anche con TCP 443. Un traceroute UDP o ICMP potrebbe rivelare una situazione diversa.

Prima di dare la colpa a internet, controlla il percorso locale.

Se i primi hop sono incoerenti, verifica il percorso utilizzato dalla tua macchina. Questo è fondamentale su un server con più interfacce, una VPN, un percorso statico o un indirizzo IP secondario.

percorso IP
ip route get 8.8.8.8
ip route get 1.1.1.1

ottenere il percorso ip Mostra l’interfaccia, il gateway e, a volte, l’indirizzo sorgente utilizzato per raggiungere una destinazione. Se l’output non corrisponde a quanto previsto, traceroute sta semplicemente confermando un percorso locale errato.

Prima di modificare una rotta da remoto, mantieni una sessione SSH aperta e assicurati di avere accesso alla console. Una rotta predefinita errata può disconnetterti dal server più velocemente di un servizio riavviato in modo errato.

Distinguere tra latenza, perdita e filtraggio

Un singolo hop ad alta latenza non è sufficiente a dimostrare che il router sia responsabile. Alcuni router rispondono lentamente ai pacchetti diagnostici, ma continuano a inoltrare il traffico normalmente.

Ciò che mi interessa di più è un degrado che si protrae in tutti i salti successivi, o una perdita di qualità visibile fino alla destinazione finale. È allora che si può iniziare a parlare di un vero problema con il percorso o con la destinazione.

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

Se devi controllare le porte aperte sul lato server, non mescolare tutto in traceroute. Usa invece Utilizza i comandi ss o netstat per verificare le porte aperte in Linux.Traceroute mostra il percorso. ss mostra cosa sta realmente ascoltando sulla macchina.

Quando utilizzare tracepath invece

tracepath Questo può essere utile quando si desidera un test rapido senza opzioni avanzate. È spesso disponibile tramite il pacchetto iputils e può anche segnalare informazioni relative all’MTU del percorso.

tracepath linuxencaja.net
tracepath 1.1.1.1

La pagina di manuale di tracepath Rimane un buon riferimento se si vogliono comprendere i suoi limiti. Per una diagnosi precisa su una porta o modalità particolare, faccio ancora riferimento a traceroute.

Il metodo che utilizzo prima di modificare una configurazione

Quando la connessione fallisce, eseguo i controlli in quest’ordine:

• testa il DNS con un indirizzo IP e un nome di dominio;
• gettare traceroute -n verso diverse destinazioni;
• testare la modalità appropriata, ad esempio -T -p 443 per HTTPS;
• controllare ottenere il percorso ip dalla macchina in questione;
• controllare la porta lato server con ss se la strada raggiunge con successo la sua destinazione;
• Si noti il ​​salto nel punto in cui il percorso si interrompe prima dell’apertura di un ticket di operatore o di hosting.

Con questo metodo, si evita il classico errore: riavviare un server o intervenire sul firewall quando il problema risiede a monte. E se il problema si ripresenta, si avrà almeno una registrazione chiara del percorso, della porta testata e del percorso locale utilizzato.

sudo apt update && sudo apt upgrade