A rota de reserva VPN flutuante não assume: lista de verificação de failover

A sua rota VPN flutuante está configurada, a distância da reserva é maior do que a da primária e, ainda assim, nada se desloca. Ou desloca-se e volta minutos depois, enquanto a ligação sem fios continua em baixo. Em ambos os casos, algo diferente da falha que lhe interessa decide a elegibilidade da rota.

Execute estas verificações por ordem. Cada uma tem uma condição de paragem, e uma verificação falhada não pode ser salva pelas seguintes. Os exemplos usam a sintaxe RouterOS porque a distância, a acessibilidade do gateway e o salto seguinte recursivo estão todos visíveis na configuração, mas a ordem aplica-se a qualquer router com rotas estáticas monitorizadas.

Nomeie a falha que a reserva tem de cobrir

«A rota primária está em baixo» são quatro observações diferentes. Um rádio que perde o seu par, uma interface que perde a portadora, um gateway remoto que deixa de responder e uma aplicação que deixa de funcionar parecem todos diferentes do lugar do router. Anote para qual deles é o desenho antes de alguém alterar um valor de distância.

Depois verifique a independência. Se o transporte exterior da VPN passa pelo mesmo caminho sem fios, ou por uma ligação de acesso que partilha o mesmo upstream, a reserva não é um segundo domínio de falha e estará em baixo exatamente quando precisar dela. Puxe o cabo primário no papel: se o transporte do próprio túnel morre com ele, a rota flutuante só cobre erros de configuração, não interrupções.

Deixe de pedir à distância que detete alguma coisa

Uma distância maior torna uma rota menos preferida. É todo o trabalho. Enquanto a rota estática primária continuar elegível, a rota flutuante permanece inativa, e isso é um comportamento correto e não um erro. A falha só se torna visível quando a primária é retirada ou marcada como inalcançável.

Para rotas estáticas isso exige um rastreador explícito:

/ip route
add dst-address=10.20.0.0/24 gateway=192.0.2.1 distance=1 check-gateway=ping
add dst-address=10.20.0.0/24 gateway=wg-backup distance=10

Leia o que isso testa: o salto seguinte, não o destino. Um rádio que ainda responde do seu lado local enquanto o encaminhamento para lá está quebrado mantém a rota primária ativa. Esse é o caso silencioso, e a distância mais uma verificação de gateway não o apanham. Se esse caso importa, a deteção tem de vir de algo que observe o lado remoto: uma adjacência de protocolo de encaminhamento, ou uma sonda cujo caminho e regra de resultado você mesmo definiu.

Rastreie para onde vão os pacotes da própria sonda

Uma sonda de saúde também tem rota. Assim que o tráfego de dados passa para a VPN, uma sonda sem restrições para o mesmo endereço remoto pode segui-lo, ter sucesso e ser lida como prova de que a primária recuperou. O tráfego volta a um caminho quebrado e o ciclo repete-se.

Fixe a sonda ao caminho que deve julgar. No RouterOS a forma usual é uma rota de host para o alvo de monitorização através do gateway primário, com um âmbito suficientemente pequeno para que nenhuma outra rota a possa resolver, e é isso que constrói o exemplo de failover recursivo do manual do RouterOS. Confirme-o na tabela viva com a reserva ativa, não a partir do comentário da configuração:

/ip route print detail where dst-address=203.0.113.10
# gateway should still be the primary next hop

Defina o que significa o resultado de uma sonda antes de adicionar alvos

Um alvo que rejeita ICMP ou entra em manutenção parece exatamente uma falha de caminho, e três alvos sem regra dão-lhe apenas três opiniões. Decida a regra primeiro e depois implemente-a: por exemplo, a primária conta como em baixo quando dois de três alvos falham durante dois intervalos consecutivos, escrito no manual de operações onde a próxima pessoa o encontrará.

Ajuste os limites de falha e recuperação para que um pacote perdido não desloque o local. A histerese custa um pouco de tempo de deteção e compra de volta estabilidade. Escolha o intervalo em função de quanto tempo é tolerável uma interrupção, não da rapidez com que a sonda pode correr, e mantenha o retorno mais lento do que o failover para que a primária tenha de provar-se antes de recuperar o tráfego.

Verifique o caminho de retorno e a história das sessões

Um failover que só funciona em saída é meio desenho. O local remoto precisa de uma rota de retorno para o seu intervalo de origem através da VPN, senão o tráfego de retorno chega de um endereço inesperado e embate num estado de firewall que já não corresponde. As sessões existentes quebram mesmo quando as ligações novas funcionam, por isso coloque isso nos critérios de aceitação em vez de prometer a sobrevivência da transferência.

Mantenha o acesso de gestão fora do caminho testado. Se a sua única entrada é através da primária, um teste de failover deixa-o de fora do dispositivo que se está a portar mal.

Execute a sequência de aceitação

Três testes cobrem a maior parte: perda física da primária, uma falha de encaminhamento silenciosa com a interface ainda ativa, e restauração da primária. Para cada um, registe a origem e o salto seguinte da sonda, a rota de destino ativa e uma troca de aplicação permitida e recente nos dois sentidos.

O caso silencioso é o que separa os desenhos. Se a reserva não assume aí, construiu um monitor de ligação em vez de um monitor de caminho. Decida se isso é aceitável e escreva a limitação onde o engenheiro de turno a lerá. Um segundo túnel ligado não é, por si só, uma política de reserva terminada.