SOLUZIONE GUIDATA

La prova assegnata (Sistemi e Reti — sessione ordinaria 2026, indirizzo Informatica). Tienila aperta qui mentre segui lo svolgimento.

Prima cosa: riscrivo la traccia con parole mie per capire cosa serve davvero. Una grande società di ingegneria apre tanti cantieri sparsi sul territorio. In ogni cantiere ci sono apparecchiature che producono dati (tablet con scanner 3D, telecamere, sensori di sicurezza) e quei dati devono arrivare alla sede centrale, che ha già una sua LAN ma una connessione vecchia.

• Per ogni cantiere serve una rete temporanea: collegare tablet, telecamere e sensori e dare loro accesso ai servizi.
• La sede centrale va riorganizzata e potenziata per ricevere e conservare i dati dei cantieri (i file degli scanner 3D sono pesanti).
• Il collegamento cantiere → sede deve essere sicuro: passa su Internet pubblico, quindi serve cifratura.
• Gli operatori devono autenticarsi sia in sede sia da remoto (tecnici in trasferta).

La traccia è volutamente aperta: dichiaro qualche ipotesi ragionevole per poter dimensionare la rete. Sono assunzioni, non verità assolute — ed è giusto scriverle.

• Cantiere tipo: circa 5 tablet, 4 telecamere, una ventina di sensori, più qualche portatile dei tecnici. Diciamo fino a ~30–40 dispositivi per cantiere.
• In cantiere si porta un uplink primario verso Internet (collegamento dedicato temporaneo); il 4G/5G resta come backup per la continuità (vedi Quesito II). I tablet non vanno sul 4G: si collegano in Wi-Fi agli Access Point del cantiere.
• I file pesanti degli scanner 3D si possono trasferire in modo asincrono (anche di notte): non serve banda enorme in tempo reale.
• La sede centrale sostituisce l'ADSL datata con una connessione in fibra.

Imposto il cantiere come una piccola LAN a stella. Sul bordo tengo router e firewall come due apparati fisici separati (mai il firewall «dentro» al router): il router gestisce l'uscita Internet, il firewall filtra il traffico. Sotto, uno switch a cui si attacca tutto e più Access Point per coprire il cantiere in Wi-Fi. Esattamente lo schema che disegnerei sul foglio 3.

Apparati e perché. Tengo tutto essenziale:

• Router: è l'uscita verso Internet (NAT) con uplink primario e 4G/5G di backup. Fa anche da DHCP e DNS locale, così i dispositivi prendono IP da soli e risolvono i nomi.
• Firewall fisico (separato dal router): apparato dedicato che filtra il traffico in entrata/uscita e termina la VPN verso la sede. Non è un servizio del router: è una scatola a parte.
• Switch (con PoE): collega tutto via cavo. Il PoE (Power over Ethernet) alimenta direttamente Access Point e telecamere IP sullo stesso cavo di rete.
• Più Access Point WPA3: coprono il cantiere in Wi-Fi; i tablet si agganciano all'AP più vicino e passano da uno all'altro spostandosi (roaming). Cifratura AES (vedi punto 4).
• Nodi IoT (Arduino/Raspberry): i sensori di sicurezza si collegano a una scheda che ne raccoglie le letture e le manda in rete. Sono i "mattoncini" dell'IoT che hai già visto.

Segmentazione con le VLAN. Divido il cantiere in reti logiche separate sullo stesso switch, così il traffico pesante (BIM) non disturba quello critico (sensori) e tutto è più sicuro:

! Creo le VLAN del cantiere
SW(config)# vlan 10
SW(config-vlan)# name BIM
SW(config)# vlan 30
SW(config-vlan)# name IOT

! Porta ACCESS verso un PC della VLAN BIM
SW(config)# interface fa0/1
SW(config-if)# switchport mode access
SW(config-if)# switchport access vlan 10

! Porta TRUNK verso il gateway (trasporta tutte le VLAN)
SW(config)# interface g0/1
SW(config-if)# switchport mode trunk
SW(config-if)# switchport trunk allowed vlan 10,20,30,99

