Nethesis
NethSecurity: VPN site-to-site e accesso remoto non sono la stessa cosa
Un tunnel tra due sedi collega reti intere; una VPN per utenti remoti identifica invece singole persone e dispositivi. Progetto, regole e controlli sono differenti.
Due VPN con obiettivi diversi
La parola VPN descrive un collegamento cifrato, ma non indica automaticamente chi o che cosa viene collegato. Una VPN site-to-site, detta anche net-to-net, crea un percorso stabile tra due reti: per esempio sede principale e filiale. Una VPN di accesso remoto collega invece un singolo computer o telefono alla rete aziendale quando l’utente è fuori sede. Confondere i due scenari può portare a permessi troppo ampi, indirizzi sovrapposti e procedure di assistenza difficili da gestire.
Nel site-to-site lavorano i due firewall
La documentazione NethSecurity presenta IPsec come protocollo tipicamente usato per tunnel tra reti e compatibile anche con apparati di altri produttori. I due endpoint devono avere parametri coerenti: interfacce WAN, identificativi, reti locali e remote, chiavi e impostazioni IKE ed ESP. Una volta attivo il tunnel, i dispositivi delle sottoreti autorizzate possono raggiungere le destinazioni previste senza installare un client VPN su ogni postazione. Questo non significa però unire indiscriminatamente le LAN: routing e regole firewall continuano a stabilire quali flussi sono ammessi.
L’accesso remoto parte dall’identità
Per il lavoro fuori sede, NethSecurity documenta la modalità OpenVPN Road Warrior. Il server attende le connessioni dei client, che si autenticano e ricevono un indirizzo della rete VPN; i dispositivi remoti non devono essere pubblicamente raggiungibili. Ogni account può essere associato a un utente e, secondo la configurazione, usare certificato, credenziali e OTP. Questo modello permette di revocare l’accesso a una persona o a un dispositivo senza interrompere un tunnel permanente tra sedi. Le reti raggiungibili vanno comunque limitate a quelle realmente necessarie.
WireGuard può coprire entrambi gli scenari
NethSecurity supporta WireGuard sia per client remoti sia per collegamenti net-to-net. La differenza è nella configurazione del peer: lasciando vuote le reti del peer si ottiene un accesso client-to-site, mentre per un tunnel tra reti devono essere indicate le sottoreti raggiungibili dall’altro lato. La disponibilità di entrambe le modalità non rende equivalenti i progetti. Chi amministra il sistema deve definire endpoint, chiavi, indirizzi riservati, rotte e zona VPN, oltre a distribuire nuovamente la configurazione quando le impostazioni del peer cambiano.
Un esempio con sede e tecnico esterno
Immaginiamo una sede con rete 192.168.10.0/24 e un magazzino con rete 192.168.20.0/24. Un tunnel site-to-site può consentire al gestionale della sede di comunicare con un terminale autorizzato nel magazzino, applicando regole limitate a indirizzi e porte necessari. Un tecnico che deve intervenire occasionalmente riceve invece un account VPN individuale, con accesso soltanto ai sistemi di sua competenza. Le due reti devono essere diverse: se entrambe usassero lo stesso intervallo, il routing non saprebbe distinguere la destinazione e servirebbe riprogettare gli indirizzi o introdurre soluzioni aggiuntive.
MultiWAN, indirizzi e controlli pratici
In presenza di più connessioni Internet, la guida IPsec di NethSecurity richiede che l’endpoint remoto venga raggiunto attraverso la stessa WAN assegnata al tunnel; può essere necessaria una rotta statica verso l’indirizzo pubblico del peer. Vanno verificati anche NAT, DNS, MTU, stabilità delle linee e disponibilità delle porte necessarie. Una prova completa controlla apertura del tunnel, raggiungibilità nelle due direzioni, isolamento delle reti non autorizzate e comportamento dopo la caduta e il ripristino della connessione. Il solo stato “connesso” non dimostra che applicazioni e regole funzionino correttamente.
Versione e limiti da considerare
Le note ufficiali consultate il 7 novembre 2026 indicano NethSecurity 8.8.0, pubblicato il 29 luglio 2026 e basato su OpenWrt 25.12.5. Prima di modificare tunnel esistenti occorre verificare versione installata, backup e note complete. Una VPN non protegge endpoint compromessi, password condivise o servizi autorizzati in modo eccessivo; inoltre latenza e banda restano quelle delle connessioni disponibili. Servono monitoraggio, rinnovo o revoca delle credenziali, documentazione delle sottoreti e test periodici. Il protocollo va scelto dopo aver definito persone, reti e applicazioni da collegare, non soltanto in base alla semplicità del primo collegamento.
Fonti e riferimenti
Fonti consultate il 07/11/2026.