Due sedi cellulari senza porte in entrata: costruire un concentratore che funzioni

Due sedi su collegamenti cellulari hanno lo stesso problema in entrambe le direzioni: nessuna può accettare una connessione IPv4 non richiesta, quindi nessuna può fare da server in un tunnel diretto. L’architettura che funziona mette un terzo raggiungibile nel mezzo: ogni sede chiama verso l’esterno e il mezzo inoltra solo il traffico che approvi. Quel mezzo può essere un router che gestisci tu o un prodotto che presenta i peer, e non sono la stessa cosa. I passaggi sotto sono ordinati in modo che ciascuno produca una prova prima che il successivo ne dipenda.

Nessuna delle due sedi è raggiungibile, quindi entrambe devono chiamare verso l’esterno

Conferma il vincolo prima di progettare attorno ad esso. Se l’operatore assegna un indirizzo privato all’interfaccia WAN, nessuna redirezione di porta sul router della sede la renderà raggiungibile, perché la traduzione avviene più a monte. Un indirizzo IPv6 pubblico può esistere sullo stesso collegamento e cambiare del tutto il progetto, per questo il controllo copre entrambe le famiglie. Annota la risposta per ogni sede, perché le due raramente hanno vincoli identici anche quando condividono un operatore.

Il caso cellulare ordinario appare come un indirizzo dell’intervallo tradotto dall’operatore con una rotta predefinita che lo attraversa. Non è un guasto da riparare; è la ragione per cui esiste il concentratore. Quello che cerchi è qualsiasi indirizzo che un terzo possa raggiungere senza che la sede abbia parlato per prima.

Due comandi rispondono alla domanda di indirizzamento della sede davanti a cui ti trovi. Eseguili sul router della sede, non su un portatile dietro di essa:

ip -4 addr show scope global
ip -6 addr show scope global

Chi presenta i peer e chi trasporta i pacchetti

Presentazione e trasporto sono lavori separati che i prodotti spesso raggruppano senza rendere visibile la linea. Un meccanismo di incontro aiuta due peer a trovare un percorso candidato; un relay trasporta i loro pacchetti quando non esiste un percorso diretto. Comprare un servizio che presenta i peer non ti dà un router, e quella differenza decide se il progetto ha bisogno di un concentratore.

La traversata ha il suo vocabolario, e le parole descrivono ruoli, non garanzie. La specifica ICE descrive candidati e controlli di connettività, STUN descrive un modo per conoscere la traduzione degli indirizzi, e TURN descrive il trasporto inoltrato per le applicazioni che lo implementano. Nessuno di questi meccanismi compare in un gateway convenzionale perché l’hai puntato a un indirizzo di scoperta. Verifica la traversata come capacità del prodotto e presupponi il relay finché un test non dimostra il contrario.

Una rotta per sede, posseduta da un peer

Il concentratore richiede un tunnel per sede, un prefisso LAN distinto dietro ciascuna e una rotta per ogni prefisso che ne nomina il proprietario. Nell’esempio il concentratore è 10.61.0.1, la sede A è 10.61.0.11 con LAN 10.60.10.0/24, e la sede B è 10.61.0.12 con LAN 10.60.20.0/24. Ogni rotta sotto punta al peer che possiede il prefisso, non all’interfaccia del tunnel:

ip route add 10.60.10.0/24 via 10.61.0.11 dev wg0
ip route add 10.60.20.0/24 via 10.61.0.12 dev wg0
sysctl net.ipv4.ip_forward
ip route get 10.60.20.55 from 10.60.10.77

L’inoltro deve essere attivo, altrimenti i pacchetti si fermano al concentratore senza un errore che indichi la causa. L’ultimo comando risponde alla domanda reale, perché chiede quale percorso prenderebbe un pacchetto dalla LAN della sede A alla LAN della sede B con l’origine inclusa nella ricerca. Tratta una ricerca che nomina l’interfaccia del tunnel come prova e una che ricade sulla rotta predefinita come una rotta mancante, non come un mistero. Poi limita il transito di proposito, perché un concentratore che inoltra tra ogni peer trasforma due sedi in una rete piatta e la politica di accesso che credevi di avere smette di valere.

Decidi anche dove finisce la crittografia. Quando il concentratore detiene entrambe le terminazioni del tunnel, l’operatore di quella macchina e il suo carico di lavoro entrano nel modello di fiducia e disponibilità, e la sua larghezza di banda diventa parte del percorso.

Mantieni ogni mappatura viva attraverso l’operatore

Ogni sede avvia il proprio tunnel, e ciascuna deve mantenere viva la mappatura della traduzione altrimenti l’operatore la dimentica. Un keepalive sul lato che inizia preserva quella mappatura tra le strette di mano. Limita i prefissi consentiti all’indirizzo del concentratore e alla LAN remota, così un peer compromesso non può rivendicare un prefisso che non possiede:

[Peer]
PublicKey = <hub public key>
Endpoint = 192.0.2.10:51820
AllowedIPs = 10.61.0.1/32, 10.60.20.0/24
PersistentKeepalive = 25

Ripeti il blocco sull’altra sede con il proprio prefisso remoto, e resisti alla tentazione di consentire l’intero intervallo del tunnel. Una stretta di mano che si ferma e riprende da una nuova porta di origine è la firma di una mappatura scaduta, e i timestamp della stretta di mano sono la prova che è accaduto. Un intervallo più breve del timeout dell’operatore previene la scadenza invece di ripararla dopo. Quando l’operatore cambia il suo comportamento di traduzione, aspettati che quei tempi cambino con esso.

Dimostra entrambe le direzioni, poi dimostra il recupero

La verifica è direzionale, quindi un ping da A a B dimostra metà del progetto e nulla sulla rotta di ritorno. Controlla il percorso di risposta con la stessa ricerca consapevole dell’origine sul concentratore, poi ripeti il test dall’altro lato. Anche le strette di mano nuove fanno parte della prova, perché un tunnel rimasto inattivo un’ora potrebbe testare una mappatura vecchia:

wg show wg0 latest-handshakes
ping -c 3 10.60.20.55
traceroute -n 10.60.20.55

Poi prova il guasto che ti aspetti, non il successo che vuoi. Riavvia il collegamento di una sede e conferma che il tunnel torna senza che una persona tocchi nessuno dei due estremi, perché un progetto che richiede un operatore dopo ogni modifica presso l’operatore è incompleto. Registra il percorso principale, l’alternativa IPv6 quando esiste e il comportamento quando il concentratore non è disponibile. Il concentratore ora fa parte del tuo modello di disponibilità, quindi scrivilo invece di scoprirlo durante un guasto.