Svolgiamo la prova di Sistemi e Reti del 2026

Sono le otto del mattino e fa già molto caldo a Monticello Brianza, dove i ragazzi del quinto anno dell'Indirizzo Informatico dell'Istituto Alessandro Greppi stanno per entrare in aula e affrontare la temuta seconda prova di Sistemi e Reti. Il cortile è già pieno: il cancello è ancora chiuso e un brusio continuo si mescola al sole che inizia a picchiare.

I ragazzi sono davanti all'ingresso e aspettano. Alcuni sono lì da diverso tempo, appoggiati ai muretti con bottiglie d'acqua e bevande energetiche in mano, lo sguardo perso su un foglietto fitto di appunti; altri sono appena arrivati, un po' trafelati, e si uniscono ai capannelli cercando di ripassare gli argomenti più importanti all'ultimo minuto. Si incrociano nomi, formule, indirizzi di rete scritti di fretta sui palmi delle mani. Oggi non si parla d'altro che di subnetting, di VPN, di tabelle di routing, di protocolli e di maschere wildcard: il linguaggio segreto di chi, tra qualche ora, dovrà dimostrare di saper tenere in piedi una rete intera.

C'è tensione, certo, ma anche quella strana eccitazione che precede i grandi appuntamenti. Qualcuno scherza per scaricare l'ansia, qualcun altro ripete a bassa voce i passaggi della VLAN trunking come una preghiera laica. L'aria profuma d'estate e di chiusura: di un ciclo che finisce e di una prova che, volenti o nolenti, bisogna superare.

Poi, finalmente, un docente fa segno che si può entrare e un fiume di studenti si riversa dentro, lungo il corridoio che porta alle aule assegnate. I banchi sono già pronti, i fogli protocollo impilati con cura, la lavagna pulita in attesa della traccia e dell'orario d'inizio.

Mi avvicino alla cattedra, prendo il gesso e, con pochi gesti decisi, scrivo alla lavagna l'ora di inizio della prova e il termine ultimo per la consegna. Segue un istante di silenzio. Le tracce, precedentemente estratte dal plico telematico crittografato del Ministero e fotocopiate per ogni candidato, vengono distribuite. E si comincia.

Sarà davvero così difficile? Scopriamolo assieme in questa soluzione ampliata della seconda prova, che riporto di seguito passo dopo passo. Ci tengo però a precisare una cosa: questa non è la soluzione che mi aspetto da uno studente, intesa come versione perfetta. È piuttosto una discussione ampliata sul caso proposto dalla traccia ministeriale, un percorso ragionato attraverso le scelte progettuali, i calcoli e i motivi che stanno dietro a ogni decisione.

INTRODUZIONE E IPOTESI DI LAVORO

Per affrontare la progettazione richiesta, è fondamentale definire il perimetro operativo e le dimensioni del problema. La traccia descrive una "grande società di ingegneria". Formulo pertanto le seguenti Ipotesi Aggiuntive:

Numero di Cantieri: La società gestisce fino a 5 cantieri attivi contemporaneamente.
Dimensioni Cantiere: Si ipotizzano cantieri di medie/grandi dimensioni, con necessità di copertura Wi-Fi outdoor estesa (circa 10.000 mq) e presenza di barriere fisiche (muri, gru, scavi).
Dispositivi per Cantiere:
- 5 Tablet Rugged con LiDAR/Scanner.
- 4 Fotocamere Timelapse.
- 20 Sensori IoT (gas, temperatura, vibrazioni).
- 3 PC portatili per i capicantiere in un modulo prefabbricato (baracca di cantiere).
Mole di Dati e Calcolo dei Volumi: Per dimensionare la rete occorre stimare il traffico generato quotidianamente da un singolo cantiere:
- Nuvole di punti (LiDAR): Una scansione LiDAR di buona risoluzione genera circa 50-100 MB al minuto. Per giustificare questa stima occorre fare alcune considerazioni tecniche sui dispositivi e sulla natura dei dati.
  - Classificazione delle tecnologie: la traccia distingue due famiglie di strumenti. Il Laser Scanner 3D (alta precisione) è uno strumento professionale stazionario (es. Leica, Faro) che, posizionato su un treppiede, esegue scansioni a precisione millimetrica su milioni di punti, ma è costoso, ingombrante e richiede tempi di acquisizione più lunghi per ogni stazione. Il LiDAR (bassa/media precisione) è invece il sensore compatto integrato nei tablet rugged (es. iPad Pro), più leggero e maneggevole, pensato per rilievi rapidi e "a mano": la precisione è inferiore ma del tutto sufficiente per i rilevamenti BIM di massima e per il rilievo dello stato di fatto di un edificio. Poiché la traccia parla di "tablet rugged", ci si colloca in questa seconda famiglia.
  - Dispositivi di riferimento: Lo standard attuale per i rilievi LiDAR su tablet è rappresentato dalla tecnologia integrata negli iPad Pro (spesso inseriti in case rugged nei cantieri). Utilizzando app di scansione professionali orientate al BIM (come SiteScape, Polycam o 3D Scanner App), ogni scansione genera nuvole di punti grezze, esportabili nei formati standard del settore (.las, .ply o .e57).
  - Il "peso" di un punto: Una nuvola di punti ad alta risoluzione cattura milioni di punti. Per ogni singolo punto il sistema memorizza le coordinate spaziali a virgola mobile (X, Y, Z), i valori di colore (RGB) della fotocamera e l'intensità della riflettanza del laser. Tutto ciò richiede molti byte per singolo punto, da cui la mole complessiva.
  - Flusso dati reale: a densità media/bassa (rilievi veloci di massima) il flusso si aggira sui 20-30 MB al minuto. A densità alta (necessaria per il BIM, per non perdere dettagli come tubazioni o prese elettriche) e con texture fotografiche a colori ad alta risoluzione applicate sui punti, il peso sale facilmente a 50-150 MB al minuto. Se si usassero scanner palmari professionali dedicati (es. Leica BLK2GO) si arriverebbe anche a 100-300 MB al minuto, ma poiché la traccia parla di "Tablet Rugged con LiDAR", l'intervallo 50-100 MB/minuto è l'ipotesi perfetta e inattaccabile.
  Ipotizzando che ciascuno dei 5 operatori con tablet effettui circa 30 minuti di rilievi al giorno (es. 50 MB/min * 30 min = 1.5 GB per tablet), si ottiene un totale di ~7.5 - 10 GB al giorno.
- Fotocamere Timelapse (4K): Ipotizziamo 4 fotocamere che scattano 1 foto ogni 10 minuti per 10 ore lavorative (60 foto al giorno per fotocamera, 240 foto totali). Con un peso medio di 2 MB per foto JPEG in 4K, il volume è di 480 MB, arrotondato a ~0.5 GB al giorno.
- Sensori IoT: Ipotizziamo 20 sensori che inviano un payload MQTT di 1 KB ogni minuto, 24h/24h. Il traffico è: 1 KB * 60 min * 24 h * 20 sensori = 28.800 KB, ovvero appena ~28 MB al giorno. Il traffico è irrisorio in termini di volume, ma critico in termini di latenza per la segnalazione degli allarmi.
Sede Centrale: Conta circa 50 dipendenti (ingegneri, architetti, geometri) che necessitano di accesso rapido ai modelli BIM.

PRIMA PARTE

1. Progetto Generale dell'Infrastruttura di Rete del Cantiere

L'infrastruttura del cantiere deve essere temporanea, robusta (vista l'ostilità dell'ambiente) e scalabile.

