Vai al contenuto

Architettura di Rete e Infrastruttura

Questo documento illustra l'architettura fisica e logica, la configurazione dei bridge di rete su Proxmox, le regole di routing e NAT del firewall pfSense, i tunnel VPN WireGuard e l'interconnessione con i servizi Cloud AWS.

1. Il Server Fisico Bare Metal (Host Proxmox VE)

L'intera infrastruttura on-premise/hosted risiede su un unico server fisico collocato nel datacenter di Netsons a Milano, noto internamente come "la 229".

Specifiche Hardware e Risorse

  • Hypervisor: Proxmox VE 8.4.19 (nodo singolo pve).
  • CPU: Processore a 20 thread logici.
  • Memoria RAM: 125 GB totali (circa 52 GB allocati alle VM attive).
  • Storage Locale:
  • local-lvm (Thin-pool LVM): capacità 758 GB (354 GB occupati reali, circa 760 GB allocati virtualmente in thin provisioning).
  • local (Directory): capacità 94 GB (50 GB occupati per immagini ISO, template, dump).
  • Controller dischi hardware stimato in circa 1,96 TB complessivi.
  • Storage Remoto di Backup:
  • NasBSQ-NFS: volume NFS montato su Proxmox collegato via VPN al NAS QNAP situato fisicamente presso l'ufficio aziendale di Cava de' Tirreni (capacità totale 10,8 TB, circa 6,9 TB occupati).
  • Gestione Host:
  • Interfaccia WebGUI: https://185.31.66.229:8006.
  • Non risponde direttamente dalla WAN pubblica a causa di un filtro upstream impostato dal provider Netsons; è raggiungibile via VPN o dalla rete LAN interna.

2. Configurazione dei Virtual Switch (Bridge Proxmox)

L'host gestisce due interfacce di rete fisiche (eno1 ed eno2):

       [Rete Internet Netsons]
                  │
                  ▼
          ┌──────────────┐
          │     eno1     │ (Porta fisica 1 Gbps)
          └───────┬──────┘
                  │
          ┌───────▼──────┐
          │    vmbr0     │ Bridge Pubblico WAN (185.31.66.0/24)
          └───────┬──────┘
                  ├──────────────────────── Host Proxmox (185.31.66.229/24, GW: .1)
                  │
                  └──────────────────────── WAN pfSense (VM 101: 185.31.66.187 + Alias)

          ┌──────────────┐
          │    vmbr1     │ Bridge Privato LAN (Isolato, nessuna scheda fisica)
          └───────┬──────┘
                  ├──────────────────────── LAN pfSense (VM 101: 170.10.0.1/24 - Default GW)
                  ├──────────────────────── ServerIT PROD (VM 500: 170.10.0.108)
                  ├──────────────────────── Coolify DEV (VM 200: 170.10.0.107)
                  ├──────────────────────── FreePBX Centralino (VM 102: 170.10.0.101)
                  ├──────────────────────── OP4 Windows (VM 105: 170.10.0.204)
                  └──────────────────────── VM 400 Legacy (VM 400: Spenta)
  • vmbr0 (Bridge Pubblico WAN):
  • Mappato sulla scheda fisica eno1.
  • Subnet pubblica: 185.31.66.0/24, Default Gateway del provider: 185.31.66.1.
  • Ospita l'indirizzo IP di gestione dell'host (185.31.66.229) e l'interfaccia WAN di pfSense.
  • vmbr1 (Bridge LAN Interna):
  • Switch virtuale software puro, senza schede fisiche associate.
  • Subnet interna: 170.10.0.0/24.
  • Mette in comunicazione pfSense (che fa da router/gateway con IP 170.10.0.1) con tutte le macchine virtuali.
  • eno2 / vmbr2: Interfaccia fisica secondaria non collegata e bridge non utilizzato.

3. Gestione IP Pubblici, NAT e Regole Firewall (pfSense VM 101)

Il firewall pfSense gestisce tutti gli indirizzi IP pubblici assegnati contrattualmente da Netsons tramite Virtual IP (IP Alias sulla scheda WAN).

Mappatura IP Pubblici ed Esposizione Servizi

