Una postazione radioamatoriale moderna non contiene più soltanto un ricetrasmettitore, un duplexer e un alimentatore.
Sempre più spesso troviamo anche router, Raspberry Pi, controller MMDVM, server Linux, telecamere, sistemi di telemetria, sensori, dashboard, ricevitori SDR e apparati che devono essere gestiti a distanza.
Questo crea però un problema importante:
come possiamo accedere alla postazione da Internet senza esporre direttamente tutti questi dispositivi alla rete pubblica?
Una delle soluzioni più interessanti è utilizzare una VPN WireGuard.
WireGuard è una VPN moderna e multipiattaforma che crea un’interfaccia di rete virtuale e incapsula traffico IP all’interno di UDP. La configurazione si basa principalmente sullo scambio di chiavi pubbliche tra i peer, mentre le chiavi private rimangono sui rispettivi dispositivi.
Perché una VPN in una postazione radio?
Immaginiamo una postazione DMR situata in montagna.
Al suo interno abbiamo:
- ripetitore DMR;
- Raspberry Pi;
- router;
- MMDVM;
- controller di alimentazione;
- telecamera IP;
- sistema di monitoraggio.
Il sistema dispone di una connessione LTE oppure Starlink.
La soluzione più semplice sembrerebbe aprire sul router varie porte:
22 → SSH Raspberry
80 → Dashboard
443 → Web management
8291 → Router
...Tecnicamente può funzionare, ma significa rendere disponibili verso Internet diversi servizi amministrativi.
Una soluzione decisamente più ordinata consiste invece nel creare un solo tunnel VPN.
Lo schema diventa:
PC DEL SYSOP
│
│ WireGuard
▼
INTERNET
│
▼
VPN / SERVER CENTRALE
│
│ tunnel cifrato
▼
ROUTER POSTAZIONE
│
├── Raspberry
├── Ripetitore
├── MMDVM
├── Telemetria
└── ControllerUna volta collegato alla VPN, il Sysop può raggiungere le risorse autorizzate come se si trovasse su una rete privata.
WireGuard è progettato proprio come un’interfaccia di rete IP: routing e firewall possono quindi essere gestiti con i normali strumenti del sistema operativo.
Un vantaggio enorme: il tunnel può partire dalla postazione
Questa caratteristica diventa particolarmente interessante quando la postazione si trova dietro NAT o CGNAT.
Invece di dover necessariamente iniziare la connessione dall’esterno, possiamo configurare la postazione perché stabilisca il tunnel verso un server raggiungibile pubblicamente.
Per esempio:
POSTAZIONE
Raspberry / Router
│
▼
LTE / STARLINK
│
▼
INTERNET
│
▼
VPS
IP pubblicoIl Raspberry o il router remoto conoscono l’indirizzo del VPS e instaurano il collegamento WireGuard.
Da quel momento il VPS diventa il punto centrale attraverso cui possiamo raggiungere la postazione.
WireGuard supporta inoltre i cosiddetti Persistent Keepalive, utili quando un peer dietro NAT o firewall deve mantenere valida la mappatura necessaria a ricevere traffico. La documentazione WireGuard indica 25 secondi come intervallo sensato in molti scenari NAT, precisando però che la funzione va utilizzata quando realmente necessaria.
Architettura consigliata
Possiamo utilizzare un piccolo VPS pubblico come hub della rete.
Esempio:
┌─────────────┐
│ VPS CENTRALE│
│ 10.50.0.1 │
└──────┬──────┘
│
┌─────────────┼─────────────┐
│ │ │
▼ ▼ ▼
SITO A SITO B SYSOP
10.50.0.2 10.50.0.3 10.50.0.100A ogni postazione assegniamo un indirizzo VPN differente.
Per esempio:
VPS centrale 10.50.0.1
Ripetitore A 10.50.0.2
Ripetitore B 10.50.0.3
Ripetitore C 10.50.0.4
PC Sysop 10.50.0.100In questo modo abbiamo creato una vera rete privata di management.
Installazione WireGuard su Debian o Raspberry Pi
Su sistemi Debian/Ubuntu compatibili l’installazione può essere effettuata tramite il pacchetto WireGuard; la documentazione Ubuntu mostra, ad esempio:
sudo apt install wireguardÈ poi necessario generare una coppia di chiavi.
La procedura ufficiale WireGuard utilizza:
umask 077
wg genkey > privatekey
wg pubkey < privatekey > publickeyoppure, in un’unica operazione:
wg genkey | tee privatekey | wg pubkey > publickeyLa chiave privata non deve essere distribuita. Ogni dispositivo conserva la propria private key e comunica agli altri peer solamente la propria public key.
Esempio pratico
Supponiamo di avere:
VPS pubblico:
vpn.d2alp.example
WireGuard: 10.50.0.1
Postazione remota:
WireGuard: 10.50.0.2
LAN postazione:
192.168.50.0/24
Raspberry:
192.168.50.10
Ripetitore:
192.168.50.20
Router:
192.168.50.1Sul VPS potremmo creare:
/etc/wireguard/wg0.confcon una struttura concettuale simile:
[Interface]
Address = 10.50.0.1/24
ListenPort = 51820
PrivateKey = CHIAVE_PRIVATA_VPS
[Peer]
PublicKey = CHIAVE_PUBBLICA_POSTAZIONE
AllowedIPs = 10.50.0.2/32, 192.168.50.0/24Sul gateway della postazione:
[Interface]
Address = 10.50.0.2/24
PrivateKey = CHIAVE_PRIVATA_POSTAZIONE
[Peer]
PublicKey = CHIAVE_PUBBLICA_VPS
Endpoint = vpn.d2alp.example:51820
AllowedIPs = 10.50.0.0/24
PersistentKeepalive = 25La sintassi Address, Endpoint, AllowedIPs e la configurazione mediante peer sono coerenti con il modello documentato da WireGuard e dalle guide Ubuntu.
Che cosa significa AllowedIPs?
È uno dei parametri più importanti di WireGuard.
AllowedIPs non va interpretato semplicemente come un elenco di IP “consentiti”.
Influenza anche l’associazione tra destinazioni e peer e quindi il routing del traffico attraverso l’interfaccia WireGuard. La documentazione ufficiale descrive WireGuard come una normale interfaccia alla quale vengono associate route e peer.
Un errore nella configurazione di AllowedIPs può quindi produrre situazioni in cui:
- il tunnel risulta attivo;
- il peer risponde;
- ma una determinata rete non è raggiungibile.
Solo Raspberry o tutta la LAN?
Ci sono due possibilità.
Caso 1 — vogliamo amministrare soltanto il Raspberry
È il caso più semplice.
Il Raspberry ha:
LAN: 192.168.50.10
VPN: 10.50.0.2Il Sysop accede direttamente a:
ssh 10.50.0.2Non è necessario far transitare traffico destinato agli altri dispositivi della LAN.
Caso 2 — il Raspberry diventa gateway VPN
È più interessante.
Vogliamo raggiungere:
192.168.50.20 → ripetitore
192.168.50.30 → controller
192.168.50.40 → telemetriaattraverso il Raspberry.
A quel punto il Raspberry deve poter inoltrare pacchetti tra l’interfaccia WireGuard e la LAN.
Ubuntu documenta esplicitamente, negli scenari in cui un host interno funziona da endpoint/router WireGuard, l’abilitazione di ip_forward.
Su Linux:
net.ipv4.ip_forward = 1può essere configurato in /etc/sysctl.d/, seguendo poi le opportune regole firewall e di routing.
Non trasformiamo però la VPN in una rete senza regole
Questo è fondamentale.
Una VPN non significa:
“chi entra può vedere tutto”.
Ubuntu ricorda espressamente che il traffico attraverso WireGuard può essere bidirezionale e che, essendo WireGuard un’interfaccia di rete, è opportuno applicare normali regole firewall per limitare quali risorse siano raggiungibili.
Per esempio potremmo stabilire:
SYSOP
│
├── può raggiungere Raspberry
├── può raggiungere router
├── può raggiungere ripetitore
└── può raggiungere telemetria
SERVER MONITORING
│
├── può leggere SNMP
└── NON può accedere a SSH
HOTSPOT
│
└── nessun accesso alla rete managementQuesta è una filosofia molto più sicura.
Una chiave diversa per ogni postazione
Non utilizzerei mai la stessa coppia di chiavi per tutti i ripetitori.
Meglio:
RPTR-A → chiave A
RPTR-B → chiave B
RPTR-C → chiave C
SYSOP1 → chiave D
SYSOP2 → chiave EIn questo modo, se una postazione viene dismessa o compromessa, possiamo rimuovere soltanto quel peer.
WireGuard consente infatti di aggiungere peer differenti, ciascuno dotato della propria chiave e del proprio indirizzo.
Proteggere le chiavi private
La configurazione WireGuard contiene normalmente la private key.
Questa informazione deve essere trattata come una password critica.
Mai pubblicare online:
/etc/wireguard/wg0.confsenza aver eliminato le chiavi private.
La documentazione Ubuntu suggerisce anche, quando opportuno, di conservare la private key in un file separato dalla configurazione, riducendo il rischio di pubblicarla accidentalmente durante troubleshooting o condivisione delle configurazioni.
Avvio automatico dopo un blackout
Una postazione remota deve tornare operativa senza intervento umano.
Su sistemi che utilizzano wg-quick e systemd possiamo abilitare WireGuard all’avvio:
sudo systemctl enable wg-quick@wg0e controllarne lo stato con i normali comandi systemctl. Ubuntu documenta espressamente questo meccanismo per portare automaticamente online l’interfaccia WireGuard dopo il boot.
Dopo un blackout la sequenza diventa quindi:
alimentazione ritorna
↓
router avviato
↓
Internet disponibile
↓
Linux avviato
↓
WireGuard avviato
↓
tunnel ricostruito
↓
postazione nuovamente raggiungibileEd è esattamente ciò che vogliamo da un sito remoto.
Come controllare se il tunnel funziona
Uno dei comandi più utili è:
sudo wg showWireGuard mette a disposizione wg show per visualizzare lo stato delle interfacce e dei peer.
Possiamo controllare:
- peer;
- endpoint;
- ultimo handshake;
- quantità di dati ricevuti;
- quantità di dati trasmessi.
Una diagnostica elementare potrebbe essere:
wg show
ping 10.50.0.1
ping 192.168.50.1
ping 192.168.50.20Se:
10.50.0.1 rispondema:
192.168.50.20 non rispondeil tunnel può essere perfettamente funzionante mentre il problema si trova nel routing o nel firewall della LAN.
Site-to-site: quando la rete cresce
WireGuard non deve necessariamente collegare un singolo PC a un singolo Raspberry.
Può collegare intere reti.
Ubuntu documenta esplicitamente configurazioni WireGuard site-to-site, nelle quali due reti IP differenti vengono collegate attraverso gateway WireGuard. In questi scenari le sottoreti dei due siti non devono sovrapporsi se vogliamo effettuare routing diretto senza NAT tra esse.
Possiamo quindi immaginare:
CENTRO RETE
192.168.10.0/24
│
▼
WireGuard
│
┌─────┼─────┐
│ │ │
▼ ▼ ▼
SITO A SITO B SITO COgni ripetitore diventa una piccola “filiale” della rete.
Una possibile rete D2ALP privata
Portando il concetto all’estremo possiamo costruire:
VPN MANAGEMENT D2ALP
10.50.0.0/24
10.50.0.1 HUB
10.50.0.10 Ripetitore A
10.50.0.11 Ripetitore B
10.50.0.12 Ripetitore C
10.50.0.20 Server monitoring
10.50.0.100 Sysop 1
10.50.0.101 Sysop 2A quel punto non importa più se il sito utilizza:
FTTH
ADSL
LTE
5G
Starlink
ponte Wi-FiPer il management, tutte le postazioni appartengono alla stessa infrastruttura privata.
WireGuard non sostituisce il firewall
Questo punto merita di essere ripetuto.
La VPN:
cifra e autentica il collegamento.
Il firewall:
decide cosa può attraversarlo.
Le due cose vanno utilizzate insieme.
MikroTik, per esempio, nelle proprie indicazioni di sicurezza raccomanda l’impiego di VPN come WireGuard per l’amministrazione remota anziché esporre direttamente i servizi amministrativi verso la WAN.
Architettura finale consigliata
Una postazione moderna potrebbe quindi essere:
INTERNET
│
LTE / STARLINK
│
ROUTER FIREWALL
│
┌────────┴─────────┐
│ │
VPN WireGuard VLAN RADIO
│ │
│ Ripetitore
│
VLAN MANAGEMENT
│
┌────┼─────┐
│ │ │
Pi PDU MonitorIl principio fondamentale diventa:
nessun servizio amministrativo esposto direttamente a Internet se non strettamente necessario; l’accesso alle postazioni passa attraverso la rete privata di management.
Conclusioni
WireGuard trasforma il modo di amministrare una rete di ripetitori.
Invece di avere dieci postazioni indipendenti, ciascuna con porte aperte, indirizzi diversi e soluzioni improvvisate, possiamo realizzare una vera infrastruttura privata.
Una volta implementata correttamente, la filosofia diventa:
Internet serve soltanto a trasportare il tunnel.
All’interno del tunnel troviamo invece la nostra rete di gestione.
Ed è una differenza enorme.
Perché una rete radio digitale moderna non dovrebbe essere soltanto ben progettata dal punto di vista RF.
Deve essere progettata bene anche dal punto di vista IP e della sicurezza.
Volendo, si può usare tailscale, che sfrutta wireguard come base e concede di creare una vpn mesh senza necessità di port forwarding, con gestione centralizzata delle chiavi ed autorizzazioni SSH per gli accessi.
È altresi possibile configurare il raspberry ecc in postazione come subnet router, rendendo accessibili dall’esterno tutte quelle periferiche che per natura non possono eseguire un client wireguard.
Ti interessa sviluppare l’argomento?