La struttura esistente. La sede ha già una LAN con uffici, server e una connessione ADSL ormai datata. Per gestire il BIM la riorganizzo con una DMZ a doppio firewall (screened subnet): è la topologia classica e quella che rende più all'esame.

Leggendo lo schema: Internet → router → firewall esterno → DMZ → firewall interno → LAN. La regola è semplice: ciò che il mondo esterno deve raggiungere sta in DMZ; i dati sensibili e i servizi interni stanno in LAN.

Integrazione e potenziamento per il BIM. Cosa cambio rispetto all'esistente:

• Connessione: via l'ADSL, dentro la fibra: serve banda in upload per ricevere i file dai cantieri.
• Doppio firewall + DMZ: separa nettamente la parte pubblica dai dati interni.
• VLAN anche in sede: uffici, server e ospiti su reti logiche separate.
• Storage dedicato (NAS/SAN): per i modelli 3D, con backup regolari.
• Virtualizzazione: i vari server (portale, DNS esterno, DB, DNS interno) girano come macchine virtuali su pochi host fisici: meno hardware, più flessibilità, snapshot e ripristino facili.

Ogni cantiere è una sede remota che deve "vedere" la centrale come se fosse nello stesso edificio. Soluzione da programma: una VPN site‑to‑site. Si crea un tunnel cifrato dentro Internet tra il firewall del cantiere e quello della sede: è come avere un cavo privato, ma senza affittare linee dedicate.

• Topologia hub&spoke: la sede è il "centro" (hub), ogni cantiere è un "raggio" (spoke). Tutti i tunnel arrivano al gateway della sede.
• Protocollo: IPsec — usa IKE per scambiare in modo sicuro le chiavi e ESP per cifrare i dati. Tunnel permanente e trasparente: gli operatori non devono fare nulla.
• Cifratura con AES: i dati nel tunnel sono protetti, anche se passano su Internet pubblico.
• Uscita Internet con NAT: il router usa il NAT/PAT per far navigare tutti i dispositivi del cantiere dietro un solo indirizzo pubblico.

Capacità trasmissiva (ragionamento qualitativo). Senza perdermi nei conti: il traffico critico (allarmi dei sensori, comandi) è piccolo ma deve sempre passare; il traffico pesante (modelli 3D) è grande ma non urgente. Quindi:

• Il cantiere ha un uplink primario e il 4G/5G come backup per la continuità; i file grossi si caricano in orari scarichi (di notte).
• In sede serve più banda, soprattutto in upload/download, perché raccoglie i dati di tutti i cantieri insieme → di qui la scelta della fibra.

Idea chiave: un'unica identità per ogni operatore, verificata da un server centrale (RADIUS) in LAN. Vale sia per chi si collega in sede sia per chi arriva da remoto.

In sede (e in cantiere) — accesso alla rete:

• Wi‑Fi in modalità WPA3‑Enterprise: ogni operatore entra con le proprie credenziali, non con una password condivisa.
• Lo standard 802.1X mette in mezzo tre attori: il dispositivo (supplicant), l'AP/switch (authenticator) e il RADIUS che controlla le credenziali nell'archivio utenti.
• Se le credenziali sono valide, l'operatore entra (e può essere messo nella VLAN giusta); altrimenti resta fuori. Il traffico Wi‑Fi è cifrato con AES.

Da remoto — tecnici in trasferta:

• VPN ad accesso remoto: il tecnico apre il client VPN sul portatile e si autentica. Solo a quel punto entra nella rete aziendale, attraverso un tunnel cifrato.
• Anche qui le credenziali possono essere verificate dal RADIUS: stessa identità, un solo posto dove gestirla.
• Per gli account più delicati (amministratori) si aggiunge un secondo fattore (codice OTP): così la sola password rubata non basta.

All'esame se ne scelgono due. Qui li svolgo tutti e quattro come ripasso, sempre con gli strumenti del programma. Scegli quelli su cui hai più "carne al fuoco", non i più corti.

La domanda è: i file pesanti del BIM li teniamo sui nostri server in sede (on‑premise) o nel cloud? Due strade, ognuna con pro e contro.