Architettura e Apparati: La rete locale (LAN) del singolo cantiere seguirà una topologia a Stella Estesa (una struttura gerarchica multi-livello). Il centro della stella principale è rappresentato da un router/firewall collocato nel container direzionale. Ad esso è collegato uno switch, che funge da sotto-centro, diramando i collegamenti a stella verso i dispositivi periferici.

flowchart TD
    classDef cloud fill:#e3f2fd,stroke:#1976d2,color:#0d47a1,font-weight:bold
    classDef router fill:#fff3e0,stroke:#e65100,color:#bf360c,font-weight:bold
    classDef switch fill:#e8f5e9,stroke:#2e7d32,color:#1b5e20,font-weight:bold
    classDef wifi fill:#f3e5f5,stroke:#6a1b9a,color:#4a148c
    classDef cam fill:#fce4ec,stroke:#ad1457,color:#880e4f
    classDef endpoint fill:#e0f7fa,stroke:#00838f,color:#006064
    classDef iot fill:#fff8e1,stroke:#f57f17,color:#e65100

    INET(["🌐 Internet<br/>5G / LTE"]):::cloud

    RW["🔀 Router / Firewall Edge<br/>———————<br/>Dual SIM 5G<br/>Gateway · DHCP<br/>VPN Endpoint"]:::router

    SW["🔌 Switch PoE+ Industriale<br/>———————<br/>8/16 porte · L2<br/>VLAN 10/20/30/40"]:::switch

    AP1["📡 AP Wi-Fi 6<br/>Outdoor IP67<br/>VLAN 20 – Staff"]:::wifi
    AP2["📡 AP Wi-Fi 6 Mesh<br/>Outdoor IP67<br/>VLAN 20 – Staff"]:::wifi

    CAM1["📷 Cam Timelapse 4K<br/>VLAN 30"]:::cam
    CAM2["📷 Cam Timelapse 4K<br/>VLAN 30"]:::cam

    GW["🚪 Gateway LoRaWAN<br/>868 MHz · VLAN 40"]:::iot

    T1["📱 Tablet Rugged + LiDAR<br/>VLAN 20"]:::endpoint
    T2["📱 Tablet Rugged + LiDAR<br/>VLAN 20"]:::endpoint
    PC["💻 PC Capocantiere<br/>VLAN 20"]:::endpoint

    S1["🌡️ Sens. Gas"]:::iot
    S2["📳 Sens. Vibraz."]:::iot
    S3["🌡️ Sens. Temp."]:::iot

    INET -. "WAN cellulare" .-> RW
    RW -->|"UTP Cat 6 / Trunk 802.1Q"| SW
    SW -->|"PoE+ / Access"| AP1
    SW -->|"PoE+ / Access"| AP2
    SW -->|"PoE+ / Access"| CAM1
    SW -->|"PoE+ / Access"| CAM2
    SW -->|"Access"| GW
    AP1 -.-|"Wi-Fi 6"| T1
    AP2 -.-|"Wi-Fi 6"| T2
    AP2 -.-|"Wi-Fi 6"| PC
    GW -.-|"LoRa 868 MHz"| S1
    GW -.-|"LoRa 868 MHz"| S2
    GW -.-|"LoRa 868 MHz"| S3

Router/Firewall Edge (Mobile): Un router rugged industriale con connettività WAN cellulare (Dual SIM 5G/LTE) per garantire banda e ridondanza. Fungerà da gateway, server DHCP, e terminatore VPN verso la sede (nodo centrale della stella).
Switch Access/Distribution: Uno switch PoE+ (Power over Ethernet) industriale a 8/16 porte (centro della stella secondaria). La tecnologia PoE è cruciale per alimentare direttamente tramite cavo di rete (UTP Cat 6 outdoor) gli Access Point e le fotocamere, evitando la posa di cavi elettrici aggiuntivi.
Access Point (AP) Wi-Fi Outdoor: AP con certificazione IP67 (resistenti ad acqua e polvere), tecnologia Wi-Fi 6 (802.11ax) configurati in topologia Wireless Mesh o cablati dove possibile. Serviranno per la connettività generale dei tablet rugged verso la sede.
Connessione Periferica Tablet Rugged - LiDAR/Scanner (Analisi e Scelta): La traccia richiede che il LiDAR sia interfacciato al tablet per l'acquisizione dei dati BIM. Vengono valutate le seguenti opzioni Wired e Wireless:
- Opzione Wireless - Wi-Fi Direct (802.11ac/ax): I due dispositivi comunicano in peer-to-peer.
  - Pro: Massima libertà di movimento, assenza di cavi che potrebbero impigliarsi in ponteggi o macchinari (vantaggio cruciale per la sicurezza sul lavoro).
  - Contro: Sensibilità alle pesanti interferenze elettromagnetiche (EMI) tipiche dei cantieri (motori, saldatrici, cavi alta tensione). Inoltre, entrambi i dispositivi devono usare le proprie batterie interne.
- Opzione Wireless - Bluetooth (BLE):
  - Pro: Basso consumo energetico.
  - Contro: Larghezza di banda (max 2-3 Mbps) assolutamente insufficiente per trasferire in tempo reale la massiva mole di dati 3D generata da uno scanner LiDAR. (Soluzione scartata).
- Opzione Wired - Cavo USB-C 3.2 / Thunderbolt: * Pro: Latenza nulla e banda passante altissima (fino a 40 Gbps), essenziale per permettere al tablet il rendering a schermo in tempo reale delle nuvole di punti. Permette il Power Delivery (il tablet può alimentare lo scanner o viceversa). Totale immunità alle interferenze esterne.
  - Contro: Il cavo riduce la mobilità e rappresenta un rischio fisico se si impiglia, oltre all'usura meccanica delle porte causata dalla polvere (IP rating compromesso se la porta è aperta).
- Ipotesi Assunta (La Soluzione Migliore): Si opta per una connessione Wired (USB-C) come scelta primaria per garantire le altissime prestazioni richieste dall'elaborazione grafica live, ma con un accorgimento essenziale per la sicurezza e la robustezza: l'uso di un cavo rugged con aggancio magnetico (magnetic breakaway) certificato per alti data-rate. Se l'operatore impiglia il cavo durante l'ispezione, questo si sgancia istantaneamente evitando infortuni e cadute della costosa strumentazione. Il Wi-Fi Direct rimarrà attivo e configurato solo come fallback (via di ripiego) in caso di danneggiamento del cavo, garantendo così resilienza operativa.
Gateway IoT e Rete Sensori (Soluzione Ottima - LoRaWAN): Per raccogliere i dati dai 20 sensori di sicurezza sparsi per il cantiere, si ipotizza l'uso del protocollo LoRaWAN (Long Range WAN). I sensori comunicano via radio su frequenze sub-GHz (es. 868 MHz), che garantiscono un'ottima penetrazione attraverso ostacoli fisici (cemento, scavi).
- Vantaggi: Copertura di svariati chilometri e bassissimo consumo energetico (le batterie dei sensori durano anni).
- Ruolo del Gateway: Agisce da ponte; capta i piccoli pacchetti radio LoRa e li incapsula in pacchetti IP standard da inviare al router e, successivamente, verso la sede.
Soluzioni Alternative per Rete Sensori (Sub-ottime): In assenza di tecnologie LPWAN (come LoRaWAN), si potrebbero ipotizzare alternative, pur evidenziandone i gravi limiti in questo scenario:
- Rete Wi-Fi (IEEE 802.11): Si potrebbero agganciare i sensori agli AP dei tablet. Criticità: Il Wi-Fi ha un consumo energetico elevatissimo, costringendo ad alimentare i sensori a corrente (difficile nei cantieri) o a cambiare le batterie settimanalmente. Inoltre, i 2.4/5 GHz soffrono pesantemente gli ostacoli fisici.
- Zigbee / Bluetooth (BLE): Tecnologie a bassissimo consumo. Criticità: Raggio di copertura ridottissimo (10-30 metri). Per coprire un cantiere da 10.000 mq servirebbe creare una complessa topologia Mesh installando numerosi nodi intermedi alimentati per rilanciare il segnale, aumentando vertiginosamente i costi e i punti di vulnerabilità (Single Point of Failure). Tale confronto tecnico dimostra l'efficacia superiore della scelta LoRaWAN.