IP Pubblico Natura Destinazione Interna Porte Esposte su WAN Note e Ruolo
185.31.66.229 IP Host Fisico Host Proxmox PVE Nessuna aperta su internet Gestione PVE (porta 8006 protetta a monte).
185.31.66.185 Virtual IP Alias VM 500 (170.10.0.108) • TCP 80, 443 (Nginx Proxy Manager)
• TCP/UDP 3333, 3334, 3478, 9999, 9000-10004 (OvenMediaEngine)
• TCP 22 (SSH filtrato da 2 IP)		 PRODUZIONE CORE: Portale di gestione, API midserver e streaming video live WebRTC.
185.31.66.186 Virtual IP Alias VM 102 (170.10.0.101) & WireGuard • UDP 51420 (Endpoint WireGuard WG_VPN)
• UDP/TCP 5060, 5160, 5161 (SIP FreePBX)
• TCP 8088, 8089 (WebRTC SIP)
• UDP 10000-40000 (RTP Audio Trombe)		 VOIP & VPN IMPIANTI: Terminazione tunnel per tutti i 66 box (receiver1.protexia24.com:51420) e canali voce centralino. Porte 80 e 443 libere.
185.31.66.187 WAN Principale pfSense VM 200 (170.10.0.107) • TCP 80, 443 (Traefik Proxy Dev)
• Porte OME Streaming Dev		 SVILUPPO: Pannello Coolify Dev (coolify.dev.bsqdev.uk) e applicazioni di test.

Regole NAT da VPN verso la LAN

pfSense effettua un NAT 1:1 per rendere raggiungibili le VM della LAN dai client collegati via VPN:

IP su Rete VPN Mappatura VM LAN Descrizione
172.16.16.253 170.10.0.108 (ServerIT) Tutte le porte. È l'indirizzo a cui tutti i box clienti inviano chiamate API (porta 5000) e telemetria MQTT (porta 1883).
172.16.16.252 170.10.0.107 (Coolify DEV) Mappatura verso l'ambiente di collaudo.
172.16.16.254 170.10.0.100 (VM 400) Mappatura storica verso la vecchia VM di sviluppo.

4. Topologia e Configurazione dei Tunnel VPN WireGuard

pfSense gestisce due istanze WireGuard completamente distinte:

                  ┌──────────────────────────────────────────────┐
                  │                 pfSense                      │
                  └──────────────┬────────────────┬──────────────┘
                                 │                │
            Interfaccia tun_wg0  │                │  Interfaccia tun_wg1
         (WG_VPN: 172.16.16.1/24)│                │  (WG_STS_CAVA: 171.16.16.1/24)
            Porta UDP 51420      │                │  Porta UDP 51421
                                 │                │
                                 ▼                ▼
                     ┌─────────────────┐    ┌───────────────────────────┐
                     │ 66 BOX CLIENTI  │    │  FIREWALL SEDE CAVA       │
                     │ (Mini PC Edge)  │    │  (Peer: 171.16.16.100)    │
                     │                 │    └─────────────┬─────────────┘
                     │ 172.16.16.2     │                  │
                     │ 172.16.16.3     │                  ├─ Operatori Centrale Operativa
                     │ ...             │                  ├─ Postazioni dipendenti
                     │ 172.16.16.66    │                  ├─ Raspberry Pi Michele (192.168.200.220)
                     └─────────────────┘                  └─ NAS QNAP Backup (NFS su VPN)

Tunnel 1: WG_VPN (tun_wg0) — Rete degli Impianti

  • Scopo: Connettere i Mini PC Ubuntu installati presso i clienti alla centrale e al midserver.
  • Subnet: 172.16.16.0/24.
  • IP Gateway pfSense: 172.16.16.1.
  • Porta di Ascolto Esterna: UDP 51420 su IP 185.31.66.186.
  • Hostname Pubblico di Connessione: receiver1.protexia24.com:51420.
  • Peer Attivi: Circa 66 peer registrati (ciascuno con IP fisso progressivo).
  • Configurazione di Routing sul Box Cliente:
  • AllowedIPs = 172.16.16.1/32, 172.16.16.253/32, 172.16.16.254/32
  • Parametri tunnel: MTU = 1412, PersistentKeepalive = 25.
  • Il box invia nel tunnel esclusivamente il traffico diretto verso pfSense e verso il midserver ServerIT.

