Network Security, Intelligenza Artificiale e Troubleshooting: dalla diagnosi alla risoluzione
La lezione di sintesi del percorso Networking: collegare Layer 1, Layer 2, Layer 3, servizi e sicurezza attraverso una metodologia professionale di troubleshooting, utilizzando l'IA come supporto al ragionamento e non come semplice generatore di comandi.
1. Introduzione: dal comando al metodo
Questa è la lezione di sintesi del percorso. Abbiamo già lavorato su Ethernet, IPv4, IPv6, VLAN, trunk, STP, routing, NAT, DHCP, DNS, Wi-Fi, SSH, QoS e trasferimento di file. Ora il punto non è aggiungere un altro elenco di comandi: è imparare a mettere insieme le conoscenze quando una rete reale presenta un problema.
Nel lavoro di un tecnico di rete, il problema raramente si presenta dicendo quale configurazione è sbagliata. Arriva sotto forma di un sintomo: “un PC non naviga”, “un reparto non raggiunge il server”, “il VoIP è disturbato”, “il DHCP non assegna indirizzi”. Il compito professionale è trasformare quel sintomo in una sequenza di verifiche ripetibili.
Un buon troubleshooting non è una gara a indovinare il comando giusto. È un processo nel quale ogni comando deve rispondere a una domanda. Prima di digitare un comando, chiediti: che cosa voglio dimostrare o escludere?
2. Ripasso ragionato dei livelli
Cavi, porte, alimentazione, link, segnale e caratteristiche del mezzo trasmissivo.
Ethernet, MAC, VLAN, trunk, STP, EtherChannel e switching.
IPv4/IPv6, subnet, gateway, routing, NAT e comunicazione tra reti.
DHCP, DNS, TCP, UDP e servizi applicativi permettono alla rete di diventare utilizzabile dagli utenti e dalle applicazioni.
Autenticazione, segmentazione, accesso remoto sicuro, controllo del traffico e protezione dei servizi riducono il rischio operativo.
Se un PC non raggiunge un server, non partire automaticamente dal routing. Prima chiediti: il link è attivo? Il PC appartiene alla VLAN corretta? Ha un indirizzo IP coerente? Il gateway è raggiungibile? Il DNS è necessario per quel test? Il percorso esiste? Il servizio sul server risponde?
3. Layer 1: quando il problema è fisico
Un troubleshooting professionale parte dall'osservabile. Se una porta è down, non ha senso modificare subito il gateway o il DNS. Prima si verifica la connettività fisica e lo stato dell'interfaccia.
show interfaces status show interfaces show ip interface brief
Saltare il Layer 1 perché “il problema sembra IP”. Un cavo scollegato, una porta shutdown o un'interfaccia errata possono produrre sintomi che sembrano problemi di rete più complessi.
4. Layer 2: VLAN, trunk e switching
Al Layer 2 dobbiamo verificare appartenenza alla VLAN, stato delle porte, trunk e meccanismi di ridondanza. Una configurazione apparentemente corretta può fallire perché una sola porta access è nella VLAN sbagliata oppure perché una VLAN non attraversa un trunk.
show vlan brief show interfaces trunk show mac address-table show spanning-tree
Quando due host nella stessa rete IP non comunicano, verifica prima se sono davvero nello stesso dominio Layer 2 previsto dal progetto. L'indirizzo IP da solo non garantisce che il percorso Ethernet sia corretto.
5. Layer 3: IP, gateway e routing
Quando Layer 1 e Layer 2 sono coerenti, passiamo a indirizzamento e routing. Qui diventano fondamentali subnet mask, gateway predefinito e tabelle di routing.
show ip interface brief show ip route show arp ping <destinazione> traceroute <destinazione>
Se un PC raggiunge il proprio gateway ma non una rete remota, il problema non è necessariamente il PC. Occorre verificare il routing tra le reti e il percorso di ritorno.
6. Servizi: DHCP, DNS, TCP/UDP e NAT
Una rete può essere connessa e tuttavia sembrare “non funzionante” perché un servizio non risponde. DHCP assegna la configurazione agli host; DNS risolve nomi; TCP e UDP trasportano applicazioni; NAT modifica la rappresentazione degli indirizzi nei percorsi previsti.
“Il PC non apre il sito”.
DHCP, DNS, routing, NAT, TCP/UDP o servizio applicativo.
Per questo è importante distinguere un test di connettività IP da un test di risoluzione del nome e da un test del servizio applicativo.
7. Sicurezza: la rete deve anche essere affidabile
La sicurezza non è un blocco separato dal troubleshooting. VLAN, segmentazione, SSH, autenticazione e controllo degli accessi influenzano direttamente ciò che un dispositivo può raggiungere.
Un traffico che non passa non è automaticamente un guasto. Potrebbe essere un comportamento previsto da una policy di sicurezza. Il tecnico deve quindi distinguere tra malfunzionamento e blocco intenzionale.
Durante l'analisi bisogna evitare di disattivare una misura di sicurezza solo per “vedere se funziona”. Ogni modifica deve avere una motivazione, una verifica e, se possibile, una modalità di rollback.
8. La metodologia professionale di troubleshooting
La metodologia che useremo nel laboratorio finale è composta da otto passaggi:
La sequenza è importante: non dobbiamo saltare dalla definizione del problema direttamente alla modifica della configurazione.
9. Raccogliere evidenze prima di modificare
Una diagnosi di qualità si basa su dati. Prima di cambiare la configurazione, raccogliamo ciò che la rete ci sta già dicendo.
Collegamenti, VLAN, apparati, interfacce, percorsi e dipendenze.
Stato interfacce, VLAN, trunk, MAC, ARP, routing, NAT e configurazione corrente.
Prima di modificare una configurazione, salva l'output utile. Se la soluzione funziona, saprai perché; se peggiora il problema, potrai ricostruire ciò che è cambiato.
10. Troubleshooting con l'Intelligenza Artificiale
L'IA può diventare un ottimo assistente diagnostico, ma solo se riceve informazioni tecniche sufficienti. Un prompt come “il PC non funziona, cosa devo fare?” produce facilmente una lista generica di comandi.
Nel nostro metodo l'IA riceve topologia, sintomi, evidenze e ipotesi dello studente. Il suo compito è aiutare a ragionare sulle possibili cause e sulle verifiche, non sostituire il tecnico.
L'IA non deve essere usata semplicemente per chiedere “qual è il comando da usare?”. Deve essere utilizzata per costruire e verificare un ragionamento diagnostico basato sulle evidenze.
11. Come costruire un prompt diagnostico efficace
Un buon prompt deve fornire il contesto minimo necessario e imporre una metodologia verificabile.
Sei un assistente per il troubleshooting di una rete Cisco. Non inventare dati mancanti e non modificare direttamente la configurazione. TOPOLOGIA: [descrizione della rete] SINTOMO: [che cosa non funziona] EVIDENZE RACCOLTE: [output dei comandi, indirizzi IP, VLAN, routing, test] MIA IPOTESI: [ipotesi formulata dallo studente] Analizza le informazioni e: 1. separa fatti, ipotesi e conclusioni; 2. proponi le possibili cause ordinate per probabilità; 3. indica quale verifica effettuare per prima e perché; 4. specifica comando, risultato atteso e interpretazione; 5. usa un test alla volta; 6. dopo ogni risultato aggiorna il ragionamento; 7. indica quando un'ipotesi è confermata o smentita; 8. proponi la modifica solo dopo aver raccolto evidenze sufficienti; 9. indica come verificare la soluzione; 10. chiudi con una breve documentazione del guasto. Non fornire una soluzione finale senza spiegare il percorso diagnostico.
12. Fault Injection: più guasti contemporaneamente
Nel laboratorio finale introdurremo una difficoltà più vicina al mondo reale: la rete può contenere più guasti contemporaneamente. Questo impedisce di risolvere il problema semplicemente riconoscendo un singolo errore.
VLAN errata o trunk configurato male.
Gateway o routing errato.
DHCP o DNS non funzionante.
VLAN 20 assegnata male + gateway errato + DNS non raggiungibile + rotta mancante. Lo studente deve individuare i guasti uno alla volta senza confondere sintomi secondari e causa principale.
13. Caso ragionato: VLAN 20 non raggiunge il server
Scenario: il PC della VLAN 20 non riesce a raggiungere il server, mentre i PC della VLAN 10 funzionano.
La prima reazione non dovrebbe essere “controllo il router”. Costruiamo invece una sequenza di domande:
- Il PC ha ricevuto un indirizzo IP coerente?
- La porta dello switch appartiene alla VLAN 20?
- La VLAN 20 esiste sullo switch?
- Il trunk trasporta la VLAN 20?
- Il gateway della VLAN 20 è corretto?
- Il router o switch Layer 3 possiede l'interfaccia/SVI corretta?
- Esiste una rotta verso la rete del server?
- Il DNS sta introducendo un sintomo aggiuntivo?
- Il server risponde all'indirizzo IP?
La stessa frase “non raggiunge il server” può nascondere problemi completamente diversi. Il troubleshooting serve proprio a trasformare un sintomo generico in una causa tecnica dimostrabile.
14. Errori comuni durante il troubleshooting
Vedere un sintomo e dichiarare subito la causa senza una verifica.
Se modifichi cinque configurazioni contemporaneamente, non sai quale modifica abbia risolto il problema.
Un comando può essere sintatticamente corretto ma inadatto alla topologia o al problema.
Un DNS irraggiungibile può sembrare un problema Internet; un gateway errato può produrre errori applicativi.
15. Ponte con il laboratorio finale
Nel laboratorio finale ogni gruppo riceverà una rete intenzionalmente compromessa. Potranno essere presenti contemporaneamente VLAN errate, trunk configurati male, gateway errati, problemi DHCP/DNS, routing incompleto o NAT non funzionante.
L'obiettivo non sarà semplicemente “far tornare il ping”. Gli studenti dovranno dimostrare la causa, raccogliere le evidenze, utilizzare l'IA in modo strutturato e documentare la soluzione.
🚀 Pronto per il laboratorio finale?
Accedi alla repository ufficiale GitHub del corso per scaricare il laboratorio della Lezione 11. Troverai una rete con più fault, una metodologia guidata di diagnosi, attività di Fault Injection e una prova finale in cui l'IA diventa un assistente al troubleshooting.
Laboratorio lezione 11 →Networking security16. Riepilogo e autoverifica
1. Perché non è corretto chiedere subito all'IA “qual è il comando”?
2. Quali evidenze raccoglieresti davanti a un problema di raggiungibilità?
3. Come distingueresti un problema DNS da un problema IP?
4. Perché un singolo sintomo può avere più cause?
5. Qual è la differenza tra risolvere un problema e documentarlo?
🏁 Verso la prova finale
La Lezione 11 chiude il percorso operativo: dalla configurazione dei singoli protocolli alla capacità di affrontare una rete reale, formulare ipotesi, usare strumenti diagnostici, collaborare con l'IA e motivare ogni decisione tecnica.