Piano di Indirizzamento (IPv4 Privato - RFC 1918) e VLAN: Per isolare il traffico (sicurezza e performance), divideremo la rete in VLAN. Assegniamo al Cantiere "X" (es. Cantiere 1) la subnet generale 10.X.0.0/16.

VLAN	Nome	Subnet (Es. Cantiere 1)	Dispositivi	Giustificazione
10	Management	10.1.10.0/24	Router, Switch, AP	Separare il traffico di gestione.
20	Staff_BIM	10.1.20.0/24	Tablet, PC Capocantiere	Traffico prioritario, necessità di banda per nuvole di punti.
30	Timelapse	10.1.30.0/24	Fotocamere IP	Isolare il traffico video continuo.
40	IoT_Sensors	10.1.40.0/24	Gateway IoT, Sensori	Traffico leggero ma critico (allarmi).

Protocolli e Servizi Locali:

DHCP: Erogato dal router per VLAN 20 e 30.
Trasmissione Dati Sensori via MQTT (Soluzione Ottima): Per l'invio dei dati applicativi dei sensori verso il server di raccolta si implementerà MQTT (Message Queuing Telemetry Transport), standard de-fatto dell'IoT, basato sul paradigma Publish/Subscribe. I sensori (tramite il Gateway) fungono da Publisher, pubblicando piccoli messaggi (es. livelli di gas) su canali tematici chiamati "Topic" (es. cantiere1/sensori/gas/A1). Il centro di smistamento è il Broker, mentre gli ingegneri e i sistemi di allarme sono i Subscriber. L'header di MQTT è leggerissimo (solo 2 byte), ideale per connessioni instabili come quelle cellulari nei cantieri.
- Il problema del posizionamento del Broker: La traccia richiede espressamente che i dati dei sensori attivino notifiche e allarmi in tempo reale localmente nel cantiere, oltre a essere trasmessi in sede centrale per le segnalazioni e il log storico. Questo pone una scelta architetturale cruciale: dove collocare il broker MQTT. Si confrontano due soluzioni.
  - Soluzione A — Broker centralizzato (solo in sede): tutti i sensori pubblicano verso un unico broker ospitato sui server della sede centrale; i sistemi di allarme del cantiere e gli ingegneri in sede sono entrambi subscriber di quel broker remoto. Architettura semplice e con un'unica fonte di verità, ma inaccettabile per la sicurezza: se il collegamento WAN (5G/LTE) cade, nessun allarme locale può scattare, perché i sensori non riescono a raggiungere il broker. In un cantiere, dove gli allarmi di gas o vibrazioni possono salvare vite, questo è un Single Point of Failure inaccettabile.
  - Soluzione B — Broker locale (Edge) nel cantiere: un broker MQTT leggero (es. Eclipse Mosquitto) è in esecuzione direttamente sul Gateway IoT o sul router industriale del cantiere. I sensori pubblicano verso questo broker locale, che attiva immediatamente gli allarmi in loco (sirene, luci di emergenza, notifica push sul tablet del capocantiere) e in parallelo inoltra i dati verso il broker centrale in sede. Vantaggi: allarmi garantiti anche a WAN spenta (funzionamento autonomo in disconnected mode), latenza minima e possibilità di pre-elaborare/filtrare i dati localmente (edge analytics). Contro: un componente in più da gestire per cantiere e la necessità di sincronizzare lo stato al ripristino del collegamento.
- Scelta Adottata — Coesistenza (architettura ibrida Edge + Cloud): le due soluzioni non sono alternative ma complementari e devono coesistere. Si installa un broker locale (Edge) in ogni cantiere per gli allarmi real-time e un broker centrale in sede per il monitoraggio, il logging storico e le elaborazioni BIM. Il broker locale fa da bridge verso quello centrale tramite il meccanismo di MQTT Bridging (o il profilo Sparkplug B), replicando solo i topic rilevanti sulla WAN. In questo modo il requisito di sicurezza (allarme locale sempre attivo) risulta disaccoppiato dalla disponibilità del canale WAN — lo stesso principio di resilienza richiesto dalla continuità trasmissiva trattata nel Quesito II.
- Affidabilità degli allarmi (parametri MQTT): per garantire che nessun allarme di sicurezza venga perso, la configurazione del protocollo sfrutta tre meccanismi specifici di MQTT:
  - QoS (Quality of Service): i messaggi di telemetria ordinaria usano QoS 0 (fire-and-forget, niente conferma, leggero), mentre gli allarmi critici (gas, vibrazioni oltre soglia) sono pubblicati con QoS 1 (almeno una consegna garantita, con ritrasmissione finché non riceve ack) o QoS 2 (esattamente una consegna, niente duplicati). La scelta del livello di QoS si fa per-topic, così il traffico pesante diagnostico non congestionerà la rete a scapito degli allarmi.
  - Last Will & Testament (LWT): ogni sensore, al momento di connettersi al broker, registra un messaggio "testamento" (es. topic cantiere1/sensori/gas/A1/status = OFFLINE). Se il sensore "muore" (batteria scarica, guasto, uscita dal raggio radio), il broker pubblica automaticamente il testamento: il sistema può così generare un allarme di disconnessione. In un cantiere, sapere che un sensore di gas non trasmette più è importante quanto l'allarme stesso.
  - Retained messages: il broker conserva l'ultimo valore pubblicato su un topic (flag retain). Quando un nuovo subscriber si connette — ad esempio un ingegnere che apre il cruscotto in sede, o il tablet del capocantiere dopo un riavvio — riceve immediatamente l'ultimo stato noto, senza dover aspettare la prossima lettura periodica del sensore.
- Formato del payload: per i sensori a batteria con banda limitata, il payload può essere codificato in JSON (leggibile e auto-descrittivo, ma più voluminoso) oppure in formato binario compatto (es. CBOR o Protobuf), che comprime drasticamente la dimensione del messaggio a parità di informazione. La scelta dipende dal trade-off tra consumo di banda/energia e facilità di debugging.