Tunnel 2: WG_STS_CAVA (tun_wg1) — Collegamento Sede Operativa Cava

  • Scopo: Collegare la centrale operativa e gli uffici aziendali di Cava de' Tirreni ai server di Milano.
  • Subnet: 171.16.16.0/24.
  • IP Gateway pfSense: 171.16.16.1.
  • Porta di Ascolto Esterna: UDP 51421 su IP 185.31.66.186.
  • Peer: Unico peer gateway configurato (171.16.16.100), corrispondente al firewall dell'ufficio di Cava.
  • Flusso del Traffico Aziendale:
  • Tutto il traffico generato dai dipendenti, dalle postazioni della centrale operativa (rete 10.200.171.0/24) e dal Raspberry Pi di Michele transita attraverso questo singolo tunnel.
  • Flussi Principali verso i Box Clienti:
    • Stream video dagli NVR: porte TCP 10101-10105 e porte RTSP standard 554/8554 (trasportano la quasi totalità della banda, circa 98 TiB cumulati).
    • API locali di inserimento/stato: porta TCP 5005.
    • Porte legacy di telemetria e controllo: porta 1996 e porta 2000.
  • Flussi verso la LAN di Milano: Telefonia SIP verso FreePBX (170.10.0.101), interrogazioni al midserver e watchdog domotico Sonoff (170.10.0.108:8080).

5. Anomalia sull'Indirizzamento IP (Subnet non-RFC 1918)

Un elemento sistemistico rilevante è l'uso storico di due subnet che non rientrano negli indirizzi privati standard (RFC 1918):

  • 170.10.0.0/24 (utilizzata per la LAN interna delle VM su vmbr1).
  • 171.16.16.0/24 (utilizzata per il tunnel VPN verso la sede di Cava).

Questi blocchi appartengono formalmente a registrar pubblici su internet. Nell'infrastruttura attuale funzionano correttamente perché instradati all'interno di reti private isolate e sottoposte a NAT, ma provocano un effetto collaterale: qualsiasi eventuale risorsa pubblica reale presente su internet all'interno di quelle subnet non è raggiungibile dall'infrastruttura aziendale. La direttiva concordata è di non alterare tali reti al momento per non rischiare disallineamenti di massa sui client, ma di non estenderne ulteriormente l'utilizzo.

6. Risorse Cloud AWS Correlate (Regione eu-west-1 - Irlanda)

L'infrastruttura Proxmox è affiancata da una serie di servizi ospitati sull'account AWS aziendale (407138933921):

  • Amazon S3:
  • videosorveglianzasync: contiene l'archivio giornaliero delle registrazioni audio effettuate dal centralino FreePBX sulle trombe acustiche (registrazioni-audio/AAAA/MM/GG/).
  • bsq.protexia: ospita gli snapshot fotografici generati dagli allarmi (qalarm_snapshots/) e gli allegati della chat operativa.
  • it.bsq.mdm.logs: raccoglie i dump diagnostici e i file di log inviati periodicamente dai box cliente di produzione (suddivisi per indirizzo MAC).
  • it.bsq.mdm.logs.dev: log di diagnostica dei box di test e laboratorio.
  • Amazon RDS (MySQL): Database relazionale centrale BSQ. Contiene le anagrafiche dei clienti e dei contratti, interrogato dai sistemi gestionali e dall'applicativo qAlarm 2.
  • Amazon ECR (Elastic Container Registry): Registri delle immagini container per il provisioning dei box (mdm8670650/installation, frigate_wrapper, dsniff, mdm_panel). I token di autenticazione Docker per ECR scadono ogni 12 ore.
  • AWS Route 53: Gestore DNS autoritativo predisposto per il rollout dei nuovi domini di produzione.

7. Domini e Risoluzione DNS

Attualmente i servizi pubblici rispondono sui seguenti domini di terzo livello:

Nome Host FQDN Destinazione IP Gestore DNS Ruolo e Dipendenze
panel.bsqdev.uk 185.31.66.185 Cloudflare Portale Web di gestione MDM (produzione).
api.bsqdev.uk 185.31.66.185 Cloudflare Endpoint API REST midserver (produzione).
ome.bsqdev.uk 185.31.66.185 Cloudflare Server di streaming video OvenMediaEngine.
coolify.dev.bsqdev.uk 185.31.66.187 Cloudflare Dashboard Coolify per l'ambiente di test.
*.dev.bsqdev.uk 185.31.66.187 Cloudflare Sotto-servizi di sviluppo e monitoring.
receiver1.protexia24.com 185.31.66.186 DNS Pubblico Endpoint WireGuard configurato all'interno di tutti i 66 box impianti.

Nota di Vincolo: I nomi ome.bsqdev.uk e api.bsqdev.uk sono attualmente cablati all'interno delle applicazioni mobili (App Protexia sui dispositivi degli utenti finali). Non possono essere dismessi o modificati arbitrariamente senza prima distribuire e far adottare un aggiornamento client su scala.