Vale la pena ricordare i tre "sapori" del cloud: IaaS (affitti macchine virtuali e storage), PaaS (una piattaforma pronta su cui far girare applicazioni), SaaS (un software già pronto all'uso, come una webmail).

Due richieste: rendere la rete più sicura e garantire che la trasmissione non si interrompa. Affronto la sicurezza "a strati" (difesa in profondità): se un livello cede, sotto ce n'è un altro.

Continuità trasmissiva — come evito che "cada tutto":

• Doppio collegamento: in sede una linea principale (fibra) e una di riserva; se la prima si guasta, il traffico passa sulla seconda. In cantiere, la connessione mobile fa già da alternativa naturale.
• UPS (gruppo di continuità): tiene accesi router, switch e server qualche minuto in caso di blackout, evitando spegnimenti bruschi.
• Backup regolari: con copie anche fuori sede (cloud), per ripartire in fretta dopo un problema serio.

Veste i panni dell'amministratore di una rete didattica: vietare l'accesso non autorizzato alle piattaforme di IA solo in certi laboratori e solo in certe fasce orarie. È un problema di filtraggio del traffico + pianificazione oraria.

Come filtrare (dal più semplice al più robusto):

• ACL sul router/firewall: regole che bloccano il traffico verso gli indirizzi/porte dei siti di IA. È la via diretta e quella che mostra la tecnica all'esame.
• Filtro DNS: il DNS della scuola "non risolve" i nomi dei siti vietati → il browser non li raggiunge. Semplice e centralizzato.
• Proxy: tutto il traffico web passa da un proxy che applica una lista nera di siti. Aggiunge anche log e controllo.

Per laboratorio: ogni laboratorio è già una VLAN/sottorete diversa, quindi applico la regola solo a quella sottorete: gli altri laboratori non vengono toccati.

Per fascia oraria: sui router Cisco si usa una time‑range agganciata all'ACL: la regola di blocco è attiva solo nell'orario indicato e "si spegne" da sola fuori da quell'orario.

! 1) Definisco la fascia oraria (Lun-Ven, 8:00-14:00)
R(config)# time-range ORARIO-LEZIONE
R(config-time-range)# periodic weekdays 08:00 to 14:00

! 2) ACL: blocco la rete del Lab1 (192.168.1.0/24) verso il sito IA
!    solo dentro la fascia; tutto il resto passa
R(config)# access-list 120 deny ip 192.168.1.0 0.0.0.255 host 203.0.113.10 time-range ORARIO-LEZIONE
R(config)# access-list 120 permit ip any any

! 3) Applico l'ACL all'interfaccia del Lab1
R(config)# interface g0/1
R(config-if)# ip access-group 120 in

Il comando della traccia è:

$ ssh -p 25500 administrator@200.1.1.1

E la situazione: sul router/firewall pubblico (indirizzo 200.1.1.1) c'è una regola di NAT che reindirizza la porta 25500 verso l'host interno 172.16.1.100. Spieghiamo cosa succede e perché.

Cosa succede, passo per passo:

• L'amministratore apre una connessione SSH verso l'indirizzo pubblico 200.1.1.1 sulla porta 25500.
• Il router riceve il pacchetto e, grazie alla regola di NAT di destinazione (port forwarding), lo "gira" verso l'host interno 172.16.1.100 sulla porta 22 (quella standard di SSH).
• Tra il router e il server c'è il firewall fisico: lascia passare la sessione SSH solo se rispetta le regole (es. solo dagli indirizzi dell'amministratore).
• Da fuori l'host interno non è visibile (ha un IP privato): è raggiungibile solo attraverso quella porta pubblica. È come un centralino che inoltra una chiamata a un interno.

! Tutto ciò che arriva su 200.1.1.1:25500 va a 172.16.1.100:22
R(config)# ip nat inside source static tcp 172.16.1.100 22 200.1.1.1 25500

Finalità. Permettere all'amministratore di gestire da remoto un server che sta nella rete privata, senza esporlo direttamente su Internet. La porta non standard (25500 invece di 22) riduce i tentativi automatici di attacco, che di solito bussano alla porta 22.