flowchart LR
    classDef sensor fill:#fff8e1,stroke:#f57f17,color:#e65100
    classDef edge fill:#e8f5e9,stroke:#2e7d32,color:#1b5e20,font-weight:bold
    classDef alarm fill:#ffebee,stroke:#c62828,color:#b71c1c,font-weight:bold
    classDef cloud fill:#e3f2fd,stroke:#1976d2,color:#0d47a1,font-weight:bold
    classDef hq fill:#f3e5f5,stroke:#6a1b9a,color:#4a148c

    S1["🌡️ Sensore Gas"]:::sensor
    S2["📳 Sensore Vibraz."]:::sensor
    S3["🌡️ Sensore Temp."]:::sensor

    GW["🚪 Gateway LoRaWAN<br/>+ Broker MQTT locale<br/>(Edge · es. Mosquitto)"]:::edge

    subgraph LOC ["📍 Percorso LOCALE — Allarme real-time"]
        direction TB
        ALM["🚨 Allarme in loco<br/>Sirene · Luci · Notifica<br/>al tablet del capocantiere"]:::alarm
    end

    INET(("🌐<br/>WAN 5G/LTE<br/>+ VPN")):::cloud

    subgraph REM ["🏢 Percorso REMOTO — verso la Sede"]
        direction TB
        BROKER["📨 Broker MQTT centrale<br/>(Sede)"]:::hq
        LOG["📊 Logging storico<br/>Cruscotti ingegneri<br/>Elaborazioni BIM"]:::hq
    end

    S1 -.->|"LoRa 868 MHz"| GW
    S2 -.->|"LoRa"| GW
    S3 -.->|"LoRa"| GW
    GW ==>|"1️⃣ attivazione immediata<br/>(sempre, anche a WAN spenta)"| ALM
    GW ==>|"2️⃣ MQTT Bridge<br/>(replica topic)"| INET
    INET --> BROKER
    BROKER --> LOG

    linkStyle 3 stroke:#c62828,stroke-width:3px
    linkStyle 4,5,6 stroke:#1976d2,stroke-width:2px,stroke-dasharray: 6 4

Trasmissione Dati Sensori via HTTP/REST (Soluzione Alternativa Sub-ottima): Nel caso in cui non si voglia o possa usare un broker MQTT, i sensori potrebbero inviare i dati tramite classiche chiamate HTTP (metodo POST) dirette a un web-server aziendale. Criticità: Il protocollo HTTP è molto pesante (header testuali voluminosi) e non supporta l'aggiornamento in tempo reale (Push) in modo nativo, obbligando il server a continue richieste (Polling) e saturando inutilmente la banda del cantiere.
HTTPS / SFTP: Per il caricamento sicuro dei pesanti file delle nuvole di punti verso la sede centrale.
Workflow dei Video Timelapse (dalla cattura al video finale): Le fotocamere timelapse (VLAN 30) scattano fotogrammi a intervalli regolari; il sistema deve trasformare questa sequenza di immagini in un video "accelerato". Il percorso completo si articola in quattro fasi:
- 1. Cattura in cantiere: ogni fotocamera acquisisce un frame a intervalli prestabiliti (es. 1 foto ogni 10 minuti), memorizzandolo localmente su scheda SD o buffer interno in attesa del trasferimento.
- 2. Trasferimento verso la sede: i fotogrammi vengono inviati in modalità batch (a fine turno o in finestre a basso traffico) verso il repository centrale. La maggior parte delle IP cam da cantiere dispone di un client FTP/FTPS (o SFTP) integrato nel firmware: la fotocamera fa push autonomo dei frame non appena ha connettività, senza bisogno di un agent sul router. In alternativa, un agent sul router del cantiere può raccogliere i frame (pull) dalla scheda SD e reinviarli. Il trasferimento avviene ovviamente sulla VPN Site-to-Site.
- 3. Repository centrale (raccolta e catalogazione): presso la sede, i frame vengono archiviati sul NAS in una struttura organizzata per cantiere → fotocamera → data, es. /timelapse/cantiere1/CAM01/2026-06/. Ogni frame mantiene metadati (timestamp, ID camera) che permettono di ricostruire l'ordine cronologico esatto, anche in caso di ritardi o pacchetti ricevuti fuori sequenza.
- 4. Assemblaggio del video (rendering): un processo automatizzato (job schedulato, es. notturno) preleva tutti i frame di un intervallo e li "cuce" in un video continuo utilizzando un encoder come FFmpeg. Si fissa un framerate elevato (es. 30 fps) rispetto alla cadenza di scatto (1 frame/10 min), ottenendo l'effetto time-lapse (giornate di lavoro compresse in pochi secondi). Il video finale viene poi archiviato nel repository per documentazione dell'avanzamento lavori o per realizzare video promozionali.
Streaming live (RTSP) — funzione aggiuntiva: oltre alla raccolta dei fotogrammi per il timelapse, le IP cam supportano generalmente il protocollo RTSP (Real Time Streaming Protocol) per l'anteprima video in tempo reale. Un direttore lavori o un ingegnere in sede può così "vedere" il cantiere dal vivo (funzione di videosorveglianza), a complemento dei timelapse che restituiscono solo una sintesi accelerata a posteriori. Il flusso RTSP, essendo continuo, va correttamente classificato (QoS / priorità bassa) per non competere con gli allarmi dei sensori sulla WAN.
Connettività locale delle fotocamere: la traccia segnala che le fotocamere offrono "connettività sia wired che wireless". Nell'ipotesi adottata si privilegia il collegamento wired via PoE+ (alimentazione e dati sullo stesso UTP Cat 6 outdoor, gestione semplice e affidabile). Tuttavia, per fotocamere poste in punti del cantiere difficili da cablare (es. gru, bordo scavo), è possibile usare fotocamere con modulo cellulare 4G/5G autonomo che inviano i frame direttamente al repository centrale via Internet, senza appoggiarsi alla LAN del cantiere.

Alternativa scartata per il backbone: Cablaggio in fibra ottica in cantiere. Motivo: Troppo fragile e costoso per un'installazione temporanea soggetta a continui scavi e movimenti mezzi. Il Wi-Fi 6 unito al 5G offre la mobilità richiesta.

Extra (oltre il contesto della prova) — Pipeline software delle nuvole di punti

Questa sezione va oltre il perimetro di una prova d'esame, dove basta citare "software specialistici di modellazione 3D". La riporto per completezza, perché chiarisce cosa accade realmente ai dati delle nuvole di punti una volta giunti in sede.

La traccia si limita a dire che i dati grezzi delle nuvole di punti "verranno utilizzate in software specialistici per le successive operazioni di modellazione 3D". In concreto, la catena applicativa che trasforma una scansione grezza in un modello BIM condiviso si articola in tre famiglie di software:

1. Software di processing delle nuvole di punti (i "software specialistici"): Autodesk ReCap Pro, CloudCompare, Faro SCENE. Prendono in ingresso i file grezzi delle scansioni (.e57, .las, .ply) ed eseguono le operazioni di registrazione (allineamento delle varie scansioni tra loro in un unico sistema di riferimento), pulizia (rimozione dei punti spurii, es. vegetazione o mezzi di passaggio) e decimazione (riduzione della densità dove non serve). Il risultato è una nuvola unificata e pulita, esportata in formati compatti (.rcp/.rcs).
2. Software di authoring BIM: Autodesk Revit, Graphisoft ArchiCAD. La nuvola pulita viene importata come sottofondo di riferimento ("point cloud underlay") e il tecnico la "traccia" per costruire il modello parametrico tridimensionale (muri, travi, impianti), che diventa il vero oggetto BIM.
3. Ambiente di condivisione (CDE): il modello finale viene pubblicato sul Common Data Environment (es. Autodesk BIM 360 / Docs) per il coordinamento multi-ufficio discusso nella Sezione 2.

Fase 1 — Acquisizione e trasferimento dal cantiere:

