A segunda entrada VPN de WAN falha enquanto a principal continua a funcionar

O túnel principal mantém-se ativo, os utilizadores continuam a trabalhar e o segundo circuito ISP fica parado independentemente do que alterar. Publicou um endereço para o circuito de reserva, apontou um nome para ele, talvez tenha adicionado uma entrada de reserva ao cliente, e o cliente ou nunca a experimenta ou autentica-se e morre logo depois. Nos casos que analisei, a funcionalidade de failover estava geralmente bem; faltava uma das cinco coisas que tornam uma entrada utilizável. Um nome pode resolver para o endereço de reserva enquanto nada escuta nessa interface, e um ouvinte pode aceitar uma ligação enquanto a resposta sai pela principal. Trate cada WAN como uma entrada separada com o seu próprio contrato e a falha deixa de parecer um erro do cliente.

Cada WAN precisa do seu próprio contrato de entrada

Registe cinco campos por WAN: o nome e o endereço públicos, o transporte e a porta, a interface ou contexto que a termina, a identidade de par que deve apresentar e de onde sai a resposta. Dois circuitos significam dois conjuntos completos. Se o segundo conjunto não tiver interface de terminação ou não tiver caminho de retorno, não tem uma entrada de reserva; tem um registo DNS a descrever uma intenção.

O equipamento e a sua versão também têm de suportar esta disposição. Um registo DNS não abre um serviço noutra interface, e em muitas plataformas o ouvinte é configurado por endereço e não por dispositivo. O IPsec baseado em interface num ASA liga os mapas criptográficos e os grupos de túnel à interface exterior, pelo que um segundo uplink precisa de política aplicada onde esses pacotes chegam realmente. Os desenhos baseados em rotas comportam-se de forma diferente: o ouvinte pode ligar-se a todos os endereços ou a um único endereço nomeado, e essa escolha decide se o ISP B consegue responder de todo.

Verifique se a segunda WAN responde mesmo

Teste de fora dos dois circuitos, não a partir de uma máquina atrás do gateway, e teste o nome exato que o perfil do cliente utiliza. Para um ouvinte TLS, a verificação rápida é openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts executado a partir de um anfitrião fora da sua rede. Quer um aperto de mão concluído cuja cadeia corresponda ao nome no perfil, e não apenas uma porta TCP que aceita uma ligação.

RFC 9525 explica o que o cliente verifica: a identidade que pretendia alcançar, comparada com o certificado que o serviço apresenta. Uma segunda entrada que devolve o certificado da entrada principal, ou um certificado predefinido que não lista nenhum dos nomes, falha este teste mesmo que a porta esteja aberta e a firewall o permita.

Dois padrões explicam a maioria das falhas aqui. Uma ligação que fica pendurada significa normalmente que não há ouvinte nessa interface, uma regra de acesso que só permite as sub-redes principais, ou um equipamento de operadora à frente do segundo circuito a descartar a porta. Um aperto de mão que termina com a identidade errada significa normalmente um trustpoint diferente, um anfitrião virtual predefinido, ou configuração copiada da principal sem ajustar a identidade.

Siga a resposta, não apenas o pedido

A segunda WAN costuma quebrar no caminho de volta. Um pedido chega pelo ISP B, o equipamento responde, e a resposta sai pela rota predefinida no ISP A com um endereço de origem que o cliente nunca pediu. A tradução com estado piora isto: se o mapeamento foi construído para a interface principal, o pacote de retorno falha a tradução ou transporta uma origem que a firewall do cliente descarta. Os fornecedores também descartam endereços de origem que não pertencem ao circuito que lhe entregaram, e é por isso que isto parece um buraco negro unidirecional em vez de um erro de protocolo limpo.

Verifique a decisão de encaminhamento para o tráfego com origem na segunda entrada. A resposta deve sair pela interface por onde chegou o pedido, ou pelo menos transportar um endereço que o lado remoto aceite como pertencente a esse caminho. Em plataformas com encaminhamento por política, isso significa uma regra associada à interface de entrada ou à origem traduzida, mais uma instrução de tradução ligada a cada interface exterior. Capture nas duas interfaces ao mesmo tempo enquanto o cliente se liga; um SYN que chega pelo ISP B com o SYN-ACK a sair pelo ISP A resolve a questão numa única execução.

Dê ao cliente uma forma de saber da segunda entrada

O failover é uma decisão do lado do cliente, e cada família de clientes aprende as alternativas de forma diferente. Num ASA, a lista de servidores de reserva é entregue através dos atributos webvpn da política de grupo, enquanto outros clientes esperam uma lista dentro do perfil ou um segundo perfil manual escolhido pelo utilizador. O guia de políticas de ligação da Cisco descreve tanto a informação de reserva configurada no cliente como a fornecida pelo gateway, e esses detalhes específicos do protocolo não devem ser generalizados a todos os clientes ou modos de túnel. Confirme que mecanismo o cliente implementado suporta antes de construir a segunda entrada em torno do errado.

Seja qual for o mecanismo, o cliente tem de conseguir resolver o nome alternativo antes de perder o caminho principal. Essa dependência é a que as pessoas esquecem: se o nome de reserva for respondido por um resolvedor acessível apenas através do túnel que acabou de falhar, a reserva não pode sequer começar. Publique o segundo nome num resolvedor que responda localmente ou através da internet. Espere uma nova autenticação e uma nova sessão de aplicação após a mudança, porque o failover do cliente não é failover com estado e as sessões duradouras não sobrevivem a ele.

Um endereço em dois fornecedores é um produto diferente

Manter um único endereço público acessível através dos dois circuitos é um serviço de encaminhamento, não uma caixa de verificação na VPN. Exige espaço de endereçamento que ambos os fornecedores estejam dispostos a transportar, anunciado de uma forma que as suas redes aceitem, e é isso que o multihoming com espaço independente do fornecedor e BGP proporciona. Atribuir o endereço do ISP A à interface do ISP B não o leva até lá; o pacote chega a uma rede que nunca anunciou o prefixo e é descartado a montante.

Não precisa de nada disso para publicar duas entradas. Se o cliente consegue manter dois nomes e falhar entre eles, duas entradas independentes bastam, e evita um número de AS, um acordo de peering e um prefixo que tem de ser aceite em todo o lado. Considere a opção de endereço portátil apenas quando precisar realmente de um ponto de entrada estável que os clientes não possam ser reconfigurados para substituir, ou quando o failover baseado em DNS com o seu atraso de TTL for demasiado lento para a indisponibilidade que está a dimensionar.

O que verificar a seguir

Trabalhe de fora para dentro a partir da entrada que falha, por esta ordem: o segundo endereço responde de fora, apresenta a identidade que o cliente espera, a resposta sai pelo caminho por onde o pedido chegou, e o cliente consegue saber o nome antes de precisar dele. Onde a resposta é não, corrija essa camada e volte a testar com o perfil implementado e não com um anfitrião de teste, porque um aperto de mão de laboratório prova menos do que uma ligação concluída do cliente real.

Mantenha um registo curto por WAN, com endereço, porta, interface de terminação, nome do certificado, caminho de retorno e regra de tradução, e reveja-o sempre que um circuito, um dispositivo NAT ou uma versão de cliente mudar. Os caminhos de reserva inativos apodrecem em silêncio: nada alerta para a entrada que ninguém usa até ao dia em que todos dependem dela.