WireGuard 5G in filiale: lasciate che sia la filiale a chiamare l’hub

Puntare una filiale verso un hub è la metà facile di questo progetto quando la filiale sta dietro un indirizzo mobile che cambia e l’hub ha un nome stabile. L’hub impara allora la filiale dal traffico autenticato, invece che da un record che dovete mantenere aggiornato. Il contratto è semplice: la filiale inizia sempre.

Configuratelo di proposito, poi verificate la parte che la gente dà per funzionante. Entrambi i passaggi richiedono minuti, e nel secondo questi progetti di solito falliscono.

Quale lato detiene l’endpoint stabile

La configurazione della filiale indica l’endpoint e la chiave pubblica dell’hub. La configurazione dell’hub indica la chiave pubblica della filiale e i suoi prefissi interni consentiti, e può non avere alcun endpoint, perché l’identità viene dalla chiave e non dall’indirizzo di origine dell’ultimo pacchetto. Quell’asimmetria è tutto il meccanismo, ed elimina un’intera classe di problemi di scoperta dal lato dell’hub.

Quando la filiale invia un pacchetto autenticato, l’hub registra l’origine da cui è arrivato e usa quella mappatura per le risposte. La rinumerazione del collegamento mobile allora non costa nulla oltre alla stretta di mano successiva, e ogni componente che non vi serve più è uno che non può guastarsi durante un passaggio. Quella proprietà merita di essere provata durante un cambiamento pianificato e non durante un incidente. Fatelo mentre qualcuno può guardare entrambe le estremità insieme.

Date alla filiale una configurazione che sopravviva alla rinumerazione

Tenete l’endpoint e il keepalive sulla filiale, e tenete la voce del peer sull’hub libera da un indirizzo codificato a mano. Il keepalive tiene aperta la mappatura tradotta abbastanza a lungo perché l’hub possa inviare traffico non richiesto dopo un periodo di inattività.

[Peer]
PublicKey = HUB_PUBLIC_KEY_BASE64
Endpoint = hub.example.net:51820
AllowedIPs = 10.60.0.0/24, 10.60.10.0/24
PersistentKeepalive = 25

Venticinque secondi è l’esempio citato spesso per mantenere viva una mappatura NAT, non un requisito per ogni peer. Impostatelo in base al timeout di mappatura che osservate davvero, e ricordate che genera traffico su un collegamento con limite di dati finché l’interfaccia è attiva.

Sull’hub, i prefissi consentiti del peer della filiale devono coprire tutto ciò che la filiale invierà. Un prefisso mancante si comporta come un guasto di instradamento all’estremità remota e non produce alcun avviso su nessuno dei due lati, per questo vale la pena rivederlo prima del primo pacchetto reale. Confrontate i prefissi consentiti dell’hub con gli indirizzi di interfaccia della filiale prima della prima connessione.

Verificate la mappatura e il failover

Confermate che la stretta di mano si completa, che l’hub elenca l’endpoint attuale della filiale e che gli indirizzi interni della filiale sono raggiungibili attraverso il tunnel. Questa è la linea di base, e andrebbe registrata prima che qualcuno tocchi il collegamento mobile. Due righe di output bastano. Conservatele nel ticket con il timestamp.

wg show wg0
wg show wg0 latest-handshakes
ip route show default
ping -c 3 10.60.10.1

Poi provate il guasto per cui il progetto esiste. Staccate il WAN principale e confermate che la rotta sottostante della filiale verso l’hub ora esce dall’interfaccia mobile. Un tunnel non può riparare un percorso fisico rotto, quindi una rotta esterna che punta ancora a un uplink morto produce un timeout di stretta di mano che sembra esattamente un problema dell’hub.

Se il percorso esterno è esplicitamente vincolato o instradato da policy, il failover deve includerlo. Quel divario tra un progetto che si legge correttamente e uno che sopravvive a un’interruzione è di solito l’unica cosa che manca.

Cosa non risolve questo progetto

Niente qui ammette una connessione in ingresso verso la filiale. Se qualcosa in sede deve chiamare il sito mobile, la direzione del tunnel è sbagliata per quel requisito, e il DNS dinamico aggiorna solo un nome. La traduzione del provider, la policy in ingresso e l’aggiornamento dell’endpoint da parte del client restano tutti sulla strada, e un record cambiato non può aprire un NAT di livello operatore.

Tenete il prefisso della filiale distinto da ogni altro sito, e limitate ciò che il suo gateway inoltrerà. L’endpoint stabile dell’hub semplifica la scoperta e non fa nulla per il progetto di instradamento, la pianificazione degli indirizzi o la domanda su quali rotte applicative sopravvivano a un failover.

Scrivete quattro cose nel runbook: chi inizia, quali prefissi sono consentiti, quanto dura il keepalive e cosa succede quando il collegamento principale cade. Quelle righe sono ciò di cui un operatore futuro ha davvero bisogno alle tre di notte.