La Lettera che Cambia Busta

Table of Contents

TL;DR

traceroute -n 8.8.8.8 mostra i 14 router tra te e Google - ogni riga è un salto (hop)
IP address = destinazione finale, non cambia mai; MAC address = tratto corrente, cambia ad ogni hop
Il router legge l'IP dentro (la lettera), riscrive il MAC fuori (la busta) e passa il pacchetto al prossimo salto
* * * non significa percorso interrotto - solo che quel router non risponde a ICMP/UDP; prova con -T (TCP)

▶ $ history

traceroute -n 8.8.8.8
traceroute -I -n 8.8.8.8
sudo traceroute -T google.com
ip neighbor show
ip route show

Sistema: Linux (testato su Kali 2024 e Ubuntu 24.04) Tools: traceroute, ip - già installati di default Conoscenze: nessuna - si parte da zero

Digiti un indirizzo nel browser. In meno di un secondo la pagina appare.

Sembra magia. Non lo è.

Tra il tuo computer e il server di Google ci sono 14 router, migliaia di chilometri di fibra, e un meccanismo che quasi nessuno ha mai visto funzionare. Questo post lo mostra - partendo da un comando.

Il Viaggio di un Pacchetto TCP: Anatomia di una Connessione di Rete

graph TD
    Problema["Cosa succede davvero\nquando mando un pacchetto?"]
    Problema --> A1["Step 1 - traceroute\nvedi i router sul percorso"]
    Problema --> A2["Step 2 - IP vs MAC\ncapire i due indirizzi"]
    Problema --> A3["Step 3 - il viaggio\nbusta che cambia ad ogni hop"]

    A1 --> Q1["Quanti hop?\nChi li gestisce?"]
    A2 --> Q2["Perché due indirizzi?\nCosa cambia, cosa rimane?"]
    A3 --> Q3["Come fa il router\na sapere dove mandarlo?"]

Step 1 - Traceroute: vedi i router sul percorso
#

traceroute -n 8.8.8.8

Il flag -n evita la risoluzione DNS - l'output è più veloce e più leggibile.

Output reale dalla mia macchina (Kali Linux, lab UTM su Mac):

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
192.168.64.1      0.5 ms
192.168.1.254     7.0 ms
192.168.128.1     8.9 ms
* * *
172.30.25.209    36.7 ms
10.103.79.109    40.5 ms
10.1.129.41      33.8 ms
10.254.2.253     40.2 ms
93.57.68.133     41.3 ms
62.101.124.1     43.9 ms
209.85.168.64    43.8 ms
192.178.104.103  36.8 ms
192.178.82.61    36.7 ms
8.8.8.8          39.0 ms

Ogni riga è un router. Ogni router è un hop - un salto.

Hop non è un acronimo: è una parola inglese che significa letteralmente "salto". Un hop è il salto di un pacchetto da un router al successivo.

Cosa significa: in 14 salti, la mia richiesta raggiunge un server Google in Europa. Hop 1 risponde in 0.5ms (è il gateway della mia VM, in casa). Hop 14 risponde in 39ms (è Google, da qualche parte nel backbone europeo).

Step 2 - IP vs MAC: due indirizzi, due scopi
#

Il Viaggio di un Pacchetto TCP: Anatomia di un pachetto TCP

Prima di capire il viaggio, bisogna risolvere una cosa che confonde quasi tutti.

Un pacchetto ha due tipi di indirizzo completamente diversi:

IP address  → "dove vuoi arrivare"
              es. 8.8.8.8
              logico - identifica una destinazione su internet
              non cambia per tutto il viaggio

MAC address → "su quale cavo mando il pacchetto adesso"
              es. b6:56:08:90:16:03
              fisico - identifica una scheda di rete specifica
              valido solo nella subnet locale (LAN)
              cambia ad ogni hop

Puoi vedere i MAC dei dispositivi nella tua LAN con:

ip neighbor show

Output dalla VM Kali del lab:

