Comandi di rete Linux: ip, ss, ping, traceroute, dig e curl per la diagnostica

I comandi di rete Linux coprono quasi tutta la diagnostica di tutti i giorni: ip mostra indirizzi e route, ss le porte aperte e le connessioni, ping e traceroute verificano la raggiungibilità di un host, dig controlla il DNS e curl la risposta di un servizio web. Qui sotto trovi un riepilogo con le opzioni principali e un ordine di verifica pratico per capire la causa quando «la rete non funziona».

Riepilogo: i comandi di rete Linux in una tabella

ip: indirizzi, interfacce e route

Il comando ip, parte del pacchetto iproute2, ha sostituito i comandi obsoleti ifconfig e route. I sottocomandi si possono abbreviare: ip a equivale a ip addr, ip r a ip route. L'opzione -br produce un output sintetico, -c lo colora.

$ ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             192.168.1.25/24 fe80::a00:27ff:fe4e:66a1/64
docker0          DOWN           172.17.0.1/16

Se un'interfaccia non ha un indirizzo della rete giusta o è in stato DOWN, inutile cercare oltre: il problema è a questo livello.

Come aggiungere un indirizzo IP e attivare un'interfaccia

sudo ip link set eth0 up
sudo ip addr add 192.168.1.50/24 dev eth0
sudo ip addr del 192.168.1.50/24 dev eth0

Le modifiche fatte con ip valgono fino al riavvio. Le impostazioni permanenti si definiscono nella configurazione di sistema: netplan su Ubuntu, NetworkManager (nmcli) su Fedora e RHEL, systemd-networkd sui server.

Route e gateway predefinito

$ ip route
default via 192.168.1.1 dev eth0 proto dhcp metric 100
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.25

$ ip route get 10.20.0.5
10.20.0.5 via 192.168.1.1 dev eth0 src 192.168.1.25 uid 1000

La riga default via indica il gateway verso cui va tutto ciò che non corrisponde a route più specifiche. Se manca, non c'è accesso a Internet, anche se la rete locale funziona. Per aggiungere una route: sudo ip route add 10.20.0.0/16 via 192.168.1.254.

ss: quali porte sono aperte e chi le ascolta

ss ha sostituito netstat ed è più veloce. La combinazione più usata è ss -tulpn:

$ sudo ss -tulpn
Netid State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
tcp   LISTEN 0      511          0.0.0.0:80         0.0.0.0:*     users:(("nginx",pid=812,fd=6))
tcp   LISTEN 0      128          0.0.0.0:22         0.0.0.0:*     users:(("sshd",pid=640,fd=3))
tcp   LISTEN 0      151        127.0.0.1:3306       0.0.0.0:*     users:(("mysqld",pid=901,fd=21))

Fai attenzione all'indirizzo: 0.0.0.0 significa che il servizio accetta connessioni da tutte le interfacce, 127.0.0.1 solo da locale. È una causa frequente del motivo per cui un database «non risponde» da un'altra macchina.

Come scoprire chi occupa una porta

sudo ss -ltnp 'sport = :8080'
sudo ss -tn dst 10.0.0.7          # connessioni verso un indirizzo specifico
ss -tan state time-wait | wc -l   # quanti socket sono in TIME-WAIT

ping: l'host è raggiungibile?

ping invia richieste ICMP echo e mostra il tempo di risposta e le perdite. Su Linux non si ferma da solo, quindi indica il numero di pacchetti con -c.

$ ping -c 4 8.8.8.8
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=12.4 ms
...
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 12.1/12.5/13.0/0.3 ms

Opzioni utili: -i 0.2 intervallo, -W 2 timeout di risposta, -4/-6 versione del protocollo, -s 1472 -M do per verificare la MTU senza frammentazione. Ricorda che molti server e cloud bloccano ICMP: l'assenza di risposta al ping non significa che l'host sia irraggiungibile.

traceroute e mtr: dove si perdono i pacchetti

traceroute mostra i nodi lungo il percorso verso la destinazione. Gli asterischi su singoli hop sono normali: un router intermedio può non rispondere. Il segnale d'allarme è quando dopo un certo hop gli asterischi continuano fino alla fine.

traceroute -n example.com        # senza nomi DNS, più veloce
sudo traceroute -T -p 443 example.com   # TCP invece di UDP, attraversa i firewall
tracepath example.com            # senza root, mostra anche la MTU

mtr unisce ping e traceroute e aggiorna in tempo reale le statistiche di perdita per ogni hop. Per un report: mtr -rwc 50 example.com.

dig: verifica del DNS

dig, dal pacchetto dnsutils (bind-utils su RHEL), è lo strumento principale per controllare il DNS. La forma breve restituisce solo la risposta:

$ dig +short example.com
93.184.215.14

$ dig example.com MX +short
$ dig @8.8.8.8 example.com A       # interroga un server specifico
$ dig -x 8.8.8.8 +short            # record inverso (PTR)
$ dig +trace example.com           # percorre la catena a partire dai server radice

Nell'output completo guarda lo status: NOERROR significa record trovato, NXDOMAIN dominio inesistente, SERVFAIL il server non è riuscito a rispondere (spesso problemi di DNSSEC o un server autoritativo irraggiungibile). Se dig @8.8.8.8 risponde ma il dig normale no, il colpevole è il resolver locale: controlla /etc/resolv.conf e resolvectl status.

Attenzione: dig non legge /etc/hosts. Per verificare la risoluzione di un nome come la farebbe un'applicazione, usa getent hosts example.com.

curl: verifica di HTTP e API

curl risponde all'ultima domanda: il servizio risponde e cosa restituisce?

$ curl -s -o /dev/null -w '%{http_code} %{time_connect} %{time_total}\n' https://example.com
200 0.041 0.187

I messaggi d'errore di curl indicano bene il livello: Could not resolve host è un problema di DNS, Connection refused porta chiusa o nessuno in ascolto, Connection timed out pacchetti bloccati dal firewall o nessuna route, SSL certificate problem problema con il certificato.

Ordine di diagnostica: quando «la rete non funziona»

1. Interfaccia e indirizzo: ip -br addr — l'interfaccia è UP e ha un indirizzo.
2. Gateway: ip route — c'è una riga default via; poi ping -c 3 <gateway>.
3. Rete esterna per IP: ping -c 3 1.1.1.1. Se funziona, l'instradamento è a posto.
4. DNS: dig +short example.com. Se è vuoto o dà errore mentre il ping per IP funziona, il problema è nel resolver.
5. Porta: nc -zv host 443 oppure curl -v. Sul server, ss -tulpn per vedere se il servizio ascolta e su quale indirizzo.
6. Firewall: sudo nft list ruleset, sudo iptables -L -n, sudo ufw status.
7. Applicazione: curl -I e i log del servizio (journalctl -u nginx).

Procedi dal basso verso l'alto e non saltare i passaggi: in pochi minuti capisci a quale livello si trova il problema, invece di riavviare tutto alla cieca.

Comandi vecchi e nuovi

Nelle distribuzioni recenti net-tools spesso non è installato affatto, quindi conviene abituarsi ai comandi nuovi.

Conclusioni

Per la diagnostica quotidiana bastano sei comandi di rete Linux: ip, ss, ping, traceroute, dig e curl. Verifica a strati — indirizzo, route, DNS, porta, applicazione — e il guasto si trova in fretta. Comandi di rete e casi tipici di guasto sono mostrati in pratica nel corso di Linux.