Un ripetitore digitale può avere un’antenna perfetta, un duplexer tarato magnificamente, un ottimo apparato e un server configurato alla perfezione.
Poi cade Internet.
E improvvisamente la parte interconnessa della postazione smette di funzionare.
Per questo motivo uno degli aspetti più importanti nella progettazione di una moderna rete di ripetitori non è soltanto:
“come collego il sito a Internet?”
ma:
“cosa succede quando quella connessione smette di funzionare?”
La risposta porta direttamente ai concetti di ridondanza, dual-WAN, monitoraggio e failover automatico.
Prima regola: Internet prima o poi cadrà
Qualunque tecnologia può avere un’interruzione:
- FTTH;
- xDSL;
- LTE;
- 5G;
- Starlink;
- ponte Wi-Fi;
- ponte radio IP.
Non esiste quindi la connessione perfetta.
Possiamo però costruire una postazione capace di utilizzare più di una connessione.
Per esempio:
INTERNET
┌─────┴─────┐
│ │
FTTH LTE
│ │
└─────┬─────┘
│
ROUTER DUAL WAN
│
▼
RIPETITOREoppure:
WAN1 → Starlink
WAN2 → LTEo ancora:
WAN1 → ponte radio IP
WAN2 → 5GIl router decide quale collegamento utilizzare.
Failover e load balancing non sono la stessa cosa
Sono due concetti spesso confusi.
Failover
Abbiamo:
WAN1 → principale
WAN2 → backupFinché WAN1 funziona, tutto passa da lì.
Quando WAN1 viene dichiarata non disponibile:
WAN1 ✕
↓
WAN2 ✓il traffico viene instradato sulla connessione secondaria.
Load balancing
Entrambe le linee possono invece essere utilizzate contemporaneamente secondo una determinata politica.
OpenWrt supporta configurazioni multi-WAN e strumenti come mwan3 per gestire politiche che possono distribuire il traffico oppure utilizzare membri con priorità differenti per il failover.
Per una postazione radio remota, però, l’obiettivo principale è spesso la continuità, non aumentare la velocità.
Per questo la configurazione più semplice e robusta è frequentemente:
WAN1 PRIMARY
WAN2 BACKUPNon basta controllare se il cavo è collegato
Questo è uno dei punti più importanti.
Il router potrebbe vedere:
ether1 = UPma Internet potrebbe essere completamente assente.
Immaginiamo:
ROUTER
│
│ Ethernet OK
▼
MODEM
│
X
ISP non raggiungibileDal punto di vista fisico il link Ethernet funziona.
Dal punto di vista operativo Internet è morto.
Quindi il router non deve controllare soltanto:
“la porta è UP?”
Deve verificare:
“attraverso questa WAN riesco realmente a raggiungere Internet?”
Health check
La soluzione consiste nel monitorare periodicamente uno o più host esterni.
Per esempio:
WAN1
│
├── test host A
└── test host BSe entrambi diventano irraggiungibili attraverso quella specifica WAN, il router può considerare il collegamento guasto.
MikroTik documenta proprio un’architettura di failover basata su routing ricorsivo e check-gateway=ping; mostra inoltre come l’affidabilità della rilevazione possa essere migliorata controllando più di un host anziché affidarsi a un solo bersaglio.
Questo evita un errore classico.
Se monitoriamo soltanto:
8.8.8.8e quell’host per qualche ragione non risponde, potremmo dichiarare guasta una WAN che in realtà funziona.
Meglio utilizzare più verifiche.
Non scegliamo tutti i test nello stesso posto
Una progettazione ancora migliore potrebbe verificare destinazioni appartenenti a reti differenti.
Per esempio, concettualmente:
TEST 1 → DNS pubblico
TEST 2 → VPS della rete
TEST 3 → altro host affidabileL’obiettivo non è sapere semplicemente che “qualcosa risponde”.
Vogliamo capire se esiste realmente una connettività Internet utile alla nostra infrastruttura.
Gateway raggiungibile non significa Internet raggiungibile
Supponiamo che il modem LTE abbia:
192.168.8.1Se il router esegue:
ping 192.168.8.1il test potrà essere perfetto anche mentre l’operatore mobile è completamente offline.
Il test corretto deve quindi oltrepassare il modem.
ROUTER
│
▼
MODEM
│
▼
OPERATORE
│
▼
INTERNET
│
▼
HOST DI CONTROLLOSolo in questo modo stiamo verificando l’intero percorso che ci interessa.
Quanto velocemente deve avvenire il failover?
Qui bisogna evitare due estremi.
Troppo lento
Se aspettiamo cinque minuti prima di dichiarare una WAN guasta, la rete resterà inutilizzabile per troppo tempo.
Troppo veloce
Se basta perdere un singolo ping:
packet loss momentaneo
↓
WAN dichiarata DOWN
↓
switch
↓
WAN torna UP
↓
nuovo switchpossiamo creare continui passaggi tra le due linee.
La configurazione deve quindi prevedere:
- intervallo di controllo;
- numero di errori consecutivi;
- tempo minimo prima del passaggio;
- tempo di stabilizzazione prima del ritorno alla WAN primaria.
Non serve reagire al primo pacchetto perso.
Serve distinguere una reale indisponibilità da una normale imperfezione della rete.
Failover e failback
Il failover avviene quando:
WAN1 DOWN
↓
WAN2 ACTIVEIl failback avviene quando:
WAN1 torna disponibile
↓
il router verifica stabilità
↓
WAN1 nuovamente primariaNon necessariamente il ritorno deve essere immediato.
Una buona strategia può richiedere che la WAN primaria sia stabile per un certo periodo prima di trasferire nuovamente il traffico.
Questo evita il cosiddetto effetto “flapping”, cioè continui cambi di stato.
Il caso di una rete radio digitale
Immaginiamo un ripetitore DMR.
Normalmente:
RPTR
│
▼
Router
│
▼
FTTH
│
▼
Master / infrastruttura IPAlle 15:32 la FTTH cade.
Il router rileva che:
WAN1 → nessun host raggiungibilee attiva:
WAN2 → LTELa nuova situazione diventa:
RPTR
│
▼
Router
│
▼
LTE
│
▼
MasterDopo il ripristino della connettività e delle eventuali sessioni applicative, il servizio IP della postazione può riprendere sulla WAN secondaria.
Attenzione: il failover non è necessariamente invisibile
È importante essere realistici.
Quando cambiamo provider può cambiare:
- indirizzo IP pubblico;
- NAT;
- percorso Internet;
- latenza;
- MTU;
- sessioni già aperte.
Una connessione TCP preesistente, per esempio, può dover essere ristabilita.
Per questo bisogna progettare i servizi affinché possano riconnettersi automaticamente dopo un cambio WAN.
È particolarmente importante per:
- VPN;
- SSH;
- tunnel;
- server digital voice;
- MQTT;
- dashboard;
- telemetria.
La filosofia corretta non è pretendere che il guasto sia invisibile.
È fare in modo che il sistema si autoripari automaticamente.
WireGuard è molto utile anche qui
Il sistema visto nell’articolo precedente diventa prezioso.
Supponiamo che il sito crei un tunnel WireGuard verso un VPS.
VPS
▲
│
WireGuard
│
ROUTER
/ \
FTTH LTEQuando la FTTH cade, il percorso sottostante cambia.
WireGuard è progettato per associare dinamicamente a un peer l’endpoint Internet autenticato più recente e supporta il roaming tra indirizzi; questo rende il protocollo particolarmente adatto a scenari in cui cambia il percorso di accesso sottostante, pur restando necessario che routing, NAT e firewall siano correttamente configurati.
WAN principale e WAN secondaria
Possiamo assegnare priorità.
Esempio:
FTTH distanza/priorità 1
LTE distanza/priorità 2Finché la route primaria è valida:
0.0.0.0/0 → FTTHla secondaria rimane disponibile come backup.
Quando la route primaria viene rimossa o dichiarata irraggiungibile:
0.0.0.0/0 → LTEdiventa quella utilizzabile.
MikroTik documenta questo modello usando route con distanze differenti e controllo del gateway, nel quale la route con distanza inferiore rappresenta il collegamento preferito.
MikroTik Netwatch
Un altro strumento interessante presente in RouterOS è Netwatch.
Netwatch può monitorare host mediante diversi tipi di probe, tra cui:
- ICMP;
- TCP;
- HTTP/HTTPS;
- DNS.
Può inoltre eseguire script quando lo stato dell’host cambia.
Questo permette di costruire automatismi del tipo:
VPN SERVER NON RAGGIUNGIBILE
↓
controlla WAN
↓
riavvia interfaccia
↓
se ancora DOWN
↓
attiva backupoppure inviare notifiche e registrare l’evento.
Il watchdog non deve diventare distruttivo
Un errore molto comune consiste nello scrivere:
se ping fallisce
riavvia routerÈ troppo aggressivo.
Immaginiamo una semplice perdita di tre pacchetti.
Il router si riavvia.
La postazione resta offline per altri due minuti.
Poi ricade un pacchetto.
Nuovo reboot.
Abbiamo trasformato un piccolo problema di rete in un disservizio permanente.
Meglio ragionare per livelli:
LIVELLO 1
test connettività
LIVELLO 2
rinnova/restart WAN
LIVELLO 3
failover su seconda WAN
LIVELLO 4
riavvio modem
LIVELLO 5
power cycle controllatoIl reboot completo dovrebbe essere una delle ultime azioni, non la prima.
Due modem, ma possibilmente due infrastrutture diverse
Avere:
SIM TIM
SIM TIMnon offre necessariamente la stessa ridondanza di:
FTTH
+
LTEoppure:
LTE operatore A
+
LTE operatore BLa vera ridondanza cerca di eliminare i single point of failure.
Per esempio:
FTTH + 5Gprotegge maggiormente da un guasto della rete fissa.
LTE + Starlinkdiversifica ulteriormente il mezzo di accesso.
Ma se entrambe le connessioni dipendono dallo stesso alimentatore e quell’alimentatore muore, entrambe sono inutili.
La ridondanza deve comprendere anche l’energia
Quindi:
DUAL WAN ✓
UPS ✕non significa alta affidabilità.
Una postazione realmente robusta dovrebbe analizzare:
Internet
router
switch
alimentazione
server
controller
antenne
climatizzazioneIl principio è semplice:
la disponibilità dell’intero sistema è determinata anche dal componente non ridondato che può spegnere tutto il resto.
Un possibile progetto completo
Pensiamo a un sito D2ALP remoto.
┌──────────┐
│ STARLINK │
└────┬─────┘
│ WAN1
│
┌─────▼─────┐
│ ROUTER │
│ DUAL WAN │
└─────▲─────┘
│ WAN2
┌────┴────┐
│ LTE/5G │
└─────────┘
│
FIREWALL/VLAN
│
┌────────────┼────────────┐
│ │ │
▼ ▼ ▼
RIPETITORE RASPBERRY TELEMETRIA
│
▼
WIREGUARD
│
▼
VPS D2ALPAggiungiamo poi:
UPS
│
├── router
├── Starlink
├── modem LTE
├── Raspberry
└── apparati retee monitoriamo il tutto.
Monitoring delle due WAN
Una dashboard potrebbe mostrare:
WAN1 STARLINK
Status: UP
Latency: 42 ms
Packet loss: 0,2 %
WAN2 LTE
Status: STANDBY
Latency: 58 ms
Signal: GOOD
WireGuard:
UP
Ripetitore:
ONLINE
Ultimo failover:
03:17 – WAN1 → WAN2
Ripristino:
03:22 – WAN2 → WAN1Registrare gli eventi è molto importante.
RouterOS, per esempio, può mantenere log locali e inviarli anche verso sistemi di logging remoto.
Solo grazie allo storico possiamo scoprire che:
“Starlink cade ogni notte per trenta secondi”
oppure:
“LTE diventa inutilizzabile ogni domenica pomeriggio.”
Senza dati, abbiamo soltanto impressioni.
Il server centrale deve essere ridondante?
A questo punto nasce una domanda.
Abbiamo reso ridondante:
postazione
alimentazione
Internet
VPNma tutti i siti dipendono da:
UN SOLO VPSAbbiamo semplicemente spostato il single point of failure.
Una rete di dimensioni importanti potrebbe quindi prevedere:
VPN HUB A
+
VPN HUB Boppure almeno meccanismi di backup e ripristino rapido del server centrale.
Non è necessario rendere tutto immediatamente enterprise-grade, ma bisogna sapere dove si trovano i punti critici.
Una regola pratica: degradare invece di spegnersi
Una buona infrastruttura dovrebbe essere progettata per degradare progressivamente.
Scenario ideale:
FTTH funzionante
→ servizio completo
FTTH guasta
→ passa LTE
LTE guasto
→ parte radio locale ancora operativa
VPN guasta
→ ripetitore ancora operativo localmente
monitoring guasto
→ radio ancora funzionanteIl contrario sarebbe:
una cosa cade
→ tutto cadeEd è esattamente ciò che dobbiamo evitare.
Il ripetitore dovrebbe funzionare anche senza Internet?
Quando tecnicamente possibile, sì almeno per le funzioni locali previste dalla configurazione.
Internet dovrebbe aggiungere:
- networking;
- interconnessione;
- servizi;
- telemetria;
- gestione.
Non dovrebbe necessariamente trasformarsi nell’unico elemento che rende possibile l’esistenza stessa della funzione radio locale.
Il concetto è quello della graceful degradation:
più guasti avvengono, più servizi perdiamo, ma il sistema mantiene tutto ciò che può ancora funzionare.
Checklist per una postazione affidabile
Prima di considerare completato il sito chiediamoci:
Connettività
□ Esiste una seconda WAN?
□ Usa una tecnologia realmente indipendente?
□ Il failover è automatico?
□ Viene testato periodicamente?Routing
□ Controlliamo Internet e non soltanto il gateway?
□ Usiamo più target?
□ Evitiamo switch troppo aggressivi?
□ Il ritorno sulla WAN primaria è controllato?VPN
□ Il tunnel viene ristabilito automaticamente?
□ La VPN parte al boot?
□ Esistono regole firewall?Alimentazione
□ Router e modem sono sotto UPS?
□ Il backup Internet funziona anche durante blackout?
□ Esiste telemetria della batteria?Monitoring
□ Registriamo i cambi WAN?
□ Monitoriamo latency e packet loss?
□ Riceviamo notifiche?
□ Conserviamo uno storico?Conclusioni
La qualità di una rete di ripetitori non si misura soltanto quando tutto funziona.
Si misura soprattutto quando qualcosa si rompe.
Una postazione amatoriale progettata secondo criteri moderni non dovrebbe affidarsi alla speranza che:
“Internet tanto non cade.”
Deve partire dal presupposto opposto:
Internet cadrà. Il modem si bloccherà. La VPN perderà il tunnel. La corrente mancherà. Cosa farà automaticamente il sistema quando accadrà?
Da questa domanda nasce la vera affidabilità.
Una rete evoluta può quindi utilizzare:
WAN primaria + WAN secondaria + health check + failover + WireGuard + watchdog + UPS + monitoring.
A quel punto il Sysop non deve correre sul monte ogni volta che una linea Internet decide di smettere di funzionare.
Ed è proprio questo il salto di qualità tra un semplice ripetitore collegato a Internet e una vera infrastruttura radioamatoriale distribuita e resiliente.