192.168.64.3  dev eth0  lladdr b6:56:08:90:16:03  REACHABLE
192.168.64.1  dev eth0  lladdr 72:8c:f2:1b:c8:64  REACHABLE

Cosa significa: Kali conosce il MAC di Ubuntu (192.168.64.3) e del gateway (192.168.64.1). Google (8.8.8.8) non compare - il suo MAC non arriva mai fino a qui.

Anatomia di un Salto: Il Viaggio del Pacchetto

Step 3 - Il viaggio: la busta che cambia
#

Ogni pacchetto ha due "strati" sovrapposti:

┌──────────────────────────────────────────┐
│  Header Ethernet (Layer 2)               │
│  MAC sorgente:      il mio MAC           │  ← cambia ad ogni hop
│  MAC destinazione:  MAC del prossimo hop │
├──────────────────────────────────────────┤
│  Header IP (Layer 3)                     │
│  IP sorgente:       il mio IP            │  ← invariato per tutto il viaggio
│  IP destinazione:   8.8.8.8              │
├──────────────────────────────────────────┤
│  Payload (TCP/UDP/dati...)               │
└──────────────────────────────────────────┘

Pensa a una lettera spedita da Firenze a Roma passando per Bologna:

La lettera dentro  → indirizzo finale: "Roma, Via X"  - non cambia mai
La busta esterna   → indirizzo intermedio: "Bologna"  - cambia ad ogni ufficio postale

Il router fa esattamente questo: legge l'IP destinazione (la lettera dentro), decide dove mandare il pacchetto, poi riscrive l'header Ethernet (la busta) con i MAC del prossimo tratto.

Il viaggio completo verso Google:

sequenceDiagram
    participant K as Kali (192.168.64.200)
    participant GW as Gateway UTM (192.168.64.1)
    participant R as Router di casa (192.168.1.254)
    participant ISP as Backbone ISP
    participant G as Google (8.8.8.8)

    Note over K,GW: Stessa LAN - usa MAC
    K->>GW: MAC[kali→gateway] IP[kali→8.8.8.8]

    Note over GW,R: Router riscrive header Ethernet
    GW->>R: MAC[gw→router] IP[kali→8.8.8.8]

    Note over R,ISP: IP invariato, MAC nuovo
    R->>ISP: MAC[router→isp] IP[kali→8.8.8.8]

    Note over ISP,G: 10 hop nel mezzo...
    ISP->>G: MAC[lastrouter→google] IP[kali→8.8.8.8]

Step 4 - Chi sono questi router?
#

Senza -n, traceroute risolve i nomi DNS degli hop. Rivela chi gestisce ogni tratto:

sudo traceroute -T google.com

myfastgate.lan (192.168.1.254)        ← router di casa - Fastweb
192.168.128.1                         ← primo nodo ISP
93-57-68-133.ip163.fastwebnet.it      ← backbone Fastweb - IP pubblico
62-101-124-5.fastres.net              ← uscita Fastweb verso internet
209.85.168.64                         ← infrastruttura Google
pnmila-ag-in-f14.1e100.net            ← server Google Milano

Hop 1-3: casa e ISP locale. Hop 4: * * * - router configurato per non rispondere. Normale. Hop 5-8: backbone interno Fastweb, IP privati. Hop 9-10: uscita su IP pubblici. Hop 11-14: Google.

Come fa il router a sapere dove mandare il pacchetto? Ha una tabella di routing - una mappa locale. Puoi vedere la tua:

ip route show

default via 192.168.64.1 dev enp0s1    ← tutto il resto → gateway
192.168.64.0/24 dev enp0s1             ← questa subnet → diretto

"Default via" è il router di casa. Tutto quello che non conosco direttamente, lo mando lì. Poi è compito suo decidere il passo successivo - e così via fino a Google.

Come fanno i router su internet a trovarsi?
#

Dentro la tua LAN il router trova il MAC del prossimo hop tramite ARP - lo abbiamo visto. Ma tra due router a metà strada tra Firenze e Google, ARP non funziona: sono su reti diverse.

