Chave estática ou TLS para uma ligação OpenVPN entre dois pares?

Duas máquinas que falam apenas uma com a outra podem manter essa topologia e, ainda assim, obter chaves de tráfego negociadas. A forma da rede e o modo de proteção são escolhas independentes, e é confundi-las que leva as pessoas a tentar renovar um segredo estático substituindo um ficheiro enquanto ambos os daemons continuam a correr. Substituir o ficheiro da chave num par em funcionamento não renova nada. O modo de chave estática, que o OpenVPN 2.6 marca como obsoleto, mantém uma única chave durante toda a vida do túnel, pelo que o ficheiro em disco e a chave em memória só voltam a coincidir depois de ambos os extremos serem reiniciados. Se a renovação automática é o requisito, o modo de proteção tem de mudar.

O que o modo de chave estática não consegue fazer

No modo secreto, ambos os pares partilham uma chave pré-partilhada que cifra e autentica diretamente o túnel. Não há aperto de mão, logo não há mecanismo para qualquer dos lados propor novo material de chave, provar uma identidade ou recuperar de uma divergência sem intervenção do operador. Ambas as propriedades decorrem da ausência de um canal de controlo e não de uma opção em falta, e nenhuma flag de configuração acrescenta uma a este modo.

O manual do OpenVPN 2.6 é explícito ao dizer que a chave persiste até ser gerada uma nova. Isso é aceitável para uma ligação de laboratório ou um par fixo de equipamentos com um procedimento de rotação documentado, e é inaceitável onde um segredo de longa duração constitui um risco real. Uma substituição de ficheiro não cria uma chave nova para um par em funcionamento; cria dois pares em desacordo. Substituir o ficheiro acrescenta, portanto, uma interrupção sem acrescentar rotação.

Também não existe noção de identidade do par para além da posse do ficheiro. Quem tiver a chave é um par, e nada no túnel registra qual dos lados é qual, pelo que a revogação é tudo ou nada.

Passar para TLS sem redesenhar a ligação

O modo TLS acrescenta um canal de controlo e, com ele, a capacidade de negociar chaves do canal de dados. Numa implantação ponto a ponto, um lado assume o papel de servidor e o outro o de cliente, mas a topologia continua a ser uma ligação entre dois pares: cada lado conhece o extremo do outro e não surge nenhum conjunto nem serviço multiusuário. Os papéis são um detalhe do aperto de mão, não uma arquitetura nova.

Dê a cada máquina a sua própria identidade. Cada lado precisa de um certificado e de uma chave privada, da âncora de confiança que valida o outro e de uma regra de verificação de par que nomeie quem é esperado. Não reutilize a chave privada de um par no outro para poupar tempo; isso transforma duas identidades numa só e retira a capacidade de revogar qualquer dos lados em separado. A inscrição é o local para o fazer bem, porque corrigir mais tarde significa reemitir certificados.

Mantenha o contrato de rede inalterado enquanto a proteção muda. Os mesmos endereços de túnel, rotas e serviços permitidos devem aplicar-se antes e depois, para que uma falha durante a migração seja um problema de proteção e não uma surpresa de encaminhamento disfarçada. Anote os endereços e as rotas antes da mudança; compará-los depois é mais rápido do que reconstruí-los de memória.

Algumas implantações também protegem o canal de controlo com a sua própria chave estática, que não roda com o canal de dados. Essa chave guarda o aperto de mão e não a carga útil, pelo que a comprometer expõe a negociação e não o tráfego. Guarde-a à parte do material do canal de dados e atribua-lhe uma data de substituição da qual uma pessoa nomeada é responsável. Rodá-la implica reiniciar ambos os pares numa janela coordenada, razão pela qual merece uma entrada de calendário e não uma memória.

Quem renova o quê, e quando

No modo TLS, a renovação é governada por limites configurados: um intervalo de tempo, uma contagem de bytes ou uma contagem de pacotes. O controlo temporal documentado é aquilo em que a maioria das implantações se apoia, e o valor efetivo mais baixo entre os dois pares pode iniciar a substituição, pelo que aumentá-lo apenas de um lado não trava o evento. Os limites por volume existem porque uma ligação ocupada pode esgotar uma chave muito antes de o relógio o fazer. Nenhum dos limites é uma verificação de saúde e nenhum lhe diz que uma renovação teve sucesso.

É por isso que diagnosticar uma renegociação recorrente a partir de um único ficheiro de configuração é enganador. Leia as definições nos dois pares e depois olhe para a transição no registo em vez de presumir uma falha. Uma renovação que termina de forma limpa parece uma rajada curta de tráfego do canal de controlo, não uma desconexão.

Mantenha os objetos separados na sua cabeça. O certificado prova a identidade de longo prazo e é substituído segundo um calendário que controla. A chave do canal de dados é atualizada automaticamente, e uma troca de autenticação separada, se a implantação a exigir, segue a política da conta e pode precisar das suas próprias disposições para trocas posteriores.

Desativar completamente a renovação, colocando o intervalo a zero, não é uma solução para um registo ruidoso. Converte um evento saudável do ciclo de vida numa chave permanente, o que o devolve à propriedade de que tentava sair.

Aceitar a mudança

Construa a configuração nova a partir do exemplo suportado da versão instalada, e não de um fragmento mínimo antigo cujos algoritmos e caminhos de ficheiro foram herdados de outro lugar. Coordene a mudança para que ambos os pares se alterem em conjunto, e mantenha um caminho de recuperação aprovado caso um lado não arranque. Baixe a ligação deliberadamente em vez de esperar por uma interrupção para testar o retrocesso. Um retrocesso que ensaiou vale mais do que um retrocesso que descreveu.

Teste três coisas: a verificação inicial de identidade é bem-sucedida, o fluxo de aplicação pretendido funciona e uma renovação controlada ocorre sem perder tráfego. Depois leia a transição no registo pelo que ela prova realmente: um novo identificador de chave significa que os pares concluíram uma substituição, não que o túnel se voltou a ligar. Trate-a como prova de um passo e verifique os contadores de tráfego antes de dar a migração por concluída.

O que uma promessa de zero interrupções esconderia é a falha que ainda não viu. Uma renovação que falha, um certificado que expira ou um defeito de caminho ainda podem perturbar a ligação, e nenhum deles é descartado por um ensaio limpo. A propriedade por que vale a pena projetar é mais estreita e mais útil: a substituição rotineira de chaves deixa de ser uma troca manual de ficheiro.