Como construír unha política de conmutación por erro de VPN no enrutador sen fugas

A conmutación por erro funcionou exactamente como estaba configurada, e ese era o problema. Cando caeu o túnel principal, o enrutador moveu a ruta por defecto ao módem de cable, os portátiles seguiron navegando e ninguén chamou. Dous días despois alguén notou que o recurso compartido de finanzas estivera accesible pola vía aberta de internet durante seis horas. Unha política de conmutación por erro de VPN no enrutador non é un truco de enrutamento; é unha decisión sobre que debe facer o tráfico cando a ruta preferida xa non está, e esa decisión debe existir antes de que a ruta desapareza.

Decide o resultado antes de escoller o detector

Normalmente hai tres resultados sobre a mesa: enviar os clientes afectados por un túnel de reserva, deixalos usar a WAN normal ou bloquealos de todo. Anota cal se aplica a cada VLAN, SSID ou clase de dispositivo. Unha única regra plana de «cambiar á WAN» é como o recurso de finanzas de arriba acabou nunha ruta pública.

Os tres non son intercambiables. A reserva pola WAN mantén o servizo de soporte atendendo teléfonos mentres expón os nomes internos ao resolvedor local. Un túnel de reserva conserva a política, pero pode aterrar nunha dirección de saída que o outro extremo non acepta. O bloqueo é correcto para unha VLAN de nóminas e incorrecto para unha rede de convidados que nunca usou o túnel.

Axusta o detector ao fallo que realmente temes

O estado do handshake, o estado da interface e o reenvío utilizable son tres sinais distintos, e ao usuario só lle importa a última. Un par de WireGuard pode mostrar un handshake recente mentres o upstream do provedor tira paquetes a un burato negro. OpenVPN o cliente pode quedar en «conectado» despois de que a ruta que empurrou deixase de resolverse.

En pfSense a disposición práctica é un grupo de portas de enlace alimentado por dpinger, que sondea unha dirección de monitorización e marca unha porta como caída cando a perda ou a latencia superan os seus limiares. Apunta esa monitorización a algo máis aló do túnel, como un host na LAN remota ou unha dirección pública á que chegas a través del. Apuntala á propia dirección de par do túnel mide a parte que xa sabes que está viva.

Constrúe o grupo para que a reserva siga sendo o último recurso

Usa niveis en lugar dunha lista plana de membros. Primario no nivel 1, túnel de reserva no nivel 2, WAN no nivel 3 só para as VLAN cuxa política o permita. En pfSense isto está en System > Routing > Gateway Groups: engade ambas as portas de enlace, dálles niveis distintos, pon Trigger Level en member down plus packet loss, garda e despois aplica o grupo como predeterminado da interface ou no campo Gateway das regras de firewall que o necesiten.

Para unha instancia de cliente OpenVPN en pfSense 2.5 e posteriores, o axuste Default Gateway da instancia decide se o túnel substitúe ou non a ruta por defecto do sistema. O enrutamento de políticas por regra só se comporta como esperas cando a ruta que supós que existe está realmente instalada. Comproba Status > Gateways despois do cambio en lugar de confiar na icona de estado do túnel.

Dous axustes causan a maior parte do parpadeo. Un é un intervalo de sonda máis curto que a reconverxencia do propio provedor. O outro é un grupo onde primario e reserva comparten nivel, así que ambos seguen sendo elixibles todo o tempo. Engade histérese con limiares de perda e latencia antes de que os teus usuarios sintan as transicións por ti.

Pecha as rutas que o túnel nunca posuíu

Primeiro as fugas de DNS. O resolvedor segue respondendo na WAN e reenviando por ela, así que os nomes seguen resolvéndose a través do ISP mentres o tráfico está fixado ao túnel. Restrinxe as interfaces de saída do resolvedor, empuxa o resolvedor interno aos clientes e bloquea o porto 53 para todo o demais nas VLAN só-VPN.

IPv6 necesita a súa propia decisión. Unha LAN de dobre pila pode perder o túnel e conservar unha ruta por defecto global IPv6 que funciona, así que os navegadores prefiren IPv6 e saen pola WAN mentres IPv4 parece perfectamente contido. Ou enrutas IPv6 dentro do túnel ou deixas de anunciar un prefixo global mentres o túnel está caído. Media política é peor que ningunha, porque parece que funciona.

Despois a ruta de retorno. Se a saída de reserva usa unha dirección de orixe distinta, o outro extremo debe saber como enviar o tráfico de volta, e cada estado ligado á dirección antiga xa está morto. As sesións abertas cando caeu o primario non migran; quedan paradas ata que caducan e a aplicación decide que facer.

Proba a caída, o parpadeo e o camiño de volta

Quita o primario con tráfico inofensivo en marcha e despois le catro cousas: Status > Gateways para os estados dos membros do grupo, pfctl -ss para os estados aínda fixados á porta antiga, un traceroute desde un cliente para a ruta de saída e unha consulta ao resolvedor para ver que servidor respondeu.

Agora fai que parpadee. Sobe o primario trinta segundos, báixao trinta, dúas veces. Se o tráfico persegue cada transición, os limiares están demasiado axustados ou os niveis son incorrectos. Arranxa iso segundo o teu calendario, porque se non un provedor faráo segundo o seu.

Por último, confirma que aínda podes administrar o enrutador. Mantén unha ruta fóra de banda como un cable de consola, unha VLAN de xestión ou un módem celular. Unha proba de conmutación por erro que te deixa fóra é unha proba que non podes rematar, e un enrutador inalcanzable non pode volver por si só.

Antes de dar a política por rematada, deberías poder responder catro preguntas sen abrir un terminal: que VLAN poden usar a WAN mentres o túnel está caído, que vixía o detector e canto espera, que servidores de nomes e rutas IPv6 se moven coa ruta, e como volves entrar se a reserva tamén falla. Se algunha resposta é «o que fose o valor por defecto», a política segue pertencendo ao enrutador e non a ti.