La risposta è BGP - Border Gateway Protocol. È il protocollo che tiene in piedi internet. Ogni grande rete (ISP, Google, Fastweb) ha un numero identificativo chiamato AS (Autonomous System). I router BGP si parlano continuamente, scambiandosi informazioni su quali reti sono raggiungibili da dove. Fastweb dice a Google "per i miei IP passa da me", Google risponde "per i miei passa da me". Ogni router aggiorna la sua tabella di routing in base a queste informazioni - in tempo reale.

Tra due router direttamente connessi (un link fisico dedicato tra due datacenter), il MAC del prossimo hop viene risolto tramite ARP su quel segmento - esattamente come nella tua LAN, ma su una fibra che collega due edifici a chilometri di distanza.

BGP è anche il protocollo più delicato di internet: un errore di configurazione può reindirizzare il traffico di mezzo mondo verso il posto sbagliato. È successo più volte.

Varianti e casi edge
#

macOS vs Linux

Su macOS traceroute usa ICMP di default invece di UDP. Il comportamento è lo stesso, ma alcuni router che filtrano UDP su Linux rispondono su macOS e viceversa.

# Linux default (UDP)
traceroute -n 8.8.8.8

# Forza ICMP (come macOS) - supera alcuni firewall
traceroute -I -n 8.8.8.8

# Forza TCP - supera quasi tutti i firewall
sudo traceroute -T -n 8.8.8.8

Hop con * * * - tre scenari diversi

* * *  →  router che filtra ICMP/UDP (comune, normale)
* * *  →  firewall che blocca (possibile problema)
* * *  →  pacchetto perso per congestione (raro ma possibile)

Se gli hop successivi al * * * rispondono, il router c'è ma filtra. Se dopo il * * * ci sono solo * * *, il pacchetto si è perso lì.

ARP cache e primo hop

Il MAC del gateway viene salvato in cache. Puoi vedere lo stato:

ip neighbor show
# 192.168.64.1 dev eth0 lladdr 72:8c:f2:1b:c8:64 REACHABLE
# REACHABLE  → comunicazione recente, MAC valido
# STALE      → obsoleto, da verificare alla prossima comunicazione
# FAILED     → nessuna risposta

La cache ARP riguarda solo i MAC locali - mai i router su internet.

Quando NON usarlo
#

Traceroute non funziona (o dà risultati incompleti) in questi casi:

Firewall che bloccano completamente ICMP e UDP - vedi solo * * *. Prova con -T (TCP).
CGNAT (Carrier-grade NAT) - alcuni ISP mascherano i loro router interni, gli hop appaiono con IP privati ripetuti o mancanti.
Reti con routing asimmetrico - il percorso di andata e quello di ritorno sono diversi. Traceroute vede solo l'andata.
Diagnostica applicativa - traceroute mostra il percorso di rete, non i problemi a livello applicativo (DNS, TLS, HTTP). Se il sito non carica ma traceroute arriva a destinazione, il problema è sopra il Layer 3.

exit 0
#

Il MAC è locale. L'IP è globale. Il router è il traduttore tra i due.

Ogni volta che apri un browser, il tuo computer non sa come arrivare a Google - sa solo come arrivare al prossimo router. Poi è quel router a sapere il passo successivo. E così via, salto dopo salto, fino a destinazione.

traceroute rende visibile questa catena di fiducia. In un SOC, è il primo strumento che usi quando qualcosa "non risponde" - ti dice esattamente dove il viaggio si interrompe.

Comandi usati: traceroute, ip Concetti correlati: routing-hop-ttl, icmp-mac-ip, arp

Step 1 - Traceroute: vedi i router sul percorso#

Step 2 - IP vs MAC: due indirizzi, due scopi#

Step 3 - Il viaggio: la busta che cambia#

Step 4 - Chi sono questi router?#

Come fanno i router su internet a trovarsi?#

Varianti e casi edge#

Quando NON usarlo#

exit 0#

Related