Endereços de cliente OpenVPN estáticos atrás do OPNsense

Os nomes precisam de endereços que não se movem, e o ficheiro de pool do OpenVPN apenas torna um endereço pegajoso. Perca esse ficheiro, ou reemita um certificado com um nome comum diferente, e o cliente que regressa aterra noutro ponto do pool enquanto o seu registo DNS continua a apontar para o endereço antigo. A resposta duradoura é uma substituição específica do cliente que fixa o endereço, mais uma rede de túnel mais ampla para que os endereços fixados fiquem fora do intervalo dinâmico. A aritmética por trás desse alargamento é onde vive a maior parte da confusão.

O OPNsense guarda essas substituições nas definições específicas do cliente do servidor, indexadas pelo nome comum do certificado, o que faz do nome comum parte do plano de endereços.

Uma concessão pegajosa não é um endereço estático

O ficheiro de pool escreve correspondências de endereço para cliente e devolve-as quando um cliente conhecido se volta a ligar. Isso é comodidade, não um contrato: o ficheiro pode ser regenerado, a correspondência desaparece quando a identidade do cliente muda, e dois servidores que partilham um pool não chegarão a acordo sobre ela. Uma substituição específica do cliente funciona de outra forma, porque o endereço vem da configuração e não do histórico. Também sobrevive a um reinício e a uma reinstalação do equipamento, desde que a substituição seja salvaguardada com o resto da configuração.

A alternativa dinâmica, ligar a VPN ao DNS com um script de ligação de cliente e atualizações dinâmicas, funciona e exige um resolvedor que aceite atualizações mais um script em cada ligação. Num equipamento estás limitado aos pacotes fornecidos pelo fabricante, e é normalmente aí que esse plano para.

A aritmética /30 que ninguém aprecia

Com a topologia net30 predefinida, cada cliente recebe o seu próprio /30: o primeiro endereço utilizável vai para o lado do servidor e o segundo para o cliente. Por isso, as substituições têm de ficar fora da rede de túnel dinâmica do servidor, o que implica alargar primeiro essa rede. Um servidor em 10.8.0.0/24 pode passar para 10.8.0.0/23, deixando metade do intervalo antigo para clientes dinâmicos e a outra metade para substituições. Adicione o /24 original como rede local IPv4 adicional para que o tráfego para ambas as metades entre no túnel.

Cada endereço de substituição tem de cair numa fronteira /30, pelo que o último octeto é múltiplo de quatro. Um /30 em 10.8.1.0 dá ao cliente 10.8.1.2, e é esse o endereço que o registo DNS transporta. Escolher 10.8.1.3 em vez disso produz um cliente que se liga e não consegue passar tráfego, porque o endereço pertence a uma sub-rede que a topologia nunca lhe atribuiu.

O plano é mais fácil de manter se as substituições forem atribuídas de cima do intervalo alargado para baixo, para que o pool dinâmico se expanda para o espaço livre em vez de contornar ilhas fixas.

Redes locais e a zona que os clientes consultam

O tráfego de cliente para cliente precisa da sua própria autorização. A lista de redes locais IPv4 do servidor tem de incluir ambas as metades do intervalo, dinâmica e estática; sem ela, o servidor aceita um pacote de um cliente e não tem política que o deixe passar para outro. O sintoma lê-se como uma falha de DNS, porque o nome resolve e a ligação continua a falhar. Verifique ao mesmo tempo a definição de cliente para cliente, já que uma entrada de rede local sozinha não ativa o encaminhamento entre pares.

Publique os registos na zona que os clientes remotos consultam realmente. Um registo numa zona servida apenas pelo resolvedor da LAN é invisível para um cliente cujo resolvedor empurrado aponta para outro sítio, e acrescentar mais registos à zona errada nunca o repara. Confirme a opção DNS empurrada e o domínio de pesquisa antes de acrescentar seja o que for.

O que verificar numa nova ligação

Volte a ligar o cliente e confirme que o endereço atribuído corresponde à sua substituição antes de testar qualquer outra coisa. Depois resolva o nome a partir de um segundo cliente e ligue-se ao serviço pelo nome, o que exercita o registo DNS, a rota e a firewall em conjunto. Confirme o caminho de resposta no lado do servidor, porque um nome que resolve enquanto o serviço continua inacessível é um problema de encaminhamento ou de política, não de nomes. Mantenha a tabela de substituições junto à lista de certificados para que ambas sejam revistas em conjunto.

Um certificado reemitido com um nome comum diferente deixa de corresponder à sua substituição e devolve o cliente ao pool dinâmico. Conte com isso após qualquer mudança de identidade.