Um único IP de serviço em cada nó OpenVPN: o que ele não faz

Um cliente liga-se a um de vários servidores OpenVPN e depois precisa de um pequeno serviço que corra nesse nó: uma página de estado, um endpoint de métricas, um agente de cópias de segurança. Dar a cada nó o mesmo endereço privado de serviço torna a configuração do cliente idêntica, independentemente do servidor onde aterrou. Essa comodidade é real, e também é fácil de sobreinterpretar: o endereço partilhado diz-lhe a que nó chegou, não que algo seja redundante.

Porque é que o mesmo endereço em cada nó funciona

Cada nó possui o endereço localmente e responde por ele, pelo que um cliente que o alcança através do seu túnel atual obtém o serviço na outra ponta desse túnel. Nada é coordenado entre nós, e nenhum tráfego passa de um nó para outro.

O endereço é um rótulo local, repetido e não replicado. Cada nó responde apenas por si, e nenhum deles encaminha tráfego para o endereço em nome de outro nó. É isso que mantém uma única configuração de cliente válida enquanto os servidores permanecem independentes. É também a razão pela qual o desenho não precisa de qualquer coordenação entre os nós.

É por isso que a mesma configuração funciona em cada servidor sem um protocolo de encaminhamento entre eles. É também por isso que o desenho não diz nada sobre saúde: o endereço existe num nó doente exatamente como num saudável, porque está ligado ao anfitrião e não ao facto de o serviço ser útil.

Atribua-o ao loopback, não ao túnel

Colocar o endereço numa interface de loopback desacopla-o do tempo de vida de qualquer dispositivo de túnel, pelo que uma reconexão ou um recarregamento da configuração não o remove. O endereço existe enquanto o anfitrião existir.

Um endereço em lo não é um filtro. O serviço continua a ter de escutar nele, e a firewall do anfitrião continua a avaliar o caminho de entrada real, que chega pela interface do túnel. Quem assume que loopback significa apenas local acaba a bloquear clientes legítimos ou a expor algo que não pretendia.

Torne a atribuição persistente através da configuração de rede do anfitrião em vez de a voltar a acrescentar a partir de um hook. Um hook de instalação não dispara num nó onde nenhum túnel subiu, e o endereço do serviço não deve depender da atividade do túnel. Coloque o endereço na configuração da interface que a sua distribuição gere, depois reinicie uma vez e verifique. Um reinício é o único teste que sobrevive a uma alteração de configuração posterior.

ip address show dev lo | grep 10.250.0.1
ip address add 10.250.0.1/32 dev lo

Empurre uma rota e signifique um único destino

O cliente precisa de uma rota de anfitrião para o endereço, oferecida pelo servidor a que se liga. Como cada servidor oferece o mesmo destino, o perfil não muda quando o cliente se desloca.

Verifique o que o cliente instalou antes de culpar o serviço.

ip route get 10.250.0.1

Para um serviço HTTP, dê ao endereço um nome e um certificado para esse nome. O IP partilhado não é uma identidade, e não elimina a verificação TLS, nem justifica copiar uma chave privada para cada nó. Um nome que resolve para o endereço partilhado mantém a história do certificado comum e permite-lhe manter uma identidade por nó se precisar.

O que o endereço partilhado não pode fazer

Não proporciona comutação por falha. Se o nó escolhido morrer, o endereço morre com ele, e o cliente tem de se reconectar noutro sítio.

Não migra uma sessão TCP viva, porque uma nova ligação termina num anfitrião diferente que nada sabe da antiga.

Não escolhe um nó saudável, não equilibra carga e não sincroniza dados entre nós. Cada um destes é um mecanismo separado com os seus próprios modos de falha, e fingir que o truque de endereçamento os cobre é como um desenho simples ganha uma reputação imerecida de resiliência. Se dois túneis estiverem ativos ao mesmo tempo, o significado do destino torna-se ambíguo, por isso mantenha explícita a suposição de um único túnel ativo.

Mantenha a identidade do serviço junto ao nome

Escreva o que o endereço significa: alcança o serviço no nó a que o cliente está atualmente ligado. Essa única frase evita a maior parte do mal-entendido que este padrão atrai.

Depois documente as peças em conjunto: o endereço, a interface em que vive, a rota que o servidor empurra, e o nome e o certificado que o serviço apresenta. Quatro factos pequenos que um leitor futuro pode verificar, na ordem em que os irá confirmar.

Se o requisito é um destino estável para um serviço local ao nó, o padrão encaixa e custa quase nada.

Se o requisito é disponibilidade, suba uma camada: um balanceador de carga, um nome de serviço com verificações de saúde, ou um sistema de orquestração que já sabe como substituir um nó.

Decidir isso cedo mantém o endereço partilhado aquilo que é, um rótulo cómodo, em vez de um componente de quem se espera silenciosamente trabalho para o qual nunca foi desenhado.