Três tipos de failover OpenVPN no pfSense, três mecanismos

«O failover OpenVPN» no pfSense abrange pelo menos três desenhos não relacionados, e cada um exige um mecanismo diferente. Manter um túnel vivo através de uma ligação de internet de reserva, reconectar-se a outro servidor e encaminhar o tráfego LAN para outro túnel já estabelecido não são variantes de uma mesma funcionalidade. Escolha a falha contra a qual se está a proteger antes de construir um grupo de gateways. O grupo que corrige uma delas não faz nada pelas outras duas.

Nomeie a falha antes de construir um grupo

Escreva a frase que quer que seja verdadeira durante uma falha. «O túnel reconecta-se pelo WAN de reserva» e «a filial continua a chegar à aplicação pelo outro túnel» são frases diferentes. Só a primeira diz respeito ao transporte.

Depois associe-a a um mecanismo. A perda do WAN local é um problema de seleção de interface, um endpoint remoto morto é um problema de lista de ligações, e um caminho inutilizável dentro de um túnel estabelecido é um problema de encaminhamento e de política.

WAN local: mover o transporte

Para um cliente OpenVPN do pfSense, a disposição multi-WAN suportada seleciona um grupo de gateways adequado como a interface à qual o cliente se liga. É isso que permite à ligação exterior sair pelo link de reserva quando o primário falha. Por si só não muda a forma como o tráfego interior é encaminhado.

O lado do servidor do mesmo desenho é separado. Um servidor OpenVPN que deva estar acessível por vários endereços públicos precisa de um listener e de uma política de entrada para cada uma dessas entradas, não apenas de um cliente capaz de marcar por duas ligações. Uma entrada pública a funcionar não é prova de que a segunda está configurada.

Uma regra de encaminhamento por política para pacotes LAN reenviados não é a definição que move uma ligação de transporte VPN gerada localmente. São duas pesquisas diferentes, e alterar uma não altera a outra.

Endpoint remoto: outro servidor

Um remote alternativo é uma funcionalidade da lista de ligações. O cliente tenta a entrada seguinte quando a atual não responde, o que é útil quando um host específico está em baixo e não quando é o seu próprio uplink. As duas falhas parecem semelhantes da secretária de um utilizador e exigem correções diferentes.

Cada candidato tem de ser um substituto real: autenticação compatível, política de cliente compatível e acesso aos mesmos recursos privados. Um segundo nome de host que resolve para a mesma infraestrutura falhada não é uma reserva. Um servidor sem a rota necessária também não é, por mais saudável que pareça o seu handshake.

Este mecanismo também não faz dois túneis reencaminhar ao mesmo tempo. Substitui uma ligação por outra, sequencialmente, e o intervalo entre elas é visível para tudo o que estivesse a correr.

Caminho do túnel: escolher outra saída

Quando dois túneis já estão de pé e quer que o tráfego use o mais saudável, o mecanismo é uma interface VPN atribuída com o seu próprio gateway, mais uma regra de política explícita que envia para lá o tráfego certo. Um grupo de gateways sobre essas interfaces atribuídas pode exprimir prioridade e monitorização.

Esse desenho é sobre seleção, não sobre recuperação. Mover ligações novas para o segundo túnel não diz nada sobre sessões já estabelecidas no primeiro, nem sobre se o lado remoto aceitará o novo endereço de origem. Tratá-lo como mecanismo de recuperação é a forma de definir expectativas demasiado altas.

Se o requisito é que as sessões existentes sobrevivam, diga-o explicitamente. A maioria das implementações não migra um fluxo vivo entre túneis, e desenhar como se o fizessem produz um failover que parece correto num diagrama e deixa cair todas as ligações abertas na prática.

Monitores, NAT e a regra de fecho seguro

Um monitor deve testar algo que o túnel se destina a entregar. Um alvo que responde a partir do par do túnel mas não da rede de aplicações além dele reportará saudável enquanto os utilizadores não veem nada. Um alvo de diagnóstico inalcançável reportará morto enquanto o caminho está bem. Escolha o endereço deliberadamente e confirme que só é alcançável pelo túnel pretendido.

Verifique o NAT de saída para ambas as saídas. Uma tradução a funcionar no primário não descreve o endereço de origem da reserva, e a rede privada remota precisa de uma rota de retorno que corresponda à origem que apresenta. Uma tradução correta num caminho pode estar silenciosamente errada no outro.

Depois decida o que acontece ao tráfego que nunca deve usar o WAN. O pfSense tem um comportamento definido para as regras cujo gateway selecionado está em baixo, e uma regra de passagem ampla posterior ou uma rota predefinida podem desfazer a sua intenção. Escreva o resultado bloqueado como requisito e depois verifique-o derrubando o caminho.

Teste perda e recuperação em separado, com tráfego que esteja autorizado a gerar, e observe três coisas ao mesmo tempo: o WAN que transporta a ligação exterior, o túnel que transporta o pedido da aplicação e o caminho que a resposta toma. Um par de indicadores de gateway verdes não é uma dessas três. O guia multi-WAN da Netgate descreve a ligação de transporte e as alternativas de cliente exportadas de que isto depende.