📡 Sistemi e Reti
2024 — Sessione Ordinaria
Avanzato
Soluzione completa
Rete regionale in fibra per la sanità digitale
FSE regionale, piano /28 per strutture private convenzionate, CPE managed, IPSec VPN, GDPR. Tutte e 4 le domande della seconda parte.
Prima Parte
Traccia originale — Ministero dell’Istruzione
Prima e Seconda Parte · Sessione Ordinaria 2024
// testo ufficiale
Riportato per comodità di consultazione.START
Lettura e Analisi della Traccia
Requisiti · Vincoli · Output richiesti
Tipo di infrastruttura
Rete WAN regionale in fibra ottica con gestione centralizzata da parte di una società pubblica. Non è una rete aziendale classica: è una rete multi-tenant che connette migliaia di siti eterogenei verso un unico hub (il data center regionale).
Requisiti identificati
- ~2.000 strutture sanitarie private convenzionate da connettere (con possibili incrementi)
- Blocco assegnato:
10.100.0.0/16 - Minimo 8 indirizzi complessivi per struttura
- Accesso esclusivo verso il data center — nessun accesso a Internet e nessuna comunicazione inter-struttura
- La struttura privata ha già una LAN interna propria
- Il CPE è fornito, configurato e controllato da remoto dalla società regionale
- Dati sanitari sensibili → GDPR + NIS2 applicabili
Output richiesti dalla traccia
- Schema grafico infrastruttura pre-esistente + evoluzione
- Specifiche hardware CPE con configurazione IP delle porte
- Dettagli di integrazione con la LAN pre-esistente
- Misure di sicurezza e schedulazione trasferimenti
- Quattro quesiti separati nella seconda parte
// decisione chiave
La natura del progetto richiede un approccio zero-trust per le strutture private: ogni CPE deve vedere solo il datacenter, mai le altre strutture. Questo si implementa a livello di routing (nessuna rotta verso altre /16), ACL sul backbone, e tunnel VPN con endpoint autorizzato esclusivamente verso il data center.01
Quesito 1
Topologia hub-and-spoke · Evoluzione rete regionale
Architettura pre-esistente
La rete regionale segue una topologia hub-and-spoke: il data center regionale è l’hub centrale. Nello schema seguente è indicato l’indirizzo del server FSE (Fascicolo Sanitaro Elettronico); tutte le strutture collegate (enti locali, scuole, strutture sanitarie pubbliche) sono spoke che parlano solo con l’hub, mai tra loro. Ogni tipologia di struttura è separata in una propria sottorete /16 ricavata dal piano 10.0.0.0/8.
Schema Topologico 1 — Visione generale
// topologia hub-and-spoke · rete regionale in fibra
Piano di indirizzamento regionale (ipotesi)
| Sottorete | Assegnataria | Note |
|---|---|---|
| 10.1.0.0/16 | Data center regionale | Hub FSE |
| 10.10.0.0/16 | Enti locali | Comuni, Province |
| 10.20.0.0/16 | Scuole | Istituti scolastici |
| 10.50.0.0/16 | Strutture sanitarie pubbliche | OSP, ASL, RSA |
| 10.100.0.0/16 | Strutture priv. conv. (nuovo) | Solo accesso verso DC |
// motivazione architettura
La topologia hub-and-spoke è la scelta naturale per una rete multi-tenant con un unico punto di raccolta (il FSE). Ogni spoke può raggiungere solo l’hub: non è necessaria comunicazione laterale tra strutture, e questa proprietà semplifica enormemente la sicurezza.Evoluzione della rete – Scelta della dimensione di sottorete
Il testo richiede un minimo di 8 indirizzi complessivi per struttura. Le opzioni sono:
| Prefisso | IP totali | Host utili | Subnet in /16 | Scelta |
|---|---|---|---|---|
| /29 | 8 | 6 | 8.192 | Soddisfa il minimo ma è troppo limitante in pratica |
| /28 | 16 | 14 | 4.096 | ✓ Scelta adottata |
| /27 | 32 | 30 | 2.048 | Abbondante ma spreco eccessivo con 2000 strutture |
// motivazione /28
Una struttura sanitaria privata dispone realisticamente di: PC amministrativi (2–3), workstation mediche (2–4), apparecchiature diagnostiche connesse (ECG, ecografo – 2–4), stampanti di rete (1–2), server locale o NAS (1), tablet/portatili medici (2–3). Totale stimato: 10–17 dispositivi. Il /29 (6 host) sarebbe insufficiente. Il /28 (14 host) è adeguato e le 4.096 subnet disponibili coprono ampiamente le ~2.000 strutture con margine del 100% per crescite future.Schema di allocazione sequenziale
| Struttura | Rete | Gateway (backbone) | CPE WAN | Host disponibili | Broadcast |
|---|---|---|---|---|---|
| 001 | 10.100.0.0/28 | 10.100.0.1 | 10.100.0.2 | .3 → .14 | 10.100.0.15 |
| 002 | 10.100.0.16/28 | 10.100.0.17 | 10.100.0.18 | .19 → .30 | 10.100.0.31 |
| … | … | … | … | … | … |
| 016 | 10.100.0.240/28 | 10.100.0.241 | 10.100.0.242 | .243 → .254 | 10.100.0.255 |
| 017 | 10.100.1.0/28 | 10.100.1.1 | 10.100.1.2 | .3 → .14 | 10.100.1.15 |
| … | … | … | … | … | … |
| 2000 | 10.100.124.224/28 | 10.100.124.225 | 10.100.124.226 | .227 → .238 | 10.100.124.239 |
| 2001–4096 | Riserva per crescita futura (fino a 10.100.255.240/28) | ||||
Formula allocazione: struttura N occupa la subnet con indirizzo di rete 10.100.((N-1)/16 floor).(((N-1) mod 16) × 16)/28
Schema Topologico 2 — CPE dettaglio connessione
// dettaglio singola struttura privata convenzionata · flusso dati
Isolamento inter-struttura — tre livelli
Il requisito di non-accessibilità reciproca tra strutture si implementa a tre livelli sovrapposti:
- Livello 1 — Routing CPE: ogni CPE riceve solo la rotta
10.1.0.0/16verso il data center. Nessuna rotta verso le sottoreti10.10.x.x,10.50.x.x, né verso altri /28 di10.100.x.x. - Livello 2 — ACL sul backbone: il router backbone applica un’ACL estesa che blocca esplicitamente il traffico laterale tra strutture private.
- Livello 3 — IPSec endpoint specifico: il tunnel VPN è configurato con endpoint autorizzato esclusivamente verso il data center, quindi anche a livello crittografico è impossibile raggiungere altre strutture.
ACL backbone — isolamento strutture private
ip access-list extended ISOLA-STRUTTURE-PRIVATE
! Permetti traffico da strutture private verso data center
permit ip 10.100.0.0 0.0.255.255 10.1.0.0 0.0.255.255
! Permetti traffico di ritorno (established)
permit tcp any any established
! Blocca traffico tra strutture private (inter-spoke)
deny ip 10.100.0.0 0.0.255.255 10.0.0.0 0.255.255.255
! Blocca accesso a Internet (no default route verso esterno)
deny ip 10.100.0.0 0.0.255.255 any
permit ip any any ! permetti traffico legittimo per gli altri spoke
02
Quesito 2
Hardware CPE · Servizi da configurare
Tipologia del dispositivo CPE
Ogni struttura privata riceve un router (CPE — Customer Premises Equipment) con supporto VPN hardware fondamentale per garantire routing veloce tra VLAN e tunnel crittografati ad alte prestazioni senza sovraccaricare la CPU principale. È gestito interamente dalla società regionale tramite accesso SSH remoto. La struttura privata non ha accesso alla configurazione del CPE.
Modello di riferimento: Cisco ISR 1111X o equivalente enterprise.
Specifiche hardware
| Componente | Specifica | Motivazione |
|---|---|---|
| Porta WAN | 1× GigE SFP/LC per fibra monomodale | Connessione diretta alla rete regionale in fibra |
| Porte LAN | 4× GigE RJ45 (switch integrato) | Collegamento alla rete interna della struttura |
| CPU/Crypto | Hardware AES accelerato (AES-NI) | Cifratura IPSec a line-rate senza collo di bottiglia |
| RAM | ≥4 GB DDR4 | Buffer per code di trasferimento dati |
| Storage | ≥8 GB Flash/SSD | Log, code locali, configurazioni |
| Backup WAN | Modulo 4G/LTE integrato (SIM) | Continuità in caso di guasto fibra |
| Alimentazione | Doppio alimentatore o batteria tampone | Alta disponibilità; strutture sanitarie |
Configurazione IP delle porte
CPE — struttura N (es. N=1)
! ── Porta WAN (verso rete regionale) ──────────────────────
interface GigabitEthernet0/0
description WAN-Regionale-Fibra
ip address 10.100.0.2 255.255.255.240 ! secondo IP del /28
ip nat outside
no shutdown! ── Porta LAN (verso rete interna struttura) ──────────────
interface GigabitEthernet0/1
description LAN-Struttura-Privata
ip address 192.168.100.1 255.255.255.0
ip nat inside
no shutdown! ── Rotta statica: solo verso il data center ──────────────
ip route 10.1.0.0 255.255.0.0 10.100.0.1
! Nessuna rotta verso altre 10.x.x.x → isolamento garantito
Servizi configurati sul CPE
| Servizio | Funzione |
|---|---|
| IPSec IKEv2 (AES-256-GCM) | Tunnel VPN cifrato verso data center. Autenticazione con certificati X.509 |
| NAT/PAT | Mascheramento rete interna struttura verso il /28 regionale assegnato |
| Stateful Firewall | Blocca tutto il traffico tranne quello verso il data center (whitelist) |
| Routing statico selettivo | Unica rotta: 10.1.0.0/16 → DC. No rotte verso altre /16 |
| DHCP Server | Assegnazione IP ai dispositivi medici della struttura (opzionale) |
| DNS Forwarder | Inoltro query verso resolver regionale autorevole |
| SSH Server | Gestione remota da parte della società regionale |
| SNMP v3 / NETCONF | Monitoraggio centralizzato, telemetria, gestione configurazione |
| Syslog (cifrato) | Invio log al SIEM regionale su TLS |
| NTP Client | Sincronizzazione oraria precisa (essenziale per audit log GDPR) |
| QoS | Priorità al traffico emergenze mediche su eventuali code |
| WAN Failover (LTE) | Switch automatico su 4G in caso di guasto fibra |
03
Quesito 3
Integrazione LAN pre-esistente · Connessione rete struttura · Apparati · Riconfigurazioni
Scenario ipotetico di partenza
La struttura privata dispone già di: uno switch managed (24 porte), un router/firewall per la navigazione Internet, indirizzi 192.168.1.0/24, workstation mediche, stampanti.
Approccio consigliato — CPE in parallel path (non-invasivo)
Il CPE viene connesso a una porta dello switch di distribuzione esistente, preferibilmente su una VLAN dedicata (VLAN 10 “FSE-Regionale”) per separare logicamente il traffico verso il data center dal traffico interno ordinario.
Interventi sugli apparati esistenti
1. Switch managed esistente:
- Creare VLAN 10 “FSE-Regionale”
- Configurare la porta connessa al CPE come access VLAN 10
- Configurare la porta uplink verso il router/firewall esistente come trunk (aggiungendo VLAN 10 alle VLAN permesse)
2. Router/firewall pre-esistente della struttura:
- Aggiungere una rotta statica: destinazione
10.1.0.0/16via gateway192.168.100.1(IP LAN del CPE) - In alternativa: configurare policy routing per inviare al CPE solo il traffico con destinazione
10.1.0.0/16 - Il resto del traffico (navigazione Internet, rete interna) continua a passare attraverso il router/firewall esistente invariato
3. Dispositivi medici e workstation (se necessario):
- Se il firewall gestisce il routing correttamente: nessuna modifica ai dispositivi finali
- In alternativa: aggiungere rotta statica persistente sul sistema operativo per
10.1.0.0/16
Caso senza switch managed
Se lo switch della struttura non supporta VLAN, il CPE viene inserito in cascata: il CPE usa una seconda interfaccia LAN (es. GigEth0/2) per collegarsi direttamente ai dispositivi che devono accedere al FSE, su una sottorete separata (192.168.100.0/24), mentre la LAN esistente rimane invariata.
// principio guida
L’approccio non-invasivo è preferibile in ambito sanitario: riduce i rischi di downtime su apparecchiature critiche e non richiede formazione del personale della struttura. La società regionale lavora solo sul CPE che controlla già.05
Quesito 4
Sicurezza e schedulazione trasferimenti · GDPR · IPSec · Cifratura · Scheduling
Sicurezza in transito
- TLS 1.3 per le connessioni applicative (API REST, portale web FSE)
- Split tunneling disabilitato: tutto il traffico verso il data center passa nel tunnel, nessuna deviazione possibile
- Nessun accesso diretto a Internet dalla sottorete
10.100.0.0/16
Sicurezza at-rest (data center)
- AES-256 per cifratura filesystem e database (TDE — Transparent Data Encryption)
- Immagini diagnostiche (DICOM) cifrate individualmente con chiave derivata dall’ID paziente
Controllo degli accessi
- RBAC (Role-Based Access Control): medico curante, medico specialista, infermiere, paziente, amministratore — ogni ruolo accede solo ai dati di competenza
- MFA obbligatoria per il personale sanitario
- SPID L2 / CIE 3.0 per i cittadini
- Audit log immutabile di tutti gli accessi (retention ≥5 anni per compliance GDPR), inviato a SIEM centralizzato
- GDPR: DPIA (Data Protection Impact Assessment) effettuata; DPO nominato; procedure per diritti dell’interessato (accesso, rettifica, cancellazione)
Schedulazione trasferimenti dati (ipotesi)
| Tipo dato | Dim. tipica | Modalità | Finestra |
|---|---|---|---|
| Referti testuali, prescrizioni | ~5–50 KB | Event-driven (push API) | Entro 1h dalla firma digitale |
| Immagini ECG, ECO, RX | 10–200 MB | Batch programmato | 01:00–05:00 ogni notte |
| TAC, RMN, PET | 200 MB – 3 GB | Batch programmato | 01:00–05:00 ogni notte |
| Video procedurali | >1 GB | Batch programmato | 01:00–05:00, weekend |
| Dati emergenza | Qualsiasi | Immediato, priorità massima | Real-time, coda separata |
Ogni record viene firmato digitalmente con la chiave del dispositivo medico generante e cifrato prima di essere immesso in coda. Il data center emette un ACK con checksum SHA-256 verificato per ogni record ricevuto. In caso di mancato ACK, il record rimane in coda locale e viene ritrasmesso con backoff esponenziale (retry: 1′ → 5′ → 30′ → alert IT).
END
Documentazione finale e riepilogo
Riepilogo scelte · Punti chiave relazione
Riepilogo scelte progettuali
| Aspetto | Scelta | Motivazione sintetica |
|---|---|---|
| Sottorete strutture private | 10.100.0.0/16 | Assegnata dal testo |
| Dimensione subnet per struttura | /28 (14 host utili) | Superiore al minimo /29; adeguata per dispositivi medici |
| N. subnet disponibili | 4.096 /28 | Doppio delle strutture previste — crescita coperta |
| Isolamento | ACL + routing + VPN endpoint | Tre livelli indipendenti di garanzia |
| CPE | Router L3 VPN managed | Gestito da remoto; hardware AES; LTE backup |
| VPN | IPSec IKEv2 AES-256-GCM | Dati sanitari sensibili; certificati X.509 |
| Cifratura at-rest | AES-256 TDE + HSM | Standard GDPR/NIS2 |
| Trasferimento immagini | Batch notturno 01–05 | Evita congestione rete diurna; finestra bassa utenza |
| Backup | 3-2-1 + RAID 6 + replica geografica | RPO ≈ 0, RTO < 4h |
// punti chiave per la relazione
- Il /28 ottimizza il rapporto tra disponibilità di indirizzi e crescita futura, rispettando ampiamente il requisito minimo di 8 IP complessivi
- L’isolamento a tre livelli garantisce che un compromesso di un singolo CPE non metta a rischio le altre strutture
- Il CPE managed è l’unico punto di contatto con la rete regionale: la struttura privata non può modificarne la configurazione
- La schedulazione notturna per le immagini diagnostiche bilancia il carico sulla rete in fibra e garantisce capacità sufficiente durante l’orario di lavoro
- GDPR richiede la cifratura sia in transito che at-rest per dati sanitari — entrambi i requisiti sono soddisfatti
Seconda Parte
I
Strategie contro malfunzionamenti e perdita dati
Store-and-forward · Replica · RAID · Backup 3-2-1
Livello CPE / struttura — connessione WAN
- Store-and-forward locale: il CPE mantiene una coda persistente cifrata (su storage locale) delle transazioni non ancora confermate dal data center. Se il collegamento fibra cade, i dati rimangono localmente finché la connessione non è ripristinata. La coda è durabile (sopravvive a riavvii del CPE).
- Connessione di backup LTE: in caso di guasto alla fibra, il traffico viene automaticamente rediretto sul modem 4G integrato tramite policy routing. Il failover è trasparente per le applicazioni mediche.
- Integrità dei record: ogni record viene taggato con hash SHA-256 alla generazione; il data center verifica l’hash all’arrivo e rifiuta qualsiasi record con checksum non corrispondente, richiedendo la ritrasmissione.
Livello applicativo — trasferimento
- Messaggistica durabile: utilizzo di un message broker con persistenza (Apache Kafka o RabbitMQ con durable queues). I messaggi non vengono eliminati dalla coda finché non sono confermati come scritti sul data center (acknowledgment esplicito).
- Transazioni ACID: le scritture sul database del data center usano transazioni atomiche con WAL (Write-Ahead Log). Un guasto durante la scrittura non lascia mai record parziali.
- Idempotenza: ogni record ha un ID univoco (UUID v4 + timestamp + ID struttura). Il data center deduplica in base all’ID, quindi ritrasmissioni non creano duplicati.
Livello data center — storage
- RAID 6: tolleranza a guasto simultaneo di 2 dischi. Adatto per NAS/SAN con molti dischi.
- Replica sincrona geografica: copia su sito secondario distante almeno 50 km. Modalità Active-Standby (o Active-Active per i servizi critici). RPO ≈ 0, RTO < 4h.
- Backup 3-2-1: 3 copie totali, su 2 media diversi, 1 off-site (nastri LTO o cloud immutabile). Backup giornaliero incrementale, settimanale completo. I backup sono cifrati.
- Test DR periodici: simulazione di ripristino completo almeno annuale, con misurazione effettiva di RPO e RTO documentata.
// principio chiave
Nessun singolo punto di fallimento deve causare perdita di dati. Le tre linee di difesa (coda locale CPE → messaggeria durabile → RAID + replica) garantiscono che anche in caso di guasto catastrofico al data center, i dati più recenti siano recuperabili dalla coda dei CPE.II
MFA per accesso al fascicolo sanitario elettronico
SPID · CIE 3.0 · eIDAS · Fattori di autenticazione
In Italia, l’accesso a servizi della Pubblica Amministrazione è regolato dal CAD (Codice dell’Amministrazione Digitale) e dal Regolamento europeo eIDAS. Per l’accesso al FSE sono disponibili tre strumenti di autenticazione qualificata:
SPID — Sistema Pubblico di Identità Digitale (Livello 2)
Il livello minimo obbligatorio per servizi sanitari. Flusso di autenticazione:
- Il cittadino accede al portale FSE e seleziona “Entra con SPID”
- Viene reindirizzato al proprio Identity Provider (PosteID, TIMID, Aruba, Namirial, ecc.)
- Inserisce username e password → primo fattore: conoscenza
- L’Identity Provider invia un OTP via SMS o app TOTP (Google Authenticator, Authy) → secondo fattore: possesso del dispositivo
- Inserisce l’OTP → token SAML2 o OIDC rilasciato → accesso FSE concesso
Sessione: token con scadenza breve (15–30 minuti); alla scadenza è richiesta la riautenticazione.
SPID Livello 3
Per operazioni particolarmente sensibili (es. delega a terzi, accesso a dati di salute mentale). Aggiunge un terzo fattore tramite dispositivo fisico certificato: chiavetta OTP hardware (FIDO2/WebAuthn) o biometria (impronta digitale, riconoscimento facciale) gestita dall’app del provider. Classificato come “alto” nel framework eIDAS.
CIE 3.0 — Carta di Identità Elettronica
Smart card contactless con chip PKI (crittografia asimmetrica). Flusso:
- Il cittadino avvicina la CIE al lettore NFC (smartphone Android/iOS o lettore USB-NFC)
- Il chip CIE esegue una sfida crittografica con il server di autenticazione, usando il certificato X.509 residente nel chip → fattore: possesso fisico della carta + identità verificata all’emissione
- Il cittadino inserisce il PIN della CIE (diverso dal PIN del bancomat) → fattore: conoscenza
- Autenticazione forte a 2 fattori completata. Classificato “alto” in eIDAS.
Confronto fattori
| Metodo | Fattore 1 | Fattore 2 | Fattore 3 | Livello eIDAS |
|---|---|---|---|---|
| SPID L2 | Password | OTP SMS/TOTP | — | Sostanziale |
| SPID L3 | Password | OTP hardware/app | Biometria | Alto |
| CIE 3.0 | CIE fisica (NFC) | PIN CIE | — | Alto |
// norma di riferimento
D.Lgs. 82/2005 (CAD), art. 64: le PA devono consentire l’accesso ai propri servizi tramite SPID, CIE o CNS. Per il FSE il livello minimo è SPID L2 (Livello di Garanzia 2 — LoA 2). I medici accedono con SPID L2 + OTP hardware per garantire non-ripudio delle prescrizioni.III
Configurazione NAT e port forwarding
Static PAT · ACL · Motivazioni
Scenario
- IP pubblico statico:
203.0.113.10/24(WAN) - Web server interno:
192.168.1.10 - LAN aziendale:
192.168.1.0/24 - Servizi da esporre: HTTP (80), HTTPS (443), SSH (22)
Tecnica: Static PAT (Port Address Translation statica)
Con un singolo IP pubblico e più servizi su porte diverse, l’unica soluzione è lo Static PAT (anche detto “port forwarding” o “server NAT”): il router mappa porte specifiche sull’IP pubblico alle porte corrispondenti del server interno.
Configurazione Cisco IOS — NAT + ACL
! ── Interfaccia WAN ────────────────────────────────────────
interface GigabitEthernet0/0
description WAN-Internet
ip address 203.0.113.10 255.255.255.0
ip nat outside
ip access-group ACL-WAN-IN in
no shutdown! ── Interfaccia LAN ────────────────────────────────────────
interface GigabitEthernet0/1
description LAN-Interna
ip address 192.168.1.1 255.255.255.0
ip nat inside
no shutdown! ── Static PAT — port forwarding verso web server ──────────
! HTTP: 203.0.113.10:80 → 192.168.1.10:80
ip nat inside source static tcp 192.168.1.10 80 203.0.113.10 80
! HTTPS: 203.0.113.10:443 → 192.168.1.10:443
ip nat inside source static tcp 192.168.1.10 443 203.0.113.10 443
! SSH: 203.0.113.10:22 → 192.168.1.10:22
ip nat inside source static tcp 192.168.1.10 22 203.0.113.10 22! ── NAT dinamico (PAT) per traffico uscente LAN → Internet ─
access-list 10 permit 192.168.1.0 0.0.0.255
ip nat inside source list 10 interface GigabitEthernet0/0 overload! ── ACL inbound WAN — filtra traffico in ingresso ──────────
ip access-list extended ACL-WAN-IN
permit tcp any host 203.0.113.10 eq 80
permit tcp any host 203.0.113.10 eq 443
permit tcp any host 203.0.113.10 eq 22
permit tcp any any established ! risposte a conn. uscenti
deny ip any any log ! blocca tutto il resto
Motivazioni
- Static PAT è l’unico meccanismo possibile con un singolo IP pubblico e più servizi su porte distinte. Senza di esso, tutte le connessioni in ingresso andrebbero “perse” perché il router non saprebbe a quale host interno inoltrarle.
permit tcp any any establishedè fondamentale: senza questa regola, le risposte alle connessioni avviate dalla LAN verso Internet verrebbero bloccate dall’ACL inbound.- Il
overloadnella NAT dinamica abilita il PAT: tutti i dispositivi LAN escono con lo stesso IP pubblico, distinti dalla porta TCP sorgente (NAPT). - Il
ip nat outsidesu GE0/0 eip nat insidesu GE0/1 sono obbligatori: IOS applica la traduzione NAT solo alle interfacce esplicitamente marcate.
// attenzione sicurezza SSH
SSH sulla porta 22 pubblica espone il server agli attacchi brute-force automatizzati. In produzione: spostare SSH su porta non standard (es. 2222) oppure limitare l’accesso SSH a specifici IP di origine con permit tcp host <IP-admin> host 203.0.113.10 eq 22 nell’ACL, sostituendo la regola generica.IV
Tre cause e metodologia di diagnosi
Bottom-up OSI · Strumenti · Comandi
Approccio: bottom-up per layer OSI. Si parte dalla verifica fisica (Layer 1) e si sale fino al layer applicativo (Layer 7), isolando il problema a ciascun livello prima di salire al successivo.
Causa 1 — Configurazione IP assente o errata (Layer 3)
Il dispositivo non ha ricevuto un indirizzo IP valido (DHCP fallito, conflitto IP, configurazione statica errata).
Strumenti e comandi:
Diagnosi — configurazione IP
Windows:
ipconfig /all → verifica IP, maschera, gateway, server DNS
ping 127.0.0.1 → verifica stack TCP/IP locale
ipconfig /release → rilascia IP DHCP
ipconfig /renew → richiede nuovo IP al server DHCPLinux:
ip a → mostra tutte le interfacce e indirizzi
ip route show → verifica tabella di routing e default gateway
dhclient -r eth0 → rilascia IP DHCP su eth0
dhclient eth0 → richiede nuovo IP DHCP
Segnali diagnostici: IP 169.254.x.x (APIPA) = il DHCP non ha risposto. IP 0.0.0.0 = nessuna configurazione. Se il server DHCP è giù, il problema è sul server o sulla rete LAN.
Causa 2 — Gateway non raggiungibile (Layer 2/3)
Il dispositivo ha un IP valido ma non comunica con il router/gateway. Possibili cause: cavo scollegato, switch con porta in stato down, VLAN errata, router in down o overcaricato.
Diagnosi — raggiungibilità gateway
ipconfig /all → recupera IP gateway (es. 192.168.1.1)
ping 192.168.1.1 → SE FALLISCE: problema fisico o router down
arp -a → verifica che il MAC del GW sia in cache ARP
tracert 8.8.8.8 → (Windows) dove si blocca il percorso?
traceroute 8.8.8.8 → (Linux) idem
Se ping al gateway funziona ma ping a 8.8.8.8 fallisce:
→ il router non ha connettività WAN (problema ISP o configurazione NAT)
Causa 3 — DNS non funzionante (Layer 7)
Il dispositivo raggiunge Internet a livello IP ma non risolve i nomi a dominio.
Diagnosi — risoluzione DNS
ping 8.8.8.8 → SE FUNZIONA: connettività IP OK
ping google.com → SE FALLISCE con IP OK: PROBLEMA DNS
nslookup google.com → verifica quale server DNS risponde e come
nslookup google.com 8.8.8.8 → test diretto con DNS Google
ipconfig /flushdns → svuota cache DNS locale
Interpretazione:
ping 8.8.8.8 OK + ping google.com FAIL → DNS server aziendale down
nslookup google.com 8.8.8.8 OK → il problema è solo il DNS interno
Soluzione rapida: impostare 8.8.8.8 come DNS primario temporaneo
// test discriminante fondamentale
Il comando ping 8.8.8.8 (IP numerico) vs ping google.com (nome) è il test cardine per separare immediatamente “problema di connettività IP” da “problema DNS”. Se il primo funziona e il secondo no, il problema è esclusivamente la risoluzione dei nomi — la rete funziona perfettamente.