flowchart LR
    classDef capture fill:#e0f7fa,stroke:#00838f,color:#006064
    classDef transfer fill:#e3f2fd,stroke:#1976d2,color:#0d47a1

    APP["📱 App di acquisizione<br/>Polycam · SiteScape<br/>3D Scanner App"]:::capture
    RAW["📦 Nuvola grezza<br/>.e57 · .las · .ply"]:::capture
    UP["🔒 Upload SFTP/HTTPS<br/>su VPN Site-to-Site<br/>~10 GB/giorno"]:::transfer

    APP --> RAW
    RAW --> UP

↓ i dati grezzi attraversano la VPN e raggiungono la sede centrale:

Fase 2 — Elaborazione in sede e condivisione del modello:

flowchart LR
    classDef process fill:#fff8e1,stroke:#f57f17,color:#e65100
    classDef author fill:#f3e5f5,stroke:#6a1b9a,color:#4a148c,font-weight:bold
    classDef cde fill:#e8f5e9,stroke:#2e7d32,color:#1b5e20

    RECAP["🛠️ ReCap Pro / CloudCompare<br/>registrazione · pulizia · decimazione"]:::process
    PROC["📦 Nuvola pulita<br/>.rcp · .rcs"]:::process
    REVIT["📐 Revit / ArchiCAD<br/>modellazione parametrica<br/>(nuvola come sottofondo)"]:::author
    MODEL["🗂️ Modello BIM finale<br/>.rvt · .ifc"]:::author
    BIM360["☁️ CDE — BIM 360<br/>condivisione multi-ufficio<br/>(permessi · versioning)"]:::cde

    RECAP --> PROC
    PROC --> REVIT
    REVIT --> MODEL
    MODEL --> BIM360

2. Sede Centrale: Rete Pre-esistente e Potenziamento

Stato di Fatto (As-Is): La traccia indica una rete locale con router, switch e una connessione "WAN datata basata su tecnologia ADSL". L'ADSL (Asymmetric Digital Subscriber Line) ha velocità tipiche di 20 Mbps in download e appena 1 Mbps in upload. Criticità: Un file BIM da 5 GB impiegherebbe giorni per essere trasferito con questa tecnologia. Questa infrastruttura rappresenta un collo di bottiglia inaccettabile (Bottleneck).

Integrazione e Potenziamento (To-Be): Per supportare il sistema BIM, l'infrastruttura di sede va radicalmente aggiornata:

Upgrade Connettività (WAN): Sostituzione dell'ADSL con una connessione FTTH (Fiber To The Home/Business) con banda minima Garantita (es. 1 Gbps simmetrico o 2.5 Gbps).
Edge Network (Perimetro): Inserimento di un Next-Generation Firewall (NGFW). Sostituirà il vecchio router. Il NGFW gestirà le VPN dai cantieri, analizzerà il traffico (DPI - Deep Packet Inspection) e bloccherà intrusioni (IPS).
Core Network: Switch Layer 3 (Multilayer) ad alte prestazioni (10 Gbps) per instradare velocemente il traffico interno tra i computer degli ingegneri e i server.
Infrastruttura Server (Data Center locale):
- BIM Server / NAS (Network Attached Storage): Array di dischi in RAID 10 per memorizzare i modelli 3D e le nuvole di punti, garantendo alta velocità di lettura/scrittura e ridondanza in caso di guasto ai dischi. Il NAS funge da repository centrale del modello finale, condiviso tra i vari uffici tecnici (strutturale, architettonico, impiantistico) per il coordinamento tra i tecnici che lavorano in parallelo allo stesso progetto. La gestione collaborativa si articola su tre livelli:
  - Permessi (RBAC): gli accessi sono regolati da Active Directory tramite gruppi di ruolo (es. Ingegneri_Struttura, Architetti, Impiantisti). Ogni ufficio vede e modifica solo le porzioni di modello di propria competenza (disciplina-specific worksets), impedendo sovrascritture tra discipline diverse.
  - Lock dei file (file locking): per evitare conflitti quando più tecnici operano simultaneamente, si applica il meccanismo di check-out / check-in (o il element locking nativo dei software BIM come Revit): un oggetto in modifica viene "bloccato" finché l'utente non rilascia la modifica, impedendo a un collega di sovrascriverlo in contemporanea.
  - Versioning: ogni salvataggio genera una nuova versione tracciata del modello (audit trail), con storico delle modifiche, autore e timestamp. Questo permette il rollback a stati precedenti e il confronto tra revisioni (es. BIM 360 / Common Data Environment), requisito tipico dei flussi BIM Level 2.
- Server di Autenticazione: Un server Windows con Active Directory (AD) e server RADIUS.

flowchart TD
    classDef cloud fill:#e3f2fd,stroke:#1976d2,color:#0d47a1,font-weight:bold
    classDef fw fill:#fff3e0,stroke:#e65100,color:#bf360c,font-weight:bold
    classDef switch fill:#e8f5e9,stroke:#2e7d32,color:#1b5e20,font-weight:bold
    classDef server fill:#f3e5f5,stroke:#6a1b9a,color:#4a148c,font-weight:bold
    classDef endpoint fill:#e0f7fa,stroke:#00838f,color:#006064
    classDef legacy fill:#ffebee,stroke:#c62828,color:#b71c1c,stroke-dasharray: 5 5

    INET(["🌐 Internet<br/>FTTH 1 Gbps simmetrica"]):::cloud

    subgraph HQ ["🏢 Sede Centrale — Rete Potenziata (To-Be)"]
        direction TB
        NGFW["🛡️ NGFW HA Cluster<br/>———————<br/>Active/Passive · VRRP<br/>VPN · IPS · DPI"]:::fw

        CORE["🔌 Core Switch L3<br/>———————<br/>10 Gbps · Routing inter-VLAN"]:::switch

        subgraph DC ["🗄️ Data Center Locale"]
            direction LR
            NAS["💾 BIM Server / NAS<br/>RAID 10 · Modelli 3D"]:::server
            AD["🔑 Server AD / RADIUS<br/>Autenticazione 802.1X"]:::server
        end

        subgraph STAFF ["👥 Staff (50 dipendenti)"]
            direction LR
            PC1["💻 Ingegnere 1"]:::endpoint
            PC2["💻 Architetto"]:::endpoint
            PCN["💻 ... · Geometri"]:::endpoint
        end
    end

    INET ==>|"WAN FTTH"| NGFW
    NGFW ==>|"10 GbE trunk"| CORE
    CORE ==>|"LACP trunk"| DC
    CORE ==>|"Access VLAN"| STAFF

3. Comunicazione Cantiere-Sede Centrale (WAN)

Tipologia di Canale e Topologia Geografica: I cantieri sono siti temporanei e dislocati geograficamente. La soluzione migliore non è la posa di cavi dedicati (CDN), ma lo sfruttamento della rete Internet pubblica mettendola in sicurezza tramite VPN (Virtual Private Network) di tipo Site-to-Site. Nello specifico, adotteremo la tecnologia SD-WAN (Software-Defined Wide Area Network) o, in alternativa, tunnel IPsec.

Questa architettura WAN realizzerà una topologia logica Hub-and-Spoke: la Sede Centrale rappresenta l'Hub (il mozzo centrale, in cui risiedono i server e i dati BIM), mentre i 5 cantieri agiscono come Spoke (i raggi periferici). I cantieri comunicano esclusivamente con la sede centrale e non direttamente tra di loro. Questo accentramento garantisce un rigoroso controllo degli accessi e semplifica il monitoraggio della sicurezza.

