Collegamento wireless come riserva: failover instradato o un solo segmento?

Due edifici, una radio punto a punto e una VPN internet che potrebbe servire come secondo percorso. Prima che la riserva diventi automatica, una domanda decide quasi tutto il resto: cosa deve sopravvivere, la raggiungibilità IP tra sottoreti separate o un unico segmento Ethernet condiviso? Il fatto che la radio si comporti come un cavo non è un argomento per estendere ogni trama broadcast su internet. Rispondete prima alla domanda, perché le due risposte richiedono un controllo dei loop diverso, controlli di stato diversi e idee diverse di cosa significhi ripristinare.

Decidete cosa deve sopravvivere all’interruzione

Elencate le applicazioni che devono continuare a funzionare e annotate se dipendono dalla raggiungibilità di Layer 3 o dall’adiacenza di Layer 2. La condivisione di file, le connessioni ai database e i servizi web di solito si preoccupano solo delle route; i protocolli di scoperta, alcuni prodotti cluster e tutto ciò che si aspetta un unico dominio broadcast si preoccupano dell’adiacenza. Una riserva che ripristina il tipo sbagliato di raggiungibilità produce un sito tecnicamente connesso e praticamente inutile.

Scrivete questo elenco e allegatelo al progetto, perché la risposta di solito si sposta appena il primo proprietario di un’applicazione sente parlare del nuovo collegamento.

Failover instradato: due prefissi, un percorso preferito

Con prefissi di sito distinti, la riserva diventa un problema di instradamento. Ogni router ha un percorso preferito via radio e un percorso meno preferito via tunnel, e la route preferita viene ritirata quando la radio smette di consegnare traffico. Il lato opposto ha bisogno della propria route di ritorno, e entrambi i lati dovrebbero concordare quale percorso è preferito in ciascuna direzione, così che il traffico non prenda la strada lunga solo in una direzione.

ip route show | grep -E '10.44\.|10.45\.'
ip route get 10.45.0.10
ip route get 10.45.0.10 from 10.44.0.1

Leggete il terzo comando come il secondo: una regola di policy, una seconda tabella o una decisione basata sull’origine possono inviare il traffico di una sottorete diversamente da un’altra, e una sola ricerca predefinita lo nasconde.

Failover bridged: un segmento, un percorso bloccante

Se l’adiacenza è davvero necessaria, la riserva deve trasportare trame Ethernet, cosa che un tunnel IP instradato non fa. Il bridging di un’interfaccia VPN in un segmento locale è supportato da alcune piattaforme, e queste interfacce diventano poi membri del bridge con le conseguenze che ne derivano. Due percorsi Layer 2 che inoltrano contemporaneamente formano un loop, quindi il progetto richiede uno spanning tree che copra entrambi i siti e una dichiarazione chiara su quale percorso debba bloccare.

È una decisione di progetto sostanziale e non una casella da spuntare, e la documentazione sul bridging della vostra piattaforma, come la panoramica dei bridge per pfSense, è il luogo in cui confermare a cosa partecipa davvero un membro VPN. Abilitare un’opzione di spanning tree su un singolo dispositivo non correlato non dimostra nulla sulla disposizione end-to-end.

Monitorate il confine che conta

Una radio alimentata, un’interfaccia attiva e un tunnel sano descrivono ciascuno un fatto locale. Nessuno di essi dimostra che un pacchetto da un edificio abbia raggiunto un host nell’altro, ed è l’unico fatto su cui la logica di failover dovrebbe agire. Monitorate un obiettivo oltre il router remoto se la policy lo consente, e monitorate le due direzioni separatamente perché un guasto asimmetrico sia visibile.

ping -c 3 -W 2 10.45.0.10
ip -brief link show dev wlan0
ip route get 10.45.0.10

Mantenete il controllo economico e circoscritto: un intervallo breve, un numero piccolo e un timeout che corrisponda alla tolleranza dell’applicazione. Un monitor che dipende esso stesso dal percorso che verifica segnalerà successo fino al momento in cui smetterà di segnalare qualsiasi cosa.

Esercitatevi in entrambe le direzioni sotto carico

Non copiate un unico obiettivo di convergenza dalla topologia di qualcun altro. Il tempo di rilevamento, la convergenza di route o di bridge, la prontezza del tunnel e il ripristino dell’applicazione contribuiscono ciascuno con il proprio ritardo, e la somma sulla vostra apparecchiatura è l’unico numero che conta. Esercitatevi mentre scorre traffico rappresentativo, così che la misura includa le code e le sessioni che esistono in produzione.

sudo ip link set dev wlan0 down
ip route get 10.45.0.10
sudo ip link set dev wlan0 up
ip route get 10.45.0.10

Provate il ripristino con la stessa cura del guasto. Una radio instabile che appare e scompare trascinerà il traffico avanti e indietro se la logica di preferenza non ha smorzamento, e gli utenti lo vivono come peggiore di una singola interruzione pulita. Registrate il percorso scelto in ogni fase, quali nuove richieste hanno avuto successo e cosa è successo alle sessioni aperte quando il percorso è cambiato. Quel registro è ciò che trasforma un secondo cavo in una politica operativa.