Ligazón sen fíos como respaldo: conmutación encamiñada ou un só segmento?

Dous edificios, unha radio punto a punto e unha VPN de internet que podería servir como segundo camiño. Antes de que o respaldo sexa automático, unha pregunta decide case todo o demais: que debe sobrevivir, a accesibilidade IP entre subredes separadas ou un único segmento Ethernet compartido? Que a radio se comporte como un cable non é un argumento para estender cada trama de difusión por internet. Responda primeiro á pregunta, porque as dúas respostas esixen un control de bucles distinto, comprobacións de estado distintas e ideas distintas do que significa recuperarse.

Decida que debe sobrevivir á caída

Enumere as aplicacións que deben seguir funcionando e anote se dependen da accesibilidade de Layer 3 ou da adxacencia de Layer 2. Compartir ficheiros, as conexións a bases de datos e os servizos web adoitan preocuparse só polas rutas; os protocolos de descuberta, algúns produtos de clúster e todo o que espera un único dominio de difusión preocúpanse pola adxacencia. Un respaldo que restaura o tipo incorrecto de accesibilidade produce un sitio tecnicamente conectado e practicamente inútil.

Escriba esa lista e xúntea ao deseño, porque a resposta adoita moverse en canto o primeiro responsable dunha aplicación oe falar do novo enlace.

Conmutación encamiñada: dous prefixos, un camiño preferido

Con prefixos de sitio distintos, o respaldo é un problema de encamiñamento. Cada encamiñador ten un camiño preferido pola radio e outro menos preferido polo túnel, e a ruta preferida retírase cando a radio deixa de entregar tráfico. O lado oposto necesita a súa propia ruta de retorno, e ambos os lados deben acordar que camiño se prefire en cada dirección para que o tráfico non dea o rodeo longo só nunha dirección.

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

Lea o terceiro comando ademais do segundo: unha regra de política, unha segunda táboa ou unha decisión baseada na orixe poden enviar o tráfico dunha subrede de forma distinta á doutra, e unha única consulta predeterminada ocúltao.

Conmutación ponteada: un segmento, un camiño bloqueante

Se a adxacencia é realmente necesaria, o respaldo debe transportar tramas Ethernet, algo que un túnel IP encamiñado non fai. Algunhas plataformas permiten pontear unha interface VPN dentro dun segmento local, e esas interfaces pasan a ser membros da ponte coas consecuencias consecuentes. Dous camiños de Layer 2 que reenvían á vez forman un bucle, así que o deseño necesita unha árbore de expansión que abranga ambos os sitios e unha declaración clara de que camiño debe bloquear.

Esa é unha decisión de deseño substancial e non unha casilla, e a documentación de pontes da súa plataforma, como a descrición xeral de pontes para pfSense, é o lugar onde confirmar en que participa realmente un membro VPN. Habilitar unha opción de árbore de expansión nun dispositivo non relacionado non demostra nada sobre a disposición de extremo a extremo.

Supervise a fronteira que importa

Unha radio alimentada, unha interface activa e un túnel san describen cada un un feito local. Ningún demostra que un paquete dun edificio chegase a un equipo do outro, e ese é o único feito sobre o que debe actuar a lóxica de conmutación. Supervise un obxectivo máis alá do encamiñador remoto se a política o permite, e supervise ambas as direccións por separado para que un fallo asimétrico sexa visible.

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

Manteña a comprobación barata e acoutada: un intervalo curto, un reconto pequeno e un tempo de espera que encaixe coa tolerancia da aplicación. Un monitor que depende do mesmo camiño que proba informará de éxito ata o momento en que deixe de informar de algo.

Ensaiade ambas as direccións baixo carga

Non copie un único obxectivo de converxencia da topoloxía doutra persoa. O tempo de detección, a converxencia de ruta ou de ponte, a preparación do túnel e a recuperación da aplicación achegan cada un o seu propio atraso, e a suma no seu equipo é o único número que importa. Ensaiade mentres hai tráfico representativo, para que a medición inclúa as colas e as sesións que existen en produción.

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

Probe a restauración con tanto coidado como o fallo. Unha radio inestable que aparece e desaparece arrastrará o tráfico dun lado a outro se a lóxica de preferencia non ten amortiguación, e os usuarios viven iso como peor ca unha caída única limpa. Rexistre o camiño seleccionado en cada etapa, que peticións novas tiveron éxito e que ocorreu coas sesións que estaban abertas cando cambiou o camiño. Ese rexistro é o que converte un segundo cable nunha política operativa.