Rete Linux spiegata semplice: interfacce, IP, socket e firewall

Quando si inizia a usare Linux, la rete è uno di quegli argomenti che possono sembrare subito complicati. Appena qualcosa non funziona, la frase più comune è: “internet non va”. In realtà, detta così, questa frase dice molto poco.

Su Linux la rete non è un unico interruttore acceso o spento. È una catena di livelli che coinvolge hardware, driver, interfacce di rete, indirizzi IP, gateway, DNS, socket, porte, routing e firewall.

Capire questa catena è molto più importante che imparare subito una lunga lista di comandi. I comandi servono, naturalmente, ma diventano davvero utili solo quando sappiamo quale domanda stiamo facendo al sistema.

Perché la rete Linux va capita a livelli

Il primo errore da evitare è pensare alla rete come a qualcosa di unico. Quando un sito non si apre, il problema potrebbe essere in molti punti diversi.

Potrebbe mancare il collegamento fisico. Potrebbe esserci un problema con la scheda di rete. Potrebbe esserci un driver non corretto. L’interfaccia potrebbe essere presente ma disattivata. Il sistema potrebbe non avere un indirizzo IP. Il gateway potrebbe essere sbagliato. Il DNS potrebbe non risolvere i nomi. Il firewall potrebbe bloccare il traffico. Oppure il servizio remoto potrebbe semplicemente non rispondere.

Dire “la rete non funziona” è quindi troppo generico.

Linux, però, ci aiuta molto perché espone questi livelli in modo osservabile. Possiamo controllare le interfacce, gli indirizzi, le rotte, i socket, le porte aperte e il comportamento dei servizi. Questo è uno dei motivi per cui Linux è così usato nel mondo server, cloud, networking, DevOps e cybersecurity.

Schede di rete e driver

Alla base della comunicazione troviamo la scheda di rete. Può essere una scheda Ethernet, una scheda Wi-Fi, un adattatore USB, una scheda presente in un server oppure una interfaccia virtuale creata da una macchina virtuale, da un container, da una VPN o da un bridge.

Una scheda di rete, da sola, non basta. Il kernel deve poterla usare, e per farlo ha bisogno di un driver.

Il driver è il componente che permette al kernel Linux di comunicare con il dispositivo. Possiamo immaginarlo come un interprete tra l’hardware e il sistema operativo. La scheda parla il suo linguaggio specifico; il kernel ha bisogno di un componente che sappia gestirla.

Quando il driver funziona correttamente, Linux può esporre quella scheda come interfaccia di rete. Quando invece il driver manca o ha problemi, la scheda potrebbe non essere rilevata, oppure potrebbe funzionare male.

Questo ci fa capire una cosa importante: non tutti i problemi di rete riguardano IP, DNS o firewall. Alcuni problemi stanno più in basso, nel rapporto tra hardware, driver e kernel.

Cosa sono le interfacce di rete

Una interfaccia di rete è il punto attraverso cui Linux invia e riceve traffico.

Nei vecchi esempi si trovano spesso nomi come eth0 per una interfaccia Ethernet e wlan0 per il Wi-Fi. Su molte distribuzioni moderne, invece, si vedono nomi come enp3s0, ens33, wlp2s0 e simili.

A prima vista questi nomi possono sembrare strani, ma il concetto è semplice: Linux assegna un nome a ogni punto di comunicazione di rete.

Una macchina può avere una sola interfaccia oppure molte. Un portatile può avere Ethernet e Wi-Fi. Un server può avere più schede fisiche. Una macchina virtuale può avere una scheda virtuale. Docker può creare bridge e interfacce virtuali. Una VPN può aggiungere un nuovo punto di comunicazione.

Per osservare queste informazioni, uno dei comandi più importanti è ip.

Con ip link possiamo vedere le interfacce. Con ip addr possiamo vedere anche gli indirizzi associati. Con ip route possiamo osservare le rotte.

Il punto non è imparare subito tutte le opzioni del comando ip, ma capire che ip serve a chiedere al sistema: “come è configurata la rete?”.

Interfaccia attiva non significa internet funzionante

Un altro passaggio fondamentale è questo: una interfaccia attiva non significa automaticamente che internet funzioni.

Una interfaccia può esistere, ma non avere un indirizzo IP. Può avere un indirizzo IP, ma non avere un gateway. Può avere il gateway, ma non avere DNS funzionante. Può avere tutto apparentemente corretto, ma essere bloccata da un firewall. Oppure può essere tutto corretto lato macchina, ma il problema può essere nella rete esterna.

