Enlace inalámbrico como respaldo: conmutación enrutada o un solo segmento?

Dos edificios, una radio punto a punto y una VPN de internet que podría servir como segundo camino. Antes de que el respaldo sea automático, una pregunta decide casi todo lo demás: qué debe sobrevivir, ¿la accesibilidad IP entre subredes separadas o un único segmento Ethernet compartido? Que la radio se comporte como un cable no es un argumento para extender cada trama de difusión por internet. Responda primero a la pregunta, porque las dos respuestas exigen un control de bucles distinto, comprobaciones de estado distintas e ideas distintas de lo que significa recuperarse.

Decida qué debe sobrevivir a la caída

Enumere las aplicaciones que deben seguir funcionando y anote si dependen de la accesibilidad de Layer 3 o de la adyacencia de Layer 2. Compartir archivos, las conexiones a bases de datos y los servicios web suelen preocuparse solo por las rutas; los protocolos de descubrimiento, algunos productos de clúster y todo lo que espera un único dominio de difusión se preocupan por la adyacencia. Un respaldo que restaura el tipo equivocado de accesibilidad produce un sitio técnicamente conectado y prácticamente inútil.

Escriba esa lista y adjúntela al diseño, porque la respuesta suele moverse en cuanto el primer responsable de una aplicación oye hablar del nuevo enlace.

Conmutación enrutada: dos prefijos, un camino preferido

Con prefijos de sitio distintos, el respaldo es un problema de enrutamiento. Cada enrutador tiene un camino preferido por la radio y otro menos preferido por el túnel, y la ruta preferida se retira cuando la radio deja de entregar tráfico. El lado opuesto necesita su propia ruta de retorno, y ambos lados deben acordar qué camino se prefiere en cada dirección para que el tráfico no dé el rodeo largo solo en una 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 el tercer comando además del segundo: una regla de política, una segunda tabla o una decisión basada en el origen pueden enviar el tráfico de una subred de forma distinta a la de otra, y una única consulta predeterminada lo oculta.

Conmutación puenteada: un segmento, un camino bloqueante

Si la adyacencia es realmente necesaria, el respaldo debe transportar tramas Ethernet, algo que un túnel IP enrutado no hace. Algunas plataformas permiten puentear una interfaz VPN dentro de un segmento local, y esas interfaces pasan a ser miembros del puente con las consecuencias consiguientes. Dos caminos de Layer 2 que reenvían a la vez forman un bucle, así que el diseño necesita un árbol de expansión que abarque ambos sitios y una declaración clara de qué camino debe bloquear.

Esa es una decisión de diseño sustancial y no una casilla, y la documentación de puentes de su plataforma, como la descripción general de puentes para pfSense, es el lugar donde confirmar en qué participa realmente un miembro VPN. Habilitar una opción de árbol de expansión en un dispositivo no relacionado no demuestra nada sobre la disposición de extremo a extremo.

Supervise la frontera que importa

Una radio alimentada, una interfaz activa y un túnel sano describen cada uno un hecho local. Ninguno demuestra que un paquete de un edificio haya llegado a un equipo del otro, y ese es el único hecho sobre el que debe actuar la lógica de conmutación. Supervise un objetivo más allá del enrutador remoto si la política lo permite, y supervise ambas direcciones por separado para que un fallo asimétrico sea visible.

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

Mantenga la comprobación barata y acotada: un intervalo corto, un recuento pequeño y un tiempo de espera que encaje con la tolerancia de la aplicación. Un monitor que depende del mismo camino que prueba informará de éxito hasta el momento en que deje de informar de algo.

Ensayen ambas direcciones bajo carga

No copie un único objetivo de convergencia de la topología de otra persona. El tiempo de detección, la convergencia de ruta o de puente, la preparación del túnel y la recuperación de la aplicación aportan cada uno su propio retraso, y la suma en su equipo es el único número que importa. Ensaye mientras hay tráfico representativo, para que la medición incluya las colas y las sesiones que existen en producció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

Pruebe la restauración con tanto cuidado como el fallo. Una radio inestable que aparece y desaparece arrastrará el tráfico de un lado a otro si la lógica de preferencia no tiene amortiguación, y los usuarios lo viven como peor que una caída única limpia. Registre el camino seleccionado en cada etapa, qué peticiones nuevas tuvieron éxito y qué ocurrió con las sesiones que estaban abiertas cuando cambió el camino. Ese registro es lo que convierte un segundo cable en una política operativa.