flowchart TD
    classDef cloud fill:#e3f2fd,stroke:#1976d2,color:#0d47a1,font-weight:bold
    classDef hub fill:#fff3e0,stroke:#e65100,color:#bf360c,font-weight:bold,stroke-width:3px
    classDef spoke fill:#e8f5e9,stroke:#2e7d32,color:#1b5e20
    classDef tunnel stroke:#1565c0,stroke-width:2px,stroke-dasharray: 8 4,color:#0d47a1

    INET(("🌐<br/>Internet<br/>pubblica")):::cloud

    subgraph HUB ["🏢 Hub — Sede Centrale"]
        HUBR["🛡️ NGFW HA Cluster<br/>1 Gbps FTTH simmetrica<br/>VPN concentrator"]:::hub
    end

    subgraph SPOKES ["🚧 Spoke — Cantieri (5)"]
        direction LR
        C1["🏗️ Cantiere 1<br/>10.1.0.0/16<br/>Router 5G"]:::spoke
        C2["🏗️ Cantiere 2<br/>10.2.0.0/16<br/>Router 5G"]:::spoke
        C3["🏗️ Cantiere 3<br/>10.3.0.0/16<br/>Router 5G"]:::spoke
        C4["🏗️ Cantiere 4<br/>10.4.0.0/16<br/>Router 5G"]:::spoke
        C5["🏗️ Cantiere 5<br/>10.5.0.0/16<br/>Router 5G"]:::spoke
    end

    HUBR ===>|"'🔒 Tunnel VPN Site-to-Site<br/>(SD-WAN / IPsec)"'| INET
    INET ===>|"'🔒 Tunnel VPN'"| C1
    INET ===>|"'🔒 Tunnel VPN'"| C2
    INET ===>|"'🔒 Tunnel VPN'"| C3
    INET ===>|"'🔒 Tunnel VPN'"| C4
    INET ===>|"'🔒 Tunnel VPN'"| C5

    C1 -.-x|"❌ Nessun diretto"| C2

Vantaggio SD-WAN: Permette di aggregare più connessioni (es. 5G + FTTC) al cantiere, bilanciando il traffico in base alla priorità (es. dare priorità agli allarmi dei sensori rispetto al caricamento delle foto).

Stima Capacità Trasmissiva e Calcolo dell'Uplink:

Apparati Cantiere: Router 5G/LTE Industriale (es. Teltonika o Cisco Meraki).
Dimensionamento Banda (Upload dal cantiere): La banda necessaria viene calcolata in base alla finestra temporale scelta per il trasferimento verso la sede centrale.
- Volume totale giornaliero: circa 10.5 GB (Nuvole di punti + Foto + IoT).
- Finestra di trasferimento: Si imposta il backup/sincronizzazione dei dati pesanti a fine turno in un lasso di tempo accettabile, ad esempio 1 ora (3600 secondi).
- Calcolo teorico del throughput netto: 10.5 GigaByte equivalgono a 84 GigaBit (10.5 * 8). Per trasferire 84 Gb in 3600 secondi, serve una velocità netta di: 84 Gb / 3600 s = ~23.3 Mbps.
- Calcolo reale (Overhead e Margine): Al throughput netto va aggiunto l'overhead dei protocolli di rete (TCP/IP) e, soprattutto, il peso della crittografia VPN (IPsec aggiunge circa un 10-15% di overhead). Inoltre, le connessioni cellulari subiscono fluttuazioni in base al carico della cella (BTS). Per garantire il servizio si applica un fattore di sicurezza (oversizing) minimo di 2x. È pertanto matematicamente giustificato e necessario un Upload dal cantiere compreso tra 50 e 100 Mbps. La tecnologia 5G (banda Sub-6GHz) o una FTTC/FTTH temporanea possono garantire stabilmente questi valori.
Sede Centrale: L'FTTH simmetrica a 1 Gbps riceverà agevolmente i flussi da tutti i 5 cantieri simultaneamente (5 cantieri * 100 Mbps = 500 Mbps, ampiamente coperti dalla Gigabit della sede).

Alternativa scartata: Connessione satellitare (es. Starlink). Motivo: Ottima come backup o per cantieri in zone remote (montagna), ma nei centri urbani il 5G offre minori latenze e costi inferiori. Sarà usata solo dove il 5G è assente.

4. Autenticazione (Operatori e Sistemi)

La sicurezza basata solo su password (fattore di conoscenza) non è più sufficiente, specialmente per accessi remoti. Si applicherà il principio dello Zero Trust (non fidarsi di nulla di default).

Nella Sede Centrale (Locale):

Modalità: Single Sign-On (SSO). L'operatore accede al PC e ha automaticamente accesso ai servizi autorizzati.
Protocolli/Servizi: Utilizzo di Active Directory (AD) o LDAP (Lightweight Directory Access Protocol). L'accesso fisico alla rete LAN/Wi-Fi aziendale sarà regolato dallo standard IEEE 802.1X, basato su protocollo RADIUS. Uno switch o un AP chiederà le credenziali al server RADIUS prima di abilitare la porta di rete del client.

sequenceDiagram
    autonumber
    actor Supp as 📱 Client (Supplicant)
    participant Auth as 🔌 Switch / AP (Authenticator)
    participant AS as 🔑 Server RADIUS / AD (Authentication Server)

    Note over Supp,Auth: Fase 1 — Richiesta di accesso
    Supp->>Auth: Collegamento fisico / Wi-Fi
    Auth->>Supp: EAP Request Identity

    Note over Supp,AS: Fase 2 — Autenticazione (EAP)
    Supp->>Auth: EAP Response (credenziali / cert.)
    Auth->>AS: RADIUS Access-Request
    Note right of AS: Verifica su AD/LDAP<br/>+ MFA (OTP) se remoto

    Note over AS,Auth: Fase 3 — Decisione
    AS-->>Auth: RADIUS Access-Accept ✅ (o Reject ❌)

    Note over Auth,Supp: Fase 4 — Abilitazione porta
    Auth-->>Supp: EAP Success
    Auth->>Auth: Apre la porta (VLAN assegnata)
    Note right of Auth: Traffico autorizzato<br/>sulla VLAN corretta

Da Remoto (Dai Cantieri): I tablet e i PC dei capicantiere dovranno comunicare in sicurezza.

Autenticazione Apparato: Il tunnel Site-to-Site VPN si autentica tramite scambi di certificati digitali RSA o chiavi pre-condivise (PSK) tramite protocollo IKE/IPsec.
Autenticazione Operatore (Client-to-Site): Se un tecnico col tablet si connette fuori dal raggio del cantiere (o da casa), userà un client VPN (es. OpenVPN, WireGuard o SSL/TLS VPN).
MFA (Multi-Factor Authentication): Per ogni accesso da remoto, oltre a Username/Password, verrà richiesto un token temporaneo (OTP) generato da un'app su smartphone (es. Google Authenticator), garantendo il paradigma "Something you know + Something you have".

SECONDA PARTE

Quesito I: Archiviazione Dati - On Premise vs Cloud-based

La società deve archiviare moli massive di dati (nuvole di punti, video 4K).

Soluzione "On Premise" (In sede): I dati risiedono fisicamente sui server/NAS all'interno della sede centrale dell'azienda.