Questo è uno dei motivi per cui la rete va letta come una sequenza.

Prima ci chiediamo se il dispositivo esiste. Poi se l’interfaccia è attiva. Poi se ha un indirizzo IP. Poi se esiste una rotta verso l’esterno. Poi se il gateway è raggiungibile. Poi se il DNS risolve i nomi. Poi se il servizio remoto risponde.

Questa mentalità evita molta confusione, soprattutto quando si lavora su server Linux.

Indirizzo IP, gateway e DNS

Tre concetti che vanno distinti bene sono indirizzo IP, gateway e DNS.

L’indirizzo IP identifica una macchina, o più precisamente una interfaccia, dentro una rete. Un esempio IPv4 classico è 192.168.1.10. Esistono anche gli indirizzi IPv6, più lunghi e con una notazione diversa, ma l’idea generale resta la stessa: per comunicare in una rete IP, una macchina deve avere un indirizzo.

Il gateway è invece la porta verso altre reti. Nella rete di casa, spesso coincide con il router. Se il computer deve parlare con un dispositivo della stessa rete locale, può farlo direttamente. Ma se deve raggiungere internet, deve sapere a chi consegnare il traffico diretto fuori dalla rete locale. Questo ruolo è svolto dal gateway.

Il DNS, infine, traduce i nomi in indirizzi IP. Noi scriviamo nomi come example.com, ma i computer comunicano usando indirizzi. Il DNS fa da sistema di traduzione.

Questi tre elementi rispondono a domande diverse.

L’IP risponde alla domanda: “chi sono nella rete?”. Il gateway risponde alla domanda: “da dove esco per raggiungere altre reti?”. Il DNS risponde alla domanda: “a quale indirizzo corrisponde questo nome?”.

Quando questi concetti vengono confusi, anche la diagnosi dei problemi diventa confusa.

Stack TCP/IP: la rete come pila di livelli

La rete funziona grazie a una serie di protocolli organizzati a livelli. Per questo si parla spesso di stack TCP/IP.

IP si occupa dell’indirizzamento e dell’instradamento dei pacchetti. TCP aggiunge una comunicazione affidabile, con controllo, ordine e ritrasmissione quando necessario. UDP è più leggero e non offre le stesse garanzie di TCP, ma è utile in molti scenari dove servono velocità o semplicità.

Sopra questi livelli troviamo protocolli applicativi come HTTP, HTTPS, SSH, DNS, SMTP e molti altri.

Quando apriamo un sito web, non stiamo usando “la rete” in modo generico. Stiamo usando un browser, che comunica tramite un protocollo applicativo, sopra TCP o UDP, sopra IP, attraverso una interfaccia di rete, gestita dal kernel e dal driver.

Questo modello a livelli è fondamentale perché permette di separare le responsabilità. Ogni livello fa una parte del lavoro.

Socket e porte

Uno dei concetti più importanti della rete Linux è il socket.

Un socket è un punto di comunicazione usato da un processo. Quando un programma vuole comunicare in rete, non scrive direttamente pacchetti sulla scheda di rete. Chiede al sistema operativo di aprire un socket.

Quel socket può essere associato a un protocollo, a un indirizzo IP, a una porta e a una comunicazione con un altro sistema.

Un browser apre socket per collegarsi ai server web. Un server web apre socket in ascolto, per esempio sulle porte 80 o 443. Un client SSH apre un socket verso un server SSH, spesso sulla porta 22.

Le porte servono a distinguere servizi diversi sulla stessa macchina. L’indirizzo IP identifica l’host, mentre la porta identifica il servizio o il punto di ingresso.

Su uno stesso server possono esistere molti servizi: SSH sulla porta 22, HTTP sulla porta 80, HTTPS sulla porta 443, un database su un’altra porta, e così via.

Il comando ss è molto utile proprio per osservare socket, connessioni e porte in ascolto. Anche qui non è importante memorizzare ogni opzione, ma capire la domanda: “quali processi stanno comunicando o ascoltando sulla rete?”.

Client e server sono ruoli

Quando parliamo di rete, usiamo spesso le parole client e server.

Il client è il programma che avvia una richiesta. Il server è il programma che resta in ascolto e risponde.

Quando apriamo un sito, il browser è il client e il web server remoto è il server. Quando ci colleghiamo via SSH, il comando SSH è il client e il demone SSH sulla macchina remota è il server.

È importante capire che client e server sono ruoli, non necessariamente tipi diversi di computer.

Lo stesso sistema può essere client in una situazione e server in un’altra. Un server Linux può rispondere agli utenti come server web, ma allo stesso tempo comportarsi da client quando interroga un database, un DNS, un servizio di autenticazione o un’API esterna.

Questa distinzione è molto utile quando si ragiona sui servizi e sulle porte aperte.

Routing: dove mandare i pacchetti

Il routing è il processo con cui Linux decide dove mandare i pacchetti.

Quando un pacchetto deve uscire, il kernel guarda la destinazione e consulta le informazioni di routing. Se la destinazione si trova nella rete locale, il pacchetto può essere inviato direttamente attraverso l’interfaccia corretta. Se invece la destinazione è fuori dalla rete locale, il pacchetto viene mandato al gateway.

La rotta più importante, in molti sistemi, è la rotta predefinita. È quella che risponde alla domanda: “dove mando tutto ciò per cui non ho una regola più specifica?”.

Su un computer personale questa configurazione è spesso semplice. Su un server può diventare molto più articolata, soprattutto se ci sono più interfacce, reti private, reti pubbliche, VPN, container, bridge o rotte statiche.

Il comando ip route permette di osservare le rotte configurate.

Se IP e DNS sembrano corretti, ma il traffico non arriva dove dovrebbe, il routing è uno dei livelli da controllare.

Il percorso di una richiesta web

Mettiamo insieme i pezzi con un esempio semplice: aprire un sito web.

Scriviamo un indirizzo nel browser. Il browser deve prima capire a quale IP corrisponde quel nome, quindi entra in gioco il DNS. Poi apre un socket per comunicare con il server remoto, spesso sulla porta 443 se il sito usa HTTPS.

Il kernel prende i dati, li passa attraverso lo stack TCP/IP, decide la rotta, sceglie l’interfaccia corretta e invia i pacchetti usando il driver della scheda di rete.

I pacchetti attraversano il router e le reti intermedie, raggiungono il server, il server risponde e il percorso inverso riporta i dati al nostro computer.

Noi vediamo una pagina caricata nel browser. Sotto, però, stanno lavorando molti livelli: browser, DNS, socket, TCP/IP, routing, interfaccia, driver, hardware e server remoto.

Questa è la logica che rende la rete potente, ma anche apparentemente complessa.

Netfilter e firewall Linux

Quando parliamo di firewall Linux, dobbiamo capire che non stiamo parlando solo di un programma grafico o di un pulsante “attiva/disattiva”.

Alla base c’è il kernel, con infrastrutture come netfilter.

Netfilter permette al kernel di intercettare, filtrare, modificare o decidere il destino dei pacchetti. Gli strumenti in user space, come iptables o nftables, servono a configurare regole. Ma il controllo effettivo del traffico avviene nel percorso dei pacchetti all’interno del kernel.

Un firewall può permettere o bloccare traffico in base a indirizzo IP, porta, protocollo, interfaccia e stato della connessione.

Il punto più importante è questo: un firewall non serve semplicemente a “bloccare tutto”. Serve a permettere ciò che è necessario e bloccare ciò che non deve essere esposto.

Su un server web può avere senso permettere HTTP e HTTPS. Su un server amministrato via SSH può avere senso permettere l’accesso SSH solo da indirizzi specifici. Su un computer personale può avere senso bloccare connessioni in ingresso non richieste.

La logica è molto simile a quella dei permessi sui file: non si apre tutto a tutti, si concede solo ciò che serve davvero.

Servizi e porte aperte

Un altro punto importante è il rapporto tra servizi e porte aperte.

Un servizio può essere attivo e mettersi in ascolto su una porta. Per esempio, un server web può ascoltare sulle porte 80 e 443. Un server SSH può ascoltare sulla porta 22. Un database può ascoltare su una porta specifica.

Ma il fatto che un servizio sia in ascolto non significa automaticamente che sia raggiungibile da ovunque.

Potrebbe ascoltare solo su localhost. Potrebbe essere limitato a una interfaccia privata. Potrebbe essere bloccato dal firewall. Potrebbe essere raggiungibile solo tramite VPN. Oppure potrebbe essere esposto pubblicamente.

Per questo, quando si controlla un servizio, bisogna distinguere più livelli: il processo è attivo? La porta è in ascolto? Sta ascoltando sull’indirizzo corretto? Il firewall permette il traffico? La rete consente di raggiungerlo? L’applicazione risponde davvero?

Questo approccio è fondamentale nel lavoro quotidiano su sistemi Linux.

Comandi utili: ip, ping, ss e curl

Nel video abbiamo citato alcuni comandi senza fare una demo pesante.

