Quando pensiamo alla connettività Internet di un ripetitore radioamatoriale immaginiamo normalmente fibra, ADSL, ponte Wi-Fi oppure rete cellulare LTE/5G.
Ma cosa succede quando il ripetitore si trova a 1500 metri di quota, sul tetto di un rifugio, in una postazione isolata o semplicemente in un luogo dove nessun operatore riesce a fornire una connessione affidabile?
Una possibilità che negli ultimi anni ha radicalmente cambiato lo scenario è Starlink.
Per una rete radio digitale può essere una soluzione estremamente interessante.
Ma non necessariamente è sempre la soluzione migliore.
Perché un ripetitore radioamatoriale ha bisogno di Internet?
Un classico ripetitore FM analogico può funzionare perfettamente senza alcuna connessione Internet.
Nel mondo digitale la situazione cambia.
Una postazione DMR, YSF, D-STAR, NXDN, P25 oppure un gateway multimodo può avere bisogno di raggiungere:
- master server;
- reflector;
- dashboard;
- VPN;
- sistemi di telemetria;
- server di gestione;
- NTP;
- sistemi di monitoring;
- servizi SSH;
- infrastrutture VoIP.
Il requisito fondamentale non è necessariamente una banda enorme.
Molto più importanti sono spesso:
continuità, jitter contenuto, packet loss ridotto e latenza sufficientemente stabile.
Una rete radio digitale può funzionare con pochi megabit al secondo e andare male con una connessione da centinaia di megabit se questa perde continuamente pacchetti.
La stessa DMR Association evidenzia che nelle reti IP che collegano Base Station e nodi centrali il jitter è un parametro fondamentale: aumentare i buffer può ridurre le perdite, ma al prezzo di maggiore ritardo nella voce.
Dove Starlink diventa interessante
Immaginiamo un ripetitore installato su una montagna.
Non esiste:
- fibra;
- linea telefonica;
- ponte radio IP disponibile.
Il segnale LTE arriva con -115 dBm e durante l’estate la cella si satura.
Per realizzare un link Wi-Fi dedicato servirebbe installare un secondo sito intermedio.
In uno scenario del genere Starlink può cambiare completamente le carte in tavola.
La postazione ha essenzialmente bisogno di:
alimentazione elettrica + cielo sufficientemente libero.
E improvvisamente può disporre di un collegamento IP indipendente dall’infrastruttura terrestre locale.
La prima cosa da capire: Starlink non è una normale FTTH
Dal punto di vista del Sysop, collegare un cavo Ethernet al router può far sembrare Starlink una normale connessione Internet.
La struttura della rete, però, è molto differente.
Di conseguenza non bisogna progettare una postazione pensando:
“Ho Internet, quindi posso semplicemente aprire la porta 22 e collegarmi via SSH.”
Ed è qui che entra in gioco uno degli aspetti più importanti.
Il problema del CGNAT
La configurazione IPv4 predefinita di Starlink utilizza Carrier Grade NAT — CGNAT. Starlink specifica che la configurazione standard utilizza lo spazio 100.64.0.0/10 e che il modello CGNAT predefinito non consente normalmente di esporre porte IPv4 inbound come si farebbe con un tradizionale indirizzo pubblico.
Quindi:
Internet → porta 22 → IP Starlink → Raspberry
non è generalmente la strategia da adottare sulla configurazione standard.
Il NAT si trova infatti anche nella rete dell’operatore.
È un dettaglio fondamentale per chi deve amministrare da remoto:
- Raspberry Pi;
- server DMR;
- MMDVM;
- router;
- controller;
- telecamere;
- sistemi di telemetria.
IPv6 cambia parte dello scenario
Starlink dichiara anche il supporto IPv6 e, nelle attuali informazioni di supporto, indica l’assegnazione di un prefisso pubblico IPv6 /56; l’eventuale disponibilità di opzioni IPv4 pubbliche dipende invece dal prodotto/piano utilizzato. Starlink precisa inoltre che non fornisce un indirizzo IPv4 statico nel senso tradizionale.
Per un’infrastruttura moderna IPv6 può quindi rappresentare una possibilità importante.
Ma per una postazione radioamatoriale preferisco comunque ragionare in termini di:
VPN + firewall
anziché semplicemente rendere i dispositivi direttamente raggiungibili da Internet.
La soluzione più intelligente: il tunnel nasce dalla postazione
Supponiamo che sul sito remoto abbiamo:
- ripetitore DMR;
- Raspberry Pi;
- router;
- Starlink.
Invece di tentare di entrare dall’esterno, facciamo in modo che sia la postazione a creare autonomamente una connessione verso un server che controlliamo.
Per esempio:
Ripetitore / Raspberry
↓
Router
↓
Starlink
↓
Internet
↓
VPS con IP pubblico
La postazione crea una VPN verso il VPS.
Il Sysop entra quindi nel VPS o direttamente nella VPN e raggiunge il Raspberry attraverso il tunnel.
Una tecnologia particolarmente adatta a questo tipo di architettura è WireGuard.
Starlink dichiara di supportare VPN basate su TCP o UDP, ricordando che in presenza di CGNAT il sistema VPN deve supportare opportunamente NAT traversal.
In questo modo non abbiamo bisogno di aprire porte direttamente verso la postazione.
Un possibile schema professionale
Per una postazione remota progettata bene adotterei qualcosa di simile:
STARLINK
↓
ROUTER/FIREWALL
├── VLAN RADIO
│ └── Repeater / Gateway
│
├── VLAN MANAGEMENT
│ └── Raspberry / Controller
│
└── VPN WireGuard
↓
VPS / Centro rete
Meglio ancora se il router supporta:
- WireGuard;
- watchdog;
- dual WAN;
- failover;
- VLAN;
- firewall;
- SNMP;
- reboot programmabile;
- gestione remota.
A quel punto Starlink diventa semplicemente una delle WAN disponibili.
Starlink come connessione principale
Una possibile configurazione è:
WAN1 → Starlink
WAN2 → LTE/5G
Normalmente tutto il traffico utilizza Starlink.
Se Starlink cade, il router sposta automaticamente la connessione sulla rete cellulare.
Quando Starlink ritorna disponibile, il sistema può ripristinare la WAN principale.
Per una postazione importante questo è molto più intelligente che affidarsi a una sola tecnologia.
Oppure possiamo fare esattamente il contrario
In alcuni siti è preferibile:
WAN1 → FTTH/LTE
WAN2 → Starlink
Qui Starlink diventa una connessione di emergenza.
La normale rete terrestre costa energeticamente meno e può avere caratteristiche più prevedibili; il collegamento satellitare viene mantenuto come alternativa.
Quindi alla domanda:
“Starlink deve essere primario o backup?”
la risposta corretta è:
dipende dal sito.
Il vero problema delle postazioni remote: i watt
Questo è un aspetto spesso sottovalutato.
Se abbiamo una postazione collegata alla rete elettrica, consumare qualche decina di watt in più può essere quasi irrilevante.
Ma una postazione alimentata da:
pannelli solari + batterie
ragiona in maniera completamente diversa.
Le specifiche Starlink pubblicate per i diversi terminali mostrano differenze importanti. Come riferimento, Starlink indica attualmente circa 75–100 W medi per Standard 4 e 20–40 W medi per Starlink Mini, mentre il consumo effettivo può variare con condizioni operative e ambientali.
Prendiamo soltanto un esempio teorico.
Un carico medio di 80 W sempre acceso significa:
80 × 24 = 1,92 kWh al giorno.
In una postazione solare isolata non è affatto poco.
Bisogna poi aggiungere:
- ripetitore;
- router;
- Raspberry;
- ventole;
- apparati di telemetria;
- perdite degli alimentatori;
- eventuale riscaldamento.
Starlink può quindi essere tecnicamente perfetto ma energeticamente sbagliato.
Ed è uno dei motivi per cui il Mini può essere particolarmente interessante in determinate installazioni a basso consumo, purché prestazioni e condizioni del sito siano compatibili con l’impiego previsto.
UPS: assolutamente sì
Un ripetitore remoto non dovrebbe dipendere direttamente dalla rete 230 V senza un sistema di continuità.
L’architettura ideale prevede:
RETE 230 V
↓
UPS / sistema batterie
↓
Starlink + router + server
Il beneficio non è soltanto mantenere la comunicazione durante un blackout.
Un UPS protegge anche da:
- microinterruzioni;
- cadute di tensione;
- riavvii;
- cicli di alimentazione incontrollati.
Questo aspetto è particolarmente importante perché Starlink segnala che sequenze di power cycle possono produrre effetti specifici sul router; è quindi preferibile gestire l’alimentazione in maniera controllata.
Attenzione alle ostruzioni
Un modem LTE può essere messo dentro un armadio e collegato a un’antenna esterna.
Starlink è diverso.
Il terminale deve avere una vista del cielo adeguata.
Alberi, edifici, strutture metalliche, tralicci e montagne possono creare ostruzioni.
Un collegamento destinato a una telefonata occasionale può tollerare qualche interruzione.
Una rete digitale che deve trasportare voce in tempo reale è molto meno tollerante.
Una breve perdita di connettività può diventare immediatamente:
- parola persa;
- audio interrotto;
- timeout;
- perdita del collegamento con il master.
Il corretto posizionamento dell’antenna è quindi parte integrante della progettazione del sito.
E il maltempo?
Una rete satellitare non è immune dalle condizioni atmosferiche.
Per questo una postazione critica non dovrebbe basare la propria affidabilità sul principio:
“Starlink funziona sempre.”
La filosofia corretta è invece:
“Starlink funziona abbastanza bene da essere una WAN; se quella WAN cade, esiste un piano B.”
Da qui l’utilità del failover.
Modalità bypass
Se vogliamo utilizzare un router professionale, Starlink mette a disposizione la Bypass Mode, che consente di disabilitare le funzioni di routing del router Starlink e utilizzare un dispositivo di terze parti come router principale, nei modelli/configurazioni compatibili.
Per un Sysop è spesso la configurazione più interessante.
Possiamo infatti affidare a MikroTik, OpenWrt, pfSense, OPNsense o altra appliance:
- firewall;
- VPN;
- DNS;
- DHCP;
- VLAN;
- failover;
- monitoring;
- policy routing.
Starlink diventa quindi il semplice accesso WAN.
Mai lasciare tutta la rete sulla stessa LAN
Immaginiamo questa situazione:
192.168.1.10 → ripetitore
192.168.1.20 → Raspberry
192.168.1.30 → telecamera
192.168.1.40 → PC manutenzione
192.168.1.50 → access point
Funziona.
Ma non è una buona architettura.
Meglio separare logicamente almeno:
RADIO
MANAGEMENT
SERVIZI
EVENTUALE WIFI OSPITI
con VLAN e regole firewall appropriate.
Se una telecamera venisse compromessa, non dovrebbe poter dialogare liberamente con il controller del ripetitore.
Watchdog: indispensabile
Qualunque Sysop abbia gestito un ripetitore remoto conosce la situazione.
Alle 02:17 qualcosa si blocca.
La radio funziona.
La corrente c’è.
Il router apparentemente è acceso.
Ma il Raspberry non risponde.
E il sito si trova a due ore di automobile.
Occorre quindi prevedere un watchdog.
Può essere:
software, con un servizio che controlla Internet;
hardware, tramite relay IP;
oppure integrato nel router.
Un algoritmo molto semplice potrebbe essere:
ping gateway
↓
ping VPN
↓
ping server esterno
se tutto fallisce per 10 minuti:
restart WAN
se continua:
restart router
eventualmente:
power cycle terminale
Bisogna però evitare reboot incontrollati e continui. Ogni automatismo deve utilizzare timer e soglie ragionevoli.
Monitorare, non soltanto collegare
Una postazione seria dovrebbe raccogliere nel tempo almeno:
- uptime;
- perdita pacchetti;
- latenza;
- jitter;
- traffico;
- stato della VPN;
- temperatura;
- tensione batterie;
- consumo;
- disponibilità WAN primaria e secondaria.
Le statistiche Starlink permettono inoltre di controllare parametri come uptime, latenza e outage della connessione.
Con sistemi come Prometheus e Grafana possiamo costruire una vera dashboard del sito.
Per esempio:
Starlink disponibile: YES
LTE backup: READY
WireGuard: UP
packet loss 1h: 0,3%
latency media: 37 ms
Raspberry temperature: 49 °C
batteria: 13,4 V
A quel punto non stiamo più semplicemente “collegando un ripetitore a Internet”.
Stiamo realizzando una vera infrastruttura di telecomunicazioni.
Starlink e DMR: serve davvero tutta quella banda?
Quasi certamente no.
Una singola conversazione radio digitale occupa una quantità di banda enormemente inferiore alla capacità di una moderna connessione broadband.
Perciò utilizzare Starlink per un ripetitore DMR soltanto per avere “più megabit” non avrebbe molto senso.
Il vantaggio reale è un altro:
raggiungere siti nei quali una buona connessione terrestre non esiste.
È questa la vera rivoluzione.
Quando sceglierei Starlink
Lo prenderei seriamente in considerazione quando:
- il sito non dispone di fibra;
- LTE/5G è instabile;
- realizzare un ponte IP sarebbe troppo complesso;
- la postazione ha alimentazione adeguata;
- esiste buona visibilità del cielo;
- la rete necessita di una connessione indipendente dalle infrastrutture locali.
Quando non lo sceglierei
Non lo considererei automaticamente la soluzione migliore quando:
- è già disponibile FTTH affidabile;
- il sito ha pochissima energia;
- il cielo è fortemente ostruito;
- esiste un ottimo ponte radio IP;
- è disponibile una connessione LTE/5G stabile ed economicamente più razionale.
La configurazione ideale
Per un ripetitore importante vedrei particolarmente bene:
WAN primaria: fibra, ponte radio o Starlink
WAN secondaria: LTE/5G
Router: dual-WAN con firewall e WireGuard
LAN: VLAN separate
Management: esclusivamente via VPN
Alimentazione: UPS/batteria
Controllo: watchdog
Monitoring: Prometheus/Grafana o equivalente
Accesso remoto: niente servizi di amministrazione esposti direttamente sulla WAN.
Questo crea una rete decisamente più robusta rispetto alla semplice configurazione:
Starlink → switch → Raspberry → speriamo bene.
Conclusioni: soluzione definitiva o ultima risorsa?
In realtà né l’una né l’altra.
Starlink deve essere considerato un nuovo strumento a disposizione del Sysop.
Non sostituisce automaticamente fibra, LTE o ponti radio.
Ma rende realizzabili siti che fino a pochi anni fa avrebbero richiesto costosi collegamenti dedicati o sarebbero rimasti completamente isolati.
Per una rete radioamatoriale distribuita sul territorio questo apre possibilità enormi.
La vera domanda quindi non è:
“Starlink funziona per un ripetitore?”
La risposta è certamente sì, dal punto di vista della connettività.
La domanda più interessante è:
“Come progetto la postazione affinché continui a funzionare quando Starlink, Internet, il router o l’alimentazione smettono di funzionare?”
Ed è proprio questa differenza che separa un ripetitore semplicemente connesso a Internet da una postazione progettata come una piccola infrastruttura di rete affidabile.