Vantaggi:
- Latenza e Velocità: Gli ingegneri in sede accedono ai file a velocità Gigabit o 10 Gigabit (velocità della LAN), fondamentale per manipolare fluidamente i modelli 3D BIM.
- Controllo e Privacy: Il dato non esce dal perimetro aziendale.
- Costi a lungo termine: Costo noto (CAPEX) per l'acquisto dell'hardware, senza canoni mensili per lo storage.
Svantaggi: Scalabilità complessa (se finisce lo spazio, bisogna comprare nuovi server), rischio di perdita dati in caso di disastro locale (incendio, furto) se non c'è un sito di Disaster Recovery.

Soluzione "Cloud-based" (es. AWS, Microsoft Azure, BIM 360): I dati sono ospitati nei data center di un provider esterno.

Vantaggi:
- Scalabilità infinita ed elastica: Lo spazio può essere aumentato in tempo reale.
- Accessibilità: I dati sono accessibili dal cantiere, da casa, o dai partner esterni senza dover passare per la VPN della sede.
- Nessuna manutenzione hardware: Risparmio sui costi operativi (condizionamento, corrente, guasti).
Svantaggi:
- Dipendenza dalla connettività: Se la connessione FTTH della sede cade, nessuno lavora.
- Latenza: Scaricare/caricare 10 GB di modello 3D dal cloud richiede tempo, rendendo difficile il lavoro collaborativo in tempo reale sullo stesso file.
- Costi (OPEX): Canoni mensili legati al consumo.

Integrazione Proposta (Architettura Ibrida): La soluzione ottimale è un Hybrid Cloud. I modelli BIM in lavorazione (dati "caldi") vengono tenuti On Premise sul NAS locale per massimizzare la velocità dei tecnici in sede. I dati storici, i log dei sensori e i repository dei video timelapse (dati "freddi") e i backup notturni vengono spostati in modo automatizzato sul Cloud (es. Amazon S3) per liberare spazio e garantire il Disaster Recovery.

Quesito II: Misure di Sicurezza Informatica e Continuità Trasmissiva

Oltre all'autenticazione (vista al punto 4), l'infrastruttura necessita di meccanismi di difesa stratificati (Defense-in-Depth).

Misure nella Sede Centrale:

Firewall NGFW e IPS/IDS: Un Intrusion Prevention System blocca attivamente traffico anomalo (es. tentativi di exploit, malware noti) basandosi su firme e comportamenti.
Endpoint Protection (EDR): Sostituzione dei classici antivirus con sistemi EDR (Endpoint Detection and Response) sui PC per rilevare comportamenti anomali (es. un ransomware che tenta di crittografare i file BIM).
Backup 3-2-1: Per difendersi dai ransomware e dai guasti: 3 copie dei dati, su 2 supporti diversi, di cui 1 off-site (es. in Cloud, vedi Quesito I).

Misure nei Cantieri (Edge Security):

Sicurezza Fisica e Port Security: Negli switch del cantiere, le porte non utilizzate devono essere disabilitate amministrativamente (shut down). Si implementa la MAC Address Security per permettere l'accesso solo ai MAC address noti delle telecamere.
WPA3 Enterprise: Per le connessioni Wi-Fi dei tablet, l'uso di WPA3 garantisce crittografia forte contro intercettazioni aeree (sniffing).
Isolamento Client (Client Isolation): Sul Wi-Fi Guest o della rete sensori, i dispositivi non devono potersi "vedere" tra loro per evitare movimenti laterali in caso di compromissione di un singolo tablet.

Continuità Trasmissiva (High Availability - HA): Per evitare che il cantiere resti isolato e i sensori di sicurezza non possano inviare allarmi:

Ridondanza WAN in Cantiere: Il router deve avere Dual-WAN failover. Ad esempio, una SIM 5G come primaria e una connessione satellitare Starlink (o SIM di altro operatore in LTE) come secondaria (backup). Se il ping verso la sede fallisce sulla WAN1, il router commuta automaticamente sulla WAN2.
Ridondanza Apparati in Sede (HA Cluster): Due Firewall NGFW in sede configurati in modalità Active/Passive o Active/Active (protocolli VRRP o HSRP). Se il firewall principale si rompe, il secondario subentra in millisecondi mantenendo attive le VPN con i cantieri.

Quesito III: Blocco delle Piattaforme di Intelligenza Artificiale a Scuola

In qualità di amministratore di rete (SysAdmin), per bloccare piattaforme IA (come ChatGPT, Claude, GitHub Copilot) usate dagli studenti, occorre agire a livello di rete aziendale.

Misure e Tecniche:

Filtraggio DNS (DNS Sinkhole / DNS Filtering):
- Come funziona: Quando lo studente digita chatgpt.com, il PC chiede la risoluzione IP al server DNS della scuola (es. Pi-Hole, pfSense o Cisco Umbrella). Il server DNS scolastico viene configurato con una Blacklist contenente i domini legati all'IA.
- Azione: Il DNS scolastico, invece di restituire il vero IP pubblico di OpenAI, restituisce un indirizzo nullo (es. 0.0.0.0) o l'IP di una pagina web di blocco (Blockpage) con il logo della scuola.
Firewall Layer 7 (Application Control / Web Filtering):
- Il blocco DNS può essere eluso se lo studente cambia i DNS sul PC locale o usa una VPN/Proxy web.
- Soluzione: Il firewall della scuola analizza il traffico a livello applicativo (DPI - Deep Packet Inspection) decifrando l'intestazione SNI (Server Name Indication) dei pacchetti HTTPS.
- Azione: Si crea una regola che fa "Drop" delle connessioni la cui categoria web è classificata come "Artificial Intelligence" o "Generative AI".

Schedulazione e Selettività (Esemplificazioni): Il blocco totale 24/7 potrebbe limitare l'uso legittimo dell'IA per i docenti. I Next-Generation Firewall moderni (es. Fortinet, Palo Alto) permettono regole temporizzate.

Modalità Temporale (Time-Based Policy): Si crea un oggetto "Orario_Lezioni" (es. LUN-VEN 08:00 - 14:00). La regola di Drop del traffico IA viene applicata solo in questo intervallo. Dalle 14:01, la policy si disattiva e le piattaforme tornano accessibili.
Modalità per Laboratorio (Source IP/VLAN): I laboratori sono segmentati in VLAN diverse.
- Regola 1: Se l'IP sorgente appartiene alla VLAN_LAB_INFORMATICA (es. 192.168.10.0/24) AND l'orario è compreso in "Orario_Lezioni", ALLORA Azione = DENY (Blocca).
- Regola 2: Se l'IP sorgente appartiene alla VLAN_DOCENTI (es. 192.168.20.0/24), ALLORA Azione = ALLOW (Permetti). In questo modo, il docente dalla cattedra può mostrare come funziona un'IA in modo guidato.

Quesito IV: Analisi del Comando SSH e Port Forwarding

Il comando impartito dall'utente è: ssh -p 25500 administrator@200.1.1.1

Teoria di riferimento: Il protocollo SSH (Secure Shell) è utilizzato per l'amministrazione remota sicura tramite terminale a riga di comando. Di default utilizza la porta TCP 22. Il flag -p permette di specificare una porta non standard. L'indirizzo 200.1.1.1 appartiene allo spazio di indirizzamento pubblico IP (Classe C pubblica), quindi è raggiungibile da Internet. L'indirizzo 172.16.1.100 appartiene allo spazio degli indirizzi IP privati (RFC 1918, Classe B privata), usati all'interno delle LAN e non instradabili su Internet.

Effetti del comando e Port Forwarding: Il dispositivo 200.1.1.1 (tipicamente un router o firewall di confine aziendale o domestico) esegue una funzione chiamata NAT (Network Address Translation), nello specifico Destination NAT (DNAT) o comunemente noto come Port Forwarding.

