IP estático do OpenVPN por cliente: ifconfig-push, não ipp.txt

Editar uma linha em ipp.txt parece reservar um endereço, e não é. Esse arquivo, nomeado por ifconfig-pool-persist, registra qual endereço um nome comum tinha da última vez para que o pool possa devolver o mesmo quando convier. Nada nele vincula a próxima conexão a esse número.

Execute as verificações abaixo em ordem. Cada uma confirma o mecanismo ou diz para parar e corrigir uma entrada.

Para que serve o arquivo de persistência

O arquivo existe para manter os endereços estáveis entre reinicializações, o que torna as reconexões mais amigáveis e os logs mais fáceis de ler. Ele é lido como histórico e escrito como histórico, e o caminho de alocação continua livre para escolher outro endereço quando a dica não encaixa: outro pool, uma atribuição em conflito ou um cliente que chegou depois que o pool encheu. Por isso uma edição manual pode parecer perfeita no arquivo e não mudar nada na conexão. Trate-o como um cache de decisões passadas e não como fonte de política.

Se você precisa de um endereço específico para um cliente específico, o mecanismo documentado é ifconfig-push, e ele pertence à configuração que possui esse cliente.

Verifique se o cliente correto foi selecionado

Uma atribuição explícita é procurada pelo nome comum do cliente, então um arquivo nomeado para a identidade errada simplesmente nunca é lido. Confirme o que o servidor considera o nome desse cliente, especialmente onde username-as-common-name o altera após a autenticação. Depois confirme que o nome do arquivo corresponde exatamente a esse valor, incluindo maiúsculas e minúsculas.

Considere a concorrência enquanto está aqui. Se duplicate-cn for permitido, vários dispositivos podem apresentar a mesma identidade, e um endereço fixo não pode ser único para todos. Decida se o endereço fixo vale recusar sessões simultâneas para essa identidade, porque esses dois requisitos não podem ser satisfeitos ao mesmo tempo.

Verifique se os números correspondem à topologia

O significado dos argumentos depende da topologia do túnel, e é aqui que um exemplo copiado causa mais dano. Na disposição net30 mais antiga cada cliente ocupa um bloco de quatro endereços, então o push fornece um par de endereços. Na topologia de sub-rede o cliente recebe um endereço mais a máscara do pool, e a forma de par está errada. Leia a topologia da configuração em execução antes de escrever a linha.

# /etc/openvpn/ccd/partner-a   (subnet topology)
ifconfig-push 10.44.0.61 255.255.255.0

Verifique o endereço contra tudo o mais que poderia possuí-lo: outra atribuição explícita, a faixa do pool dinâmico e qualquer rota estática que pressuponha um host fixo. Um endereço que se sobrepõe ao pool funcionará até o pool dá-lo a outra pessoa, e essa falha parecerá aleatória.

Verifique o resultado em uma conexão nova

Uma sessão existente mantém o endereço que recebeu, então o único teste significativo é uma conexão nova. Desconecte o cliente, reconecte e leia o endereço que ele realmente recebeu junto com as rotas que chegaram com ele. Se o endereço ainda for dinâmico, a atribuição não foi aplicada, e o próximo passo é a consulta à configuração e não outra edição do arquivo de histórico.

Mantenha as evidências juntas: o nome do cliente, o arquivo que correspondeu, o endereço atribuído e o pool de onde veio.

Por fim, um endereço de túnel fixo não é uma credencial do dispositivo. Ele identifica um lugar no plano de endereços, enquanto a autenticação ainda se apoia no certificado e na conta. Confundir os dois transforma um conflito de endereços em uma suposição de segurança que ninguém escreveu.