Uma conta VPN em dois servidores: três livros de estado

Uma conta que consegue iniciar sessão em qualquer de dois nós VPN levanta uma questão de desenho muito antes de levantar uma questão de software. A visão da conta, a rede que cada nó possui e a sessão que um cliente ligado mantém são três tipos diferentes de estado, e falham de formas distintas quando os copia de um lado para o outro. Copiar os três para um único sistema é uma forma comum de perder um deles.

Percorra os três livros abaixo por ordem. Cada um pergunta o que é autoritativo, o que é local e o que acontece quando o outro nó não existe, e as respostas não decorrem umas das outras.

Quem pode ligar-se: uma autoridade, muitos nós

Comece pelo livro de admissão: que fonte de identidade é autoritativa, que emissores de certificados são de confiança, que contas são elegíveis, que segundo fator se aplica e a que pode chegar cada conta. Depois anote como cada nó fica a saber das mudanças, e com que rapidez.

Uma base de dados partilhada é um componente possível dessa resposta. Não é prova de que toda a política relevante viva ali, nem de que cada nó aplique uma mudança no mesmo instante. Uma conta desativada no nó A mas ainda aceite no nó B significa que o processo de saída não terminou.

Decida o que faz um nó quando a autoridade está inacessível. Aceitar credenciais em cache durante uma falha é uma escolha de política com um custo de segurança, e recusá-las é uma escolha de política com um custo de disponibilidade. Ambas são defensáveis; deixá-lo sem documentação não é.

Mantenha a autoridade do emissor separada dos dados da conta. Vários gateways podem confiar na mesma CA sem deter a sua chave de assinatura, e cada nó continua a precisar do seu próprio certificado de servidor e da sua própria relação de confiança do lado do cliente.

O que um nó possui: endereços e rotas

O segundo livro é local a cada nó: endereço de escuta, identidade do servidor, conjunto de endereços, rotas para recursos privados, política do resolvedor e como o tráfego sai para a internet. A mesma conta pode ser servida por qualquer dos dois nós, enquanto estes objetos permanecem distintos.

O caminho de retorno é a parte que se esquece. Se ambos os nós distribuem endereços do mesmo conjunto, a rede privada não consegue dizer a que nó pertence um dado cliente, e a resposta pode ir para o lugar errado. Conjuntos diferentes também precisam de rotas e permissões, por isso um intervalo de números distinto não é um desenho completo.

Dirija os clientes para um nó deliberadamente. A seleção de DNS, as listas de pontos finais do cliente e um serviço de front-end são mecanismos diferentes com comportamentos diferentes de saúde e de comutação por falha. Escolher um está bem; tratar o «equilíbrio de carga» como o desenho deixa o caminho de retorno e o comportamento em caso de falha indefinidos.

Um exemplo de produto documentado ajuda aqui. A documentação de replicação da Pritunl trata a rede VPN como um objeto por réplica, e os clientes em réplicas diferentes precisam de rotas e conectividade adicionais para se alcançarem. É um arranjo específico do produto, não uma receita para o Community OpenVPN, mas mostra por que acrescentar uma réplica muda a rede e não apenas o arquivo de contas.

O que é uma sessão: estado vivo, não uma linha

O terceiro livro é a sessão ativa. Um cliente ligado tem estado de protocolo e uma atribuição de rede no nó que o aceitou. O facto de a conta ser conhecida no outro nó não dá a esse nó a sessão, as chaves ou a capacidade de continuar os pacotes.

Seja explícito sobre o que acontece quando um nó falha. O resultado suportado pode ser uma reconexão ao outro nó com autenticação nova e um endereço novo, após o que a aplicação recupera à sua maneira. Se for exigida uma transferência sem interrupção, esse requisito precisa de apoio explícito na implementação, não de uma inferência da replicação da base de dados. Escreva a resposta onde o engenheiro de serviço a possa encontrar.

As regras de capacidade precisam do mesmo tratamento. Um limite de duas sessões simultâneas por conta só pode ser aplicado entre nós se alguma autoridade tiver uma visão coordenada dos lugares ocupados. Listas locais a cada nó e um registo histórico da conta não somam essa visão.

Testar os três livros

Exercite cada um em separado. Inicie sessão pelo nó A, depois pelo nó B, e confirme que ambos conseguem com os intervalos de endereços esperados. Retire uma identidade e verifique os dois nós, não apenas o que testou por acaso. Depois pare um nó e observe o que o cliente e a aplicação privada fazem realmente.

Inclua o caminho de retorno no teste de aceitação. Um cliente que se liga a B mas não consegue receber respostas de um recurso atrás de A passou a verificação de admissão e falhou a de rede, e essa distinção deve aparecer no relatório.

O desenho de uma conta multi-nó só está completo quando os três livros têm um proprietário explícito, um caminho de mudança e um comportamento em caso de falha. Copiar um ficheiro de configuração entre nós não responde a nenhuma dessas perguntas.