Endereços estáveis de OpenVPN devem seguir a identidade, não o IP de origem

Planos de endereços que dizem «este portátil recebe 10.90.0.10» são, na verdade, afirmações sobre identidade: qual dispositivo autenticado pode deter esse endereço. O IP público atual desse dispositivo quase não tem relação com isso, porque NAT e roaming o alteram sem alterar quem é o utilizador. Construir o plano sobre o endereço de origem produz regras que quebram na primeira rede de hotel. Construí-lo sobre a identidade autenticada produz um plano que sobrevive a viagens.

Comece pelo que o servidor consegue verificar e depois decida para que serve o endereço.

Escolha a chave de identidade antes do endereço

Um certificado de cliente separado por dispositivo dá ao servidor uma chave estável e verificável para cada membro, que é a base mais limpa para uma atribuição estática. Uma implantação com autenticação por utilizador pode, em vez disso, basear-se no nome de utilizador, desde que a seleção de configuração siga o mesmo campo. Misturar os dois modelos produz atribuições que correspondem a um certificado para um cliente e a um nome de utilizador para outro, e ninguém consegue prever qual vencerá. Decida qual chave o plano usa antes de escrever uma única reserva.

Com duplicate-cn, várias sessões simultâneas podem apresentar o mesmo nome comum, pelo que um endereço fixado não as consegue identificar individualmente. Isso é uma propriedade do modelo de identidade, não algo que um melhor plano de endereços possa corrigir.

Reserve endereços fora do intervalo dinâmico

Numa rede com topologia de sub-rede como 10.90.0.0/24, guarde os endereços baixos para membros nomeados e coloque o pool dinâmico num intervalo disjunto. Uma atribuição para um membro fixado tem este aspeto ifconfig-push 10.90.0.10 255.255.255.0 no ficheiro que o servidor seleciona para essa identidade. O segundo argumento significa outra coisa em net30, pelo que o exemplo não é neutro em relação à topologia. Leia a topologia antes de o copiar.

A persistência do pool registra os leases recentes e tende a devolver o mesmo endereço, o que é uma comodidade e não uma reserva. Não deixe o ficheiro de persistência tornar-se o registo de propriedade, porque muda com o histórico de ligações e não com a política.

A precedência da atribuição decide quem ganha

O manual documenta uma ordem: uma atribuição explícita gerada durante o client-connect pode produzir efeitos antes de uma entrada client-config-dir, que por sua vez precede a atribuição normal do pool. Essa ordem explica a maioria dos relatos «o endereço fixado não foi aplicado». Significa também que um alocador dinâmico que escreve configuração por sessão pode substituir silenciosamente um ficheiro estático que considerava autoritativo.

Escolha uma camada para deter as atribuições e torne as outras apenas de leitura. Duas camadas que ambas afirmam decidir produzem atribuições que dependem do momento.

Um alocador dinâmico precisa do mesmo modelo

Uma integração client-connect que distribui endereços por sessão é um pequeno alocador com os problemas habituais dos alocadores. Tem de validar a identidade requerente, reservar um endereço de forma atómica, emitir apenas a saída por ligação suportada e libertar a reserva ao desligar ou em caso de falha. Pedidos concorrentes precisam de um bloqueio ou de uma restrição de base de dados, não de uma sequência ler-e-depois-escrever. Sem limpeza, o pool perde endereços até um reinício.

Mantenha o estado do alocador onde o próximo operador o possa ler, e registe a decisão identidade-para-endereço, não apenas o endereço.

Decida se o endereço é política ou comodidade

Se uma regra de firewall ou uma rota permite tráfego de um endereço de túnel, então o endereço participa na política de acesso e uma reatribuição herda essa permissão. Coordene o ciclo de vida da identidade, do endereço e da firewall, ou ligue a regra a algo que não possa ser reatribuído. Endereçamento estável torna a configuração legível; não substitui a autenticação.

Escreva o plano como um inventário com um proprietário por entrada e reveja-o quando um dispositivo for retirado. A reserva não utilizada é a que é reutilizada por acidente.