flowchart LR
    classDef client fill:#e0f7fa,stroke:#00838f,color:#006064
    classDef nat fill:#fff3e0,stroke:#e65100,color:#bf360c,font-weight:bold
    classDef server fill:#f3e5f5,stroke:#6a1b9a,color:#4a148c,font-weight:bold
    classDef internet fill:#e3f2fd,stroke:#1976d2,color:#0d47a1

    CLIENT["💻 Client SSH<br/>(casa / cantiere)"]:::client

    subgraph WAN ["🌐 Internet pubblico"]
        direction LR
        PUB["📦 200.1.1.1:25500<br/>(IP pubblico · porta alta)"]:::internet
    end

    subgraph EDGE ["🔀 Router / Firewall (DNAT)"]
        direction TB
        NAT["📋 Tabella NAT:<br/>25500 → 172.16.1.100:22<br/>Destination NAT (Port Fwd)"]:::nat
    end

    subgraph LAN ["🏢 LAN privata — RFC 1918"]
        direction LR
        SRV["🖥️ Server interno<br/>172.16.1.100:22<br/>(non raggiungibile da Internet)"]:::server
    end

    CLIENT -->|"1️⃣ ssh -p 25500<br/>administrator@200.1.1.1"| PUB
    PUB -->|"2️⃣ pacchetto arriva<br/>sulla porta 25500"| NAT
    NAT -->|"3️⃣ riscrive dest.<br/>→ 172.16.1.100:22"| SRV
    SRV -.->|"4️⃣ risposta<br/>(torna indietro via NAT)"| CLIENT

    linkStyle 0,1,2 stroke:#1565c0,stroke-width:2px
    linkStyle 3 stroke:#c62828,stroke-width:2px,stroke-dasharray: 5 5

Quando l'utente lancia il comando da casa o da un cantiere:

Il client SSH dell'utente cerca di instaurare una connessione crittografata verso l'IP pubblico 200.1.1.1 sulla porta TCP 25500.
Il router riceve il pacchetto. Leggendo la sua tabella di NAT, vede la regola: "Se arriva traffico sulla porta esterna 25500, modifica l'IP di destinazione nel pacchetto con 172.16.1.100 e cambia la porta di destinazione nella 22 (o un'altra configurata internamente)".
Il traffico viene reindirizzato all'interno della LAN aziendale al server/dispositivo interno.
L'effetto finale è che l'utente si ritrova loggato tramite terminale sul dispositivo locale 172.16.1.100 con l'account administrator, in modo completamente trasparente.

Precisazione sulla porta di destinazione: la traccia si limita a dire che il traffico in ingresso sulla 25500 viene reindirizzato a 172.16.1.100, senza specificare la porta interna. Che la destinazione diventi la 22 (porta standard di SSH) è quindi un'ipotesi ragionevole ma non l'unica possibile: la regola di NAT potrebbe mantenere la 25500 fino al server interno (port-forwarding "1:1" senza rimappatura) oppure rimapparla su una qualsiasi altra porta su cui il demone SSH è in ascolto. Il principio del Destination NAT non cambia.

Finalità del suo utilizzo:

Accessibilità Remota: Permette di amministrare un server interno protetto da NAT senza dover utilizzare una VPN.
Security by Obscurity (Sicurezza tramite segretezza): Spostare il servizio SSH dalla porta standard 22 alla porta "alta" 25500 riduce drasticamente gli attacchi di Brute Force (tentativi di indovinare la password) automatizzati effettuati dalle botnet mondiali, che solitamente scansionano solo la porta 22. Non è una misura di sicurezza infallibile, ma pulisce enormemente i log di sistema (riduzione del "rumore" di rete).

GLOSSARIO

BIM (Building Information Modeling): Modello informativo dell'edificio; contiene dati geometrici e fisici per gestire il ciclo di vita dell'opera.
BIM 360: Piattaforma cloud di Autodesk specifica per il settore delle costruzioni, che permette la collaborazione in tempo reale su modelli BIM da parte di team distribuiti geograficamente.
DHCP (Dynamic Host Configuration Protocol): Protocollo per l'assegnazione automatica di indirizzi IP nella rete locale.
Hub-and-Spoke: Topologia di rete (frequente in ambito WAN/VPN) in cui un nodo centrale (Hub) riceve, gestisce e smista il traffico per vari nodi periferici isolati tra loro (Spoke).
IoT (Internet of Things): Estensione di internet al mondo degli oggetti fisici (es. sensori).
LDAP/Active Directory: Sistemi per la gestione centralizzata delle identità, permessi e policy degli utenti e dei computer.
LiDAR (Light Detection and Ranging): Tecnica di telerilevamento ottico per determinare distanze e creare nuvole di punti 3D.
LoRaWAN (Long Range Wide Area Network): Protocollo di rete LPWAN studiato per connettere a internet sensori a batteria con bassissimo consumo energetico, garantendo un raggio di copertura di svariati chilometri e un'ottima penetrazione degli ostacoli.
MFA (Multi-Factor Authentication): Autenticazione a più fattori, aggiunge un livello di sicurezza oltre alla password.
MQTT (Message Queuing Telemetry Transport): Protocollo di messaggistica leggero di tipo publish/subscribe, divenuto lo standard de facto per la trasmissione dati dei dispositivi IoT verso i server (Broker).
NAS (Network Attached Storage): Dispositivo di archiviazione collegato alla rete, accessibile da più client.
NGFW (Next-Generation Firewall): Firewall avanzato in grado di filtrare il traffico non solo in base a IP/Porte, ma comprendendo le applicazioni (es. bloccando app specifiche o malware).
PoE (Power over Ethernet): Tecnologia che permette di fornire alimentazione elettrica ai dispositivi usando lo stesso cavo dati di rete (RJ45).
SD-WAN (Software-Defined WAN): Approccio software per gestire le reti geografiche in modo intelligente, aggregando più connessioni (es. LTE + Fibra) per ottimizzare le prestazioni.
Stella Estesa (Topologia a): Topologia tipica in ambito LAN in cui più strutture a stella sono collegate tra loro gerarchicamente tramite un nodo primario (es. router) e sottomultipli (es. switch), facilitando il cablaggio locale.
VLAN (Virtual LAN): Suddivisione logica di una rete locale fisica in più reti separate a livello data-link (Layer 2).
VPN (Virtual Private Network): Rete privata virtuale instaurata sfruttando una rete pubblica (Internet) tramite crittografia (tunneling).
Wi-Fi Direct: Standard che permette a due dispositivi di connettersi tra loro direttamente in modalità wireless peer-to-peer ad alta velocità, senza la necessità di appoggiarsi a un Access Point (router) esterno.

CONSIDERAZIONI FINALI

Tutto sommato, la prova era in linea con i programmi che vengono svolti negli istituti tecnici. Al di là dei dettagli implementativi — che pure ho voluto trattare in questo post per completezza e per stimolare la curiosità — i concetti di Sistemi e Reti effettivamente richiesti per una trattazione solida e consapevole erano tutti perfettamente in linea con la programmazione curriculare del Greppi. Chi aveva affrontato il programma con costanza nel corso degli ultimi tre anni non si è trovato davanti a null'altro che agli argomenti consueti: subnetting, VLAN, routing, VPN, autenticazione e sicurezza di rete non sono tematiche eccezionali pensate per l'esame, ma contenuti centrali e ricorrenti dell'indirizzo Informatico.