Como criar uma política de failover de VPN no router sem fugas

O failover funcionou exatamente como estava configurado, e esse foi o problema. Quando o túnel principal caiu, o router passou a rota predefinida para o modem de cabo, os portáteis continuaram a navegar e ninguém telefonou. Dois dias depois, alguém reparou que a partilha das finanças estivera acessível pelo caminho aberto da internet durante seis horas. Uma política de failover de VPN no router não é um truque de encaminhamento; é uma decisão sobre o que o tráfego deve fazer quando o caminho preferido desaparece, e essa decisão tem de existir antes de o caminho desaparecer.

Decida o resultado antes de escolher o detetor

Há normalmente três resultados em cima da mesa: enviar os clientes afetados por um túnel de reserva, deixá-los usar a WAN normal ou bloqueá-los por completo. Anote qual deles se aplica a cada VLAN, SSID ou classe de dispositivo. Uma única regra plana de «passar para a WAN» é a forma como a partilha das finanças acima acabou num caminho público.

Os três não são intercambiáveis. O recurso à WAN mantém um apoio ao cliente a atender telefones, mas expõe nomes internos ao resolvedor local. Um túnel de reserva preserva a política, mas pode acabar num endereço de saída que o lado remoto não aceita. Bloquear é correto para uma VLAN da folha de pagamento e errado para uma rede de convidados que nunca usou o túnel.

Faça corresponder o detetor à falha que realmente receia

O estado do handshake, o estado da interface e o encaminhamento utilizável são três sinais diferentes, e só o último importa ao utilizador. Um par WireGuard pode mostrar um handshake recente enquanto a rede do fornecedor está a descartar pacotes. Um cliente OpenVPN pode ficar em «ligado» depois de a rota que ele impôs ter deixado de resolver.

No pfSense, a disposição prática é um grupo de gateways alimentado pelo dpinger, que sonda um endereço de monitorização e marca um gateway como em baixo quando a perda ou a latência ultrapassa os seus limiares. Aponte essa monitorização para algo além do túnel, como um anfitrião na LAN remota ou um endereço público a que chega através dele. Apontá-la para o próprio endereço de par do túnel mede a parte que já sabe estar viva.

Construa o grupo para que a reserva continue a ser o último recurso

Use níveis em vez de uma lista plana de membros. O principal no nível 1, o túnel de reserva no nível 2 e a WAN no nível 3 apenas para as VLAN cuja política o permita. No pfSense isto vive em System > Routing > Gateway Groups: adicione ambas as gateways, dê-lhes níveis diferentes, defina o Trigger Level como membro em baixo mais perda de pacotes, guarde e depois aplique o grupo como predefinição da interface ou no campo Gateway das regras de firewall que precisam dele.

Para uma instância de cliente OpenVPN no pfSense 2.5 e posterior, a definição Default Gateway da instância decide se o túnel substitui ou não a rota predefinida do sistema. O encaminhamento por regra só se comporta como espera quando a rota que assume existir está realmente instalada. Verifique Status > Gateways depois da alteração em vez de confiar no ícone de estado do túnel.

Duas definições causam a maior parte do flapping. Uma é um intervalo de sonda mais curto do que a própria reconvergência do fornecedor. A outra é um grupo em que o principal e a reserva partilham o mesmo nível, pelo que ambos ficam sempre elegíveis. Acrescente histerese através de limiares de perda e latência antes que os utilizadores sintam as transições por si.

Feche os caminhos que o túnel nunca controlou

Primeiro, as fugas de DNS. O resolvedor continua a responder na WAN e a encaminhar para fora dela, pelo que os nomes continuam a resolver através do ISP enquanto o tráfego está fixado ao túnel. Restrinja as interfaces de saída do resolvedor, empurre o resolvedor interno para os clientes e bloqueie a porta 53 a tudo o resto nas VLAN só de VPN.

O IPv6 precisa da sua própria decisão. Uma LAN de pilha dupla pode perder o túnel e manter uma rota predefinida IPv6 global a funcionar, pelo que os navegadores preferem IPv6 e saem pela WAN enquanto o IPv4 parece perfeitamente contido. Ou encaminha o IPv6 para dentro do túnel, ou deixa de anunciar um prefixo global enquanto o túnel está em baixo. Meia política é pior do que nenhuma, porque parece funcionar.

Depois, o caminho de retorno. Se a saída de reserva usar um endereço de origem diferente, o lado remoto tem de saber como enviar o tráfego de volta para ela, e todos os estados ligados ao endereço antigo já estão mortos. As sessões abertas quando o principal caiu não migram; ficam paradas até expirarem e a aplicação decidir o que fazer.

Teste a queda, o flapping e o caminho de regresso

Desligue o principal com tráfego inofensivo a correr e depois leia quatro coisas: Status > Gateways para o estado dos membros do grupo, pfctl -ss para os estados ainda fixados ao gateway antigo, um traceroute a partir de um cliente para o caminho de saída e uma consulta ao resolvedor para ver que servidor respondeu.

Agora provoque flapping. Suba o principal durante trinta segundos, abaixo durante trinta, duas vezes. Se o tráfego perseguir cada transição, os limiares estão demasiado apertados ou os níveis estão errados. Corrija isso no seu horário, porque caso contrário um fornecedor fá-lo-á no dele.

Por último, confirme que ainda consegue administrar o router. Mantenha um caminho fora de banda, como um cabo de consola, uma VLAN de gestão ou um modem celular. Um teste de failover que o deixa trancado fora é um teste que não consegue terminar, e um router inalcançável não consegue voltar atrás sozinho.

Antes de considerar a política terminada, deve conseguir responder a quatro perguntas sem abrir um terminal: que VLAN podem usar a WAN enquanto o túnel está em baixo, o que o detetor vigia e quanto tempo espera, que servidores de nomes e rotas IPv6 se movem com o caminho, e como volta a entrar se a reserva também falhar. Se alguma resposta for «o que estava por omissão», a política ainda pertence ao router e não a si.