Dois dispositivos, um certificado OpenVPN: o ciclo de reconexão

Um túnel que sobe e depois reinicia a cada meio minuto geralmente não é um problema de cifra nem de MTU. É uma identidade usada duas vezes. O servidor vê um nome comum familiar, toma a nova sessão como a mais recente, e o dispositivo mais antigo descobre que foi substituído. Do lado do cliente isso parece um tempo de inatividade esgotado e um reinício, e é por isso que a investigação tantas vezes começa no lugar errado.

Comece pelo intervalo de reinício

O intervalo é uma pista antes de qualquer outra coisa. Uma cadência regular que coincide com a janela ping-restart aponta para uma sessão substituída e não para um caminho falho, porque falhas de caminho raramente são tão regulares. Anote o intervalo exato entre reinícios e a linha de motivo no log do cliente. Um tempo esgotado seguido de reinício conta uma história diferente de um handshake falhado.

Verifique quando os reinícios começaram em relação a um segundo dispositivo. Um portátil novo, um telefone ou um perfil copiado para uma máquina de reserva são os gatilhos habituais, e o momento costuma coincidir com o dia em que alguém o configurou.

Anote o intervalo e o motivo. Ambos são provas, e ambos são baratos de recolher.

Leia o que o servidor disse sobre o segundo início de sessão

Num servidor que controla, o log nomeia o nome comum e mostra uma segunda ligação a chegar. Sem duplicate-cn, essa chegada substitui a sessão existente para o mesmo nome, e a mensagem normalmente diz isso sem rodeios. Com duplicate-cn, as duas sessões coexistem e o sintoma muda: os clientes continuam ativos mas partilham um único conjunto de definições por cliente e uma única decisão de revogação. Leia as duas entradas em conjunto, porque a substituição só é visível em sequência.

Num serviço alojado pode não ter qualquer log do servidor. A pista é então o momento: um túnel estável que cai sempre que outra máquina se liga, sem nada no log do cliente além do tempo esgotado.

Compare os blocos de certificado e chave nos dois perfis, não só o nome de anfitrião remoto. Os perfis copiados normalmente diferem apenas no nome do ficheiro.

Separe a identidade do lado do servidor

Emita um certificado por dispositivo através da CA que assina para este servidor. Com Easy-RSA isso significa um nome de cliente separado para cada dispositivo, e o perfil é depois construído a partir desse certificado e da sua chave. O nome comum torna-se a identidade do dispositivo, e é exatamente o que faltava ao servidor. Nomeie-os pelo dispositivo e não pela pessoa, para que uma substituição produza um nome novo.

A chave partilhada do canal de controlo é outra coisa. tls-crypt ou tls-auth protege o canal de controlo de cada cliente e destina-se a ser partilhada. Não é uma identidade de cliente, e substituí-la não corrige um certificado duplicado.

Mantenha o certificado, a chave e qualquer ficheiro de configuração por cliente com o mesmo nome comum, ou o mapeamento quebra na ligação seguinte. Uma discrepância aí produz um cliente que se autentica e depois não recebe nada.

Mantenha endereços e definições alinhados após a separação

Os endereços fixos introduzem uma segunda forma de colisão. Se o servidor os atribui através de ifconfig-pool-persist ou de um ficheiro por cliente, esses registos ainda apontam para o nome antigo. Dois dispositivos podem ficar com o mesmo endereço de túnel mesmo depois de separar os certificados, e essa falha parece diferente do ciclo original.

Atualize o mapeamento ao mesmo tempo que o certificado, depois reconecte ambos os dispositivos e compare os endereços atribuídos. Um endereço duplicado manifesta-se como perda intermitente em vez de uma reconexão limpa.

Envie as definições que devem diferir por dispositivo através do ficheiro próprio desse dispositivo, não através de um modelo partilhado. Um modelo partilhado também torna o próximo duplicado mais difícil de detetar.

Retire a identidade antiga como deve ser

Revoque o certificado quando o hardware é retirado ou falta, em vez de apagar o perfil da máquina antiga. A revogação produz uma nova CRL, e o servidor precisa desse ficheiro onde crl-verify aponta. Com essa diretiva no lugar, uma CRL ausente ou ilegível faz o servidor rejeitar todos os clientes, por isso teste uma conta conhecida depois de cada atualização.

Mantenha um inventário que ligue cada certificado a uma pessoa ou dispositivo, com datas de emissão e de revogação. Esse inventário responde quem ainda tem acesso sem ler nomes de ficheiros, e impede o próximo perfil copiado de reiniciar o ciclo.