Segundo endpoint VPN: o que cobre e o que não cobre

Dois endpoints no papel parecem redundância. Na prática, um segundo endereço só ajuda quando os clientes conseguem alcançá-lo e quando evita a falha para a qual se está a preparar. Dois servidores atrás da mesma ligação de acesso, da mesma conta ou da mesma rede de destino falham juntos. A pergunta útil é qual falha única o segundo endpoint elimina.

Compare o que ambos os endpoints partilham

Liste o que os dois endpoints têm em comum antes de contar o que duplicam. A localização de alojamento, a conta do fornecedor, o trânsito ascendente, o alojamento DNS, a fonte de identidade e o recurso privado atrás do túnel representam uma dependência partilhada ou independente. Duas máquinas virtuais numa região partilham uma falha do fornecedor. Duas regiões sob uma só conta continuam a partilhar a relação de faturação e o plano de controlo que as cria.

A rede de destino merece o mesmo tratamento. Um gateway de reserva saudável não consegue restaurar um NAS que está offline, nem chegar a uma rede de escritório cujo link ascendente caiu. Se ambos os endpoints terminarem na mesma sub-rede privada, o segundo apenas acrescenta um caminho para um destino que já é o único ponto de falha.

A identidade é a dependência que as pessoas esquecem. Clonar o certificado e a configuração para um segundo anfitrião cria dois locais onde a mesma credencial pode ser copiada, e não diz nada sobre como as revogações chegam a ambos.

Decida como um cliente muda

Um segundo endpoint só é útil se o cliente o conhece e o consegue selecionar sem uma chamada ao suporte. Os perfis de ligação do OpenVPN podem conter várias linhas remote com uma política de seleção, e a maioria dos clientes oferece um perfil alternativo num menu. Seja qual for o mecanismo, anote qual os seus utilizadores têm, porque um perfil que não encontram não é failover.

Leia a documentação do cliente sobre mudanças de endereço durante uma sessão. Algumas implementações mantêm o par original durante toda a vida do túnel e só consultam alternativas ao voltar a ligar. Essa distinção decide se um endpoint morto produz uma interrupção breve ou uma sessão que nunca recupera. Teste o caminho de religação em vez de assumir que acontece.

Um endereço de saída alterado também quebra o estado da aplicação. O failover é recuperação, e descrevê-lo como continuidade ininterrupta cria uma expectativa que o transporte não consegue cumprir.

Teste uma falha real

Escolha uma indisponibilidade controlada e execute-a do início ao fim, em vez de confiar no documento de conceção. Pare o endpoint primário e confirme que um cliente autorizado chega à aplicação prevista pela alternativa enquanto os clientes não autorizados continuam sem conseguir. Registe quanto tempo durou a mudança e o que a aplicação viu.

dig +short vpn2.example.net
ip route get 10.20.30.41
journalctl -u openvpn@backup --since '-10 min'

O primeiro comando confirma que o nome de reserva resolve para algo encaminhável antes de precisar dele, e é o teste mais barato aqui. O segundo mostra que interface o núcleo usaria para um destino privado depois de a alternativa estar ativa. O terceiro dá o registo do cliente com o nome do par a que realmente se ligou, e é a única prova de que a mudança ocorreu. Vigie também o comportamento de bloqueio durante o intervalo, porque uma política que deixa escapar tráfego ao mudar é pior do que uma interrupção curta.

Depois devolva o original e confirme se o cliente regressa. Um regresso que acontece por acidente é um comportamento que ninguém planeou.

Anote o que o segundo endereço traz

Resuma a cobertura num parágrafo: que falha o segundo endpoint elimina, que falhas partilha com o primeiro e de que suposições depende a mudança. Nomeie o mecanismo do lado do cliente, bem como as rotas privadas e o comportamento DNS que têm de existir nos dois locais. Uma saída pública para a internet não substitui um gateway privado, e um documento que os trate como permutáveis será acreditado. Acrescente o teste de recuperação que executou, com a data e o resultado.

A independência de um servidor não é independência da conta partilhada nem da rede de destino. É o parágrafo que o diz em voz alta que impede que um segundo endereço seja vendido internamente como alta disponibilidade. Também diz ao próximo operador o que verificar primeiro quando o par falha em conjunto.