DHCP, DNS, TCP, UDP e servizi di rete: come configurare, osservare e capire il traffico
In questa lezione colleghiamo configurazione e analisi: da DHCP e DNS fino a TCP e UDP, imparando non solo a far funzionare un servizio, ma soprattutto a leggere le comunicazioni che attraversano la rete.
1. Introduzione: quando una rete diventa un servizio
Nelle lezioni precedenti abbiamo lavorato soprattutto sulla connettività: indirizzi IP, VLAN, STP, routing e NAT. Ma una rete funzionante non significa ancora che sia una rete realmente utilizzabile dagli utenti.
Quando un PC viene collegato a una rete aziendale, infatti, ci aspettiamo che possa ricevere automaticamente una configurazione IP, raggiungere un server utilizzando un nome comprensibile e comunicare con le applicazioni attraverso protocolli adatti al tipo di servizio.
È qui che entrano in gioco DHCP, DNS, TCP e UDP. Sono concetti differenti, ma nel lavoro quotidiano del network engineer si incontrano continuamente nello stesso flusso operativo.
DHCP fornisce automaticamente ai client parametri di configurazione IP. DNS permette di associare nomi a informazioni di rete, in particolare indirizzi IP. TCP e UDP sono protocolli di trasporto che permettono alle applicazioni di comunicare utilizzando le porte.
Prova a non studiare questi quattro argomenti come capitoli separati. Immagina un PC appena acceso: prima deve ottenere una configurazione, poi deve poter risolvere un nome e infine deve comunicare con un'applicazione. Questo collegamento rende molto più facile ricordare la teoria.
2. DHCP: configurare automaticamente gli host
Configurare manualmente ogni PC di una rete è possibile, ma diventa rapidamente poco pratico. In una rete con decine, centinaia o migliaia di dispositivi servono automazione, controllo e riduzione degli errori.
DHCP — Dynamic Host Configuration Protocol permette a un client di ottenere automaticamente informazioni come indirizzo IP, subnet mask, default gateway e, normalmente, server DNS.
Richiede configurazione
Il dispositivo non possiede ancora una configurazione IPv4 valida e cerca un server DHCP.
Assegna parametri
Il server dispone di un pool e propone una configurazione secondo le proprie regole.
2.1 Discover, Offer, Request, ACK
La sequenza didatticamente più importante è spesso chiamata DORA: Discover, Offer, Request, ACK.
- DHCP Discover: il client cerca un server DHCP.
- DHCP Offer: un server propone una configurazione.
- DHCP Request: il client comunica quale proposta intende accettare.
- DHCP ACK: il server conferma l'assegnazione.
La sequenza DORA descrive il modello operativo tipico, ma non significa che ogni singolo rinnovo di lease debba ripetere esattamente la stessa sequenza iniziale. Durante il ciclo di vita della configurazione il client può rinnovare il lease secondo le procedure DHCP previste.
2.2 Lease e rinnovo
Un indirizzo assegnato tramite DHCP è normalmente associato a un lease, cioè a un periodo durante il quale il client può utilizzare quella configurazione.
Il concetto è importante perché il server non deve considerare per sempre occupato un indirizzo che apparteneva a un dispositivo ormai scollegato dalla rete. Il lease permette di gestire dinamicamente il pool di indirizzi.
2.3 Reservation
Una reservation permette di associare un determinato client a un determinato indirizzo, normalmente utilizzando un identificativo come il MAC address.
È utile quando vogliamo che un dispositivo continui a utilizzare una configurazione assegnata dal DHCP, mantenendo però la gestione centralizzata del servizio.
Immagina una stampante di rete. Non vuoi necessariamente configurarle manualmente l'IP sul dispositivo, ma vuoi anche evitare che l'indirizzo cambi in modo imprevedibile. Una reservation DHCP può essere una soluzione pratica.
3. DNS: trasformare nomi in indirizzi
Gli esseri umani preferiscono lavorare con nomi come server.azienda.local o www.example.com. Le comunicazioni IP, invece, richiedono indirizzi.
Il DNS — Domain Name System realizza questa associazione attraverso un sistema distribuito e gerarchico.
Il DNS consente di interrogare un sistema di nomi per ottenere informazioni associate a un dominio o a un hostname. Nel caso più comune, la domanda è: “Quale indirizzo IP corrisponde a questo nome?”
3.1 Record A, AAAA, CNAME e MX
| Record | Funzione | Esempio concettuale |
|---|---|---|
| A | Associa un nome a un indirizzo IPv4 | server → 192.168.10.20 |
| AAAA | Associa un nome a un indirizzo IPv6 | server → 2001:db8::20 |
| CNAME | Alias di un altro nome DNS | www → webserver |
| MX | Indica i server incaricati della posta del dominio | mail → mail.example.com |
Una distinzione importante: CNAME non significa “indirizzo IP alternativo”. Un CNAME indica un altro nome, che deve poi essere risolto secondo le regole DNS.
3.2 La gerarchia DNS
Il DNS non è un unico grande database centrale. È organizzato gerarchicamente.
Quando risolviamo un nome, il sistema DNS può coinvolgere diversi livelli fino a raggiungere una risposta autorevole o una risposta presente in cache.
Quando studi DNS, pensa a una rubrica telefonica distribuita. Il nome è ciò che vuoi ricordare; il dato associato è ciò che serve alla rete. Questa analogia non spiega tutto il DNS, ma aiuta a fissare il concetto fondamentale.
4. Porte e servizi: dove arrivano i dati
Conoscere IP e protocolli non basta. Quando più applicazioni utilizzano contemporaneamente la stessa macchina, occorre distinguere i diversi flussi.
Qui entrano in gioco le porte di trasporto. Una comunicazione può essere descritta, in modo semplificato, attraverso indirizzo IP sorgente, porta sorgente, indirizzo IP destinazione e porta destinazione.
La porta 443 è comunemente associata a HTTPS, mentre il numero di porta sorgente può essere scelto dinamicamente dal client. L'obiettivo didattico è capire che IP identifica gli endpoint a livello di rete, mentre le porte permettono di distinguere le comunicazioni tra applicazioni.
5. TCP: affidabilità e handshake
TCP — Transmission Control Protocol è orientato alla connessione. Prima di trasferire i dati applicativi viene stabilito un rapporto tra i due endpoint attraverso il three-way handshake.
Richiesta di apertura
Il client avvia la fase di instaurazione della connessione.
Risposta
Il destinatario conferma e comunica i propri parametri iniziali.
Conferma
Il client conferma la ricezione e la connessione può procedere.
TCP fornisce meccanismi per confermare la ricezione, gestire la ritrasmissione e mantenere un flusso affidabile. Questo comporta maggiore complessità rispetto a UDP.
Quando un'applicazione ha bisogno di un trasferimento affidabile, come una comunicazione web basata su TCP, la possibilità di rilevare perdite e ritrasmettere i dati è un vantaggio importante.
6. UDP: semplicità e velocità
UDP — User Datagram Protocol è connectionless. Non stabilisce una connessione TCP e non offre lo stesso insieme di meccanismi di affidabilità.
Questo non significa che UDP sia “peggiore”. Significa che delega maggiori responsabilità all'applicazione oppure accetta una modalità di comunicazione nella quale semplicità e rapidità sono più importanti della ritrasmissione gestita dal protocollo di trasporto.
UDP non garantisce la consegna come TCP. Un'applicazione che usa UDP può comunque implementare propri meccanismi di controllo, se ne ha bisogno.
UDP è frequentemente utilizzato in scenari nei quali il tempo di risposta è importante e l'applicazione può gestire direttamente gli aspetti necessari al proprio servizio.
7. TCP vs UDP: come scegliere
| Caratteristica | TCP | UDP |
|---|---|---|
| Tipo | Connection-oriented | Connectionless |
| Handshake | Three-way handshake | Non usa il three-way handshake TCP |
| Affidabilità | Meccanismi di conferma e ritrasmissione | Non offre la stessa garanzia di consegna |
| Overhead | Maggiore | Minore |
| Porte | Sì | Sì |
| Scelta | Quando l'affidabilità del flusso è importante | Quando semplicità, rapidità o caratteristiche applicative lo rendono adatto |
Non dire semplicemente “TCP è lento e UDP è veloce”. È una semplificazione eccessiva. La scelta del protocollo dipende dai requisiti dell'applicazione, dal modello di comunicazione e dai meccanismi che l'applicazione stessa utilizza.
8. Dalla configurazione alla cattura: leggere il traffico
Fino a questo punto abbiamo descritto i protocolli. Ora facciamo un passo in più: impariamo a riconoscerli osservando i pacchetti.
Uno strumento come Wireshark permette di catturare e analizzare il traffico reale. L'obiettivo didattico non è imparare a leggere ogni singolo campo del protocollo, ma imparare a rispondere a domande tecniche a partire dalle evidenze.
Cerca DORA
Individua Discover, Offer, Request e ACK e collega i messaggi alla configurazione del client.
Cerca la domanda
Individua la query DNS e la risposta, quindi osserva quale record viene restituito.
Cerca il handshake
Riconosci SYN, SYN/ACK e ACK e segui il flusso della connessione.
Osserva il datagramma
Confronta il comportamento di UDP con quello di TCP senza attribuirgli automaticamente caratteristiche che non possiede.
Quando ti viene data una cattura, non partire dal dettaglio. Parti dalla domanda: “Che cosa sta succedendo nella rete?” Poi cerca gli indizi che permettono di ricostruire la sequenza degli eventi.
9. Un flusso completo: PC → DHCP → DNS → Server
Mettiamo insieme i concetti della lezione.
Un client potrebbe prima ottenere la propria configurazione tramite DHCP. Successivamente potrebbe chiedere al DNS l'indirizzo associato al nome del server. Una volta ottenuto l'indirizzo, l'applicazione può aprire una comunicazione verso il server utilizzando TCP oppure UDP, a seconda del servizio.
Se ping server funziona ma nslookup server fallisce, non concludere immediatamente che “la rete non funziona”. Il ping potrebbe utilizzare un indirizzo già noto o una risoluzione differente, mentre nslookup interroga esplicitamente il DNS. La domanda corretta è: quale componente del percorso sta fallendo?
10. Casi reali ed errori comuni
Errore 1 — DHCP non assegna l'indirizzo
Possibili cause: server DHCP non raggiungibile, pool esaurito, configurazione errata, VLAN errata oppure problema di relay quando client e server si trovano su reti diverse.
Errore 2 — Il client riceve IP ma non risolve i nomi
Qui la connettività IP può essere presente mentre il problema riguarda il DNS. È una distinzione fondamentale nel troubleshooting.
Errore 3 — Confondere DNS con ping
ping verifica una forma di raggiungibilità ICMP verso un indirizzo o, a seconda del sistema, può prima richiedere una risoluzione del nome. nslookup è invece uno strumento specifico per interrogare il DNS. Sono strumenti diversi e rispondono a domande diverse.
Errore 4 — “UDP non è affidabile quindi non serve”
UDP è utilizzato proprio perché offre un modello più semplice. La scelta corretta dipende dal servizio e dai requisiti applicativi.
Errore 5 — Guardare una cattura senza ricostruire la sequenza
Una cattura non è una raccolta di pacchetti isolati. È una storia temporale. Devi cercare l'ordine degli eventi e collegare i pacchetti alle azioni dell'utente e dei dispositivi.
Non utilizzare l'AI per chiedere “dimmi cosa significa questo pacchetto” senza fornire contesto. Una singola riga di cattura raramente basta per spiegare un problema. Fornisci almeno protocollo, indirizzi, porte, sequenza temporale e sintomo osservato.
11. Troubleshooting con AI e Fault Injection
In questa lezione introduciamo un modo più maturo di utilizzare l'AI nel troubleshooting. L'obiettivo non è ottenere una risposta immediata, ma usare l'AI come assistente di analisi.
Il metodo rimane quello utilizzato nelle lezioni precedenti:
11.1 Fault Injection: DHCP
Possiamo introdurre un fault come un pool DHCP errato, un servizio non attivo oppure una configurazione che impedisce al client di raggiungere il server.
L'obiettivo non è indovinare il fault, ma partire dal sintomo: “Il PC non riceve una configurazione IP valida.”
11.2 Fault Injection: DNS
Possiamo modificare il DNS configurato sul client oppure utilizzare un server DNS non raggiungibile. Il sintomo potrebbe essere: “Il server risponde al ping IP ma il nome non viene risolto.”
11.3 Fault Injection: TCP
Una cattura può mostrare un SYN senza la risposta SYN/ACK attesa. A quel punto bisogna formulare ipotesi: servizio non disponibile, porta filtrata, percorso interrotto o altro problema.
11.4 Fault Injection: UDP
La diagnostica deve essere diversa: non possiamo cercare automaticamente un handshake TCP che UDP non utilizza. Bisogna osservare il comportamento del servizio e le eventuali risposte dell'applicazione.
La qualità del prompt dipende dalla qualità delle evidenze. Se scrivi “DNS non funziona”, hai già trasformato un sintomo in una conclusione. Meglio scrivere: “nslookup restituisce timeout, mentre il ping verso il gateway funziona”. In questo modo l'AI può aiutarti a ragionare senza partire da un presupposto.
11.5 Prompt completo per troubleshooting con AI
11.6 Prompt per leggere una cattura Wireshark
12. Ponte con la parte pratica
Nel laboratorio costruiremo un piccolo scenario nel quale il client dovrà ottenere automaticamente la configurazione, utilizzare un DNS locale e raggiungere un server.
La sequenza sarà:
Configuro
Il client riceve automaticamente i parametri di rete.
Risolvo
Il nome del server viene associato al relativo indirizzo.
Osservo
Con Wireshark ricostruiamo ciò che è realmente avvenuto sulla rete.
🚀 Dalla teoria alla pratica
Accedi alla repository ufficiale GitHub del corso per scaricare il file del laboratorio pratico in formato .md.
Troverai gli esercizi per configurare DHCP e DNS, verificare la comunicazione con il server e analizzare DHCP, DNS, TCP e UDP attraverso le catture di traffico.
13. Riepilogo e autoverifica
🔬 Domande finali
- Perché DHCP usa una sequenza di messaggi invece di assegnare semplicemente un IP?
- Che differenza c'è tra un record A e un record AAAA?
- Perché un CNAME non è semplicemente un secondo indirizzo IP?
- Quali tre messaggi compongono il three-way handshake TCP?
- Perché UDP non deve essere considerato semplicemente “TCP senza affidabilità”?
- Quali pacchetti cercheresti in una cattura per capire se un client sta ottenendo un IP tramite DHCP?
- Se il ping verso un server funziona ma nslookup va in timeout, quale componente indagheresti per primo e perché?
- Quali evidenze inseriresti in un prompt AI per chiedere una diagnosi affidabile?
📚 Prossimo passo — Lezione 9
Nella prossima lezione porteremo il ragionamento sui servizi verso la rete wireless e la sicurezza: configurazione Wi-Fi, autenticazione, gestione sicura degli apparati e accesso amministrativo tramite SSH.