ip serve a osservare e configurare interfacce, indirizzi e rotte. È uno degli strumenti principali per leggere la configurazione di rete.

ping serve a verificare una raggiungibilità di base. Non dimostra tutto, perché può essere bloccato o non rappresentare il comportamento di un servizio applicativo, ma resta utile come primo controllo.

ss permette di vedere socket, porte in ascolto e connessioni attive. È molto utile per capire se un servizio sta davvero ascoltando.

curl consente di fare richieste verso servizi, soprattutto HTTP e HTTPS. È utilissimo per verificare se un endpoint risponde, se un server web restituisce una risposta o se una richiesta fallisce.

La cosa importante non è usare questi comandi a caso. La cosa importante è sapere quale domanda stiamo facendo.

ip: com’è configurata la rete? ping: riesco a raggiungere qualcosa? ss: cosa sta ascoltando o comunicando? curl: il servizio applicativo risponde?

Una diagnosi mentale della rete Linux

Quando qualcosa non funziona, conviene evitare il panico e seguire una diagnosi a livelli.

Prima domanda: l’interfaccia esiste? Seconda: è attiva? Terza: ha un indirizzo IP? Quarta: il gateway è configurato? Quinta: la rotta predefinita è corretta? Sesta: riesco a raggiungere il gateway? Settima: riesco a raggiungere un IP esterno? Ottava: il DNS risolve i nomi? Nona: la porta del servizio è in ascolto? Decima: il firewall permette il traffico? Undicesima: l’applicazione risponde davvero?

Questa sequenza non risolve automaticamente ogni problema, ma evita di confondere livelli diversi.

Se il DNS non funziona, non ha senso modificare subito il firewall. Se il servizio non è in ascolto, non ha senso accusare il gateway. Se l’interfaccia non ha IP, non ha senso partire da curl.

La rete Linux è più semplice quando impariamo a separare i livelli.

Perché Linux è così importante nel networking

Linux è dominante nei server e nel networking perché offre controllo, stabilità e flessibilità.

Può funzionare su un piccolo dispositivo, su un server fisico, su una macchina virtuale, in un container, in un router, in un firewall, in un ambiente cloud o in un cluster Kubernetes.

Il suo stack di rete è potente. Il suo modello a livelli è solido. Gli strumenti sono scriptabili e automatizzabili. Le configurazioni possono essere gestite da file, comandi, strumenti DevOps e sistemi di orchestrazione.

Linux può fare da server web, database, reverse proxy, firewall, router, nodo cloud, host di container, appliance di sicurezza o sistema embedded.

Non è sempre semplice, ma è estremamente controllabile.

Ed è proprio questo controllo che lo rende così importante nelle infrastrutture moderne.

Rete e sicurezza

La rete è anche un tema di sicurezza.

Quando un sistema è collegato alla rete, può comunicare, ma può anche essere raggiunto. Se espone servizi, quei servizi diventano potenziali punti di ingresso.

Un server SSH, un server web, un database, una dashboard di amministrazione o un servizio interno devono essere gestiti con attenzione.

Qui tornano molti concetti già visti nella serie Capire Linux.

Un servizio è un processo. Un processo gira con un certo utente. I file hanno permessi. Le configurazioni stanno nel filesystem. I log aiutano a capire cosa succede. Il firewall limita chi può accedere.

La sicurezza Linux non è una singola funzione. È una combinazione di isolamento, permessi, configurazioni corrette, servizi gestiti bene, aggiornamenti, firewall e osservazione del sistema.

Cosa ricordare davvero

La rete su Linux non è un solo elemento.

È una catena composta da hardware, driver, interfacce, indirizzi IP, gateway, DNS, socket, porte, routing, firewall, servizi e applicazioni.

Quando qualcosa non funziona, bisogna chiedersi a quale livello si trova il problema.

L’interfaccia esiste? Ha un IP? Il gateway è corretto? Il DNS risolve i nomi? Il servizio è in ascolto? La porta è raggiungibile? Il firewall permette il traffico? L’applicazione risponde?

Questa è la mentalità corretta per iniziare a capire davvero il networking Linux.

I comandi sono importanti, ma non sono il punto di partenza. Il punto di partenza è la mappa mentale.

Quando capisci la mappa, comandi come ip, ping, ss e curl diventano strumenti per osservare il sistema, non formule da copiare senza capire.

Ed è proprio questo l’obiettivo della serie Capire Linux: trasformare Linux da insieme di parole tecniche a sistema leggibile, ordinato e comprensibile.