Servidor OpenVPN com nopool: declare um intervalo de pool explícito

Os auxiliares do servidor configuram uma sub-rede e depois preenchem-na com um pool dinâmico à sua escolha. Esse padrão é cómodo até que alguns endereços tenham de ficar fora da atribuição — quer estejam reservados para atribuições fixas, quer guardados para um segmento futuro. Suprimir o pool automático e declarar o intervalo por conta própria exige duas linhas e uma decisão deliberada sobre quais endereços não são para atribuição. O resto é disciplina operacional: inventário, aplicação, verificação e reversão.

Esta é uma alteração a um serviço em funcionamento, por isso trate-a como uma tarefa operacional: primeiro inventário, aplicação pelo ciclo de vida normal, verificação com um cliente novo e uma reversão preparada.

Comece pela sub-rede que já tem

Leia a configuração atual do servidor e os endereços que os clientes realmente detêm. A alteração do pool só faz sentido face a essa base, e a base nem sempre é o que o ficheiro sugere, porque um produto gerido ou um gerador de configuração pode ser o proprietário do ficheiro que está a ler.

grep -nE '^(topology|server|ifconfig-pool|max-clients|client-config-dir)' /etc/openvpn/server/lab.conf
ip -4 addr show tun0

Confirme a topologia em vigor. Na topologia de sub-rede cada cliente retira um endereço do pool; os esquemas net30 mais antigos atribuem um bloco pequeno por cliente e a aritmética é completamente diferente. Se o servidor ainda estiver em net30, esta página é o guia de migração errado e os números do pool não significarão o que espera. Verifique essa linha antes de copiar aritmética de endereços de outro sítio.

Anote o endereço do próprio servidor, cada atribuição fixa no diretório de configuração de clientes e qualquer endereço de que dependa uma rota ou uma regra de acesso. São esses os endereços que devem ficar fora do intervalo dinâmico. Anotá-los primeiro é o que torna o intervalo uma decisão em vez de um palpite. Também dá à reversão algo concreto para restaurar.

Adicione nopool e declare o intervalo

A palavra-chave auxiliar aceita nopool, que mantém a configuração da sub-rede e suprime o pool dinâmico automático, como descreve o manual do OpenVPN 2.6. A linha explícita ifconfig-pool fornece depois o intervalo inclusivo pretendido, e a sua máscara de rede corresponde à sub-rede. Ambas as linhas pertencem ao mesmo bloco de servidor, porque um pool sem a sua sub-rede não tem significado. A ordem entre elas só importa para a legibilidade, já que o auxiliar expande o par quando o serviço arranca.

topology subnet
server 10.70.0.0 255.255.255.0 nopool
ifconfig-pool 10.70.0.50 10.70.0.120 255.255.255.0

Ambos os limites são inclusivos, pelo que o exemplo oferece setenta e um endereços. Mantenha o endereço do servidor e cada atribuição fixa fora desse intervalo; uma atribuição fixa dentro do intervalo dinâmico produz uma colisão que depende da ordem das ligações, e é o pior tipo de depurar. Deixe uma margem entre o conjunto reservado e o intervalo se as atribuições fixas forem provavelmente crescer.

O tamanho do intervalo e a concorrência são limites separados. Cem endereços não significam cem clientes simultâneos se max-clients disser o contrário, e um pool maior do que o limite de concorrência é normal e não um desperdício. O importante é que os dois limites sejam escolhidos deliberadamente em vez de herdados de um valor predefinido.

Mantenha as atribuições fixas fora do intervalo dinâmico

Um ifconfig-push específico de um cliente é um mecanismo diferente da atribuição pelo pool e tem de usar parâmetros adequados à topologia ativa. Em modo de sub-rede é um único endereço e máscara de rede; transportar um par net30 porque apareceu num exemplo antigo é um erro frequente.

O histórico de atribuições é uma pista, não uma autoridade. Um ficheiro persist recorda que cliente tinha que endereço, pelo que os clientes que se reconectam tendem a receber o mesmo, e não reserva endereços, não os liberta nem substitui uma atribuição fixa. Se um dispositivo específico tiver de deter sempre um endereço específico, use uma atribuição fixa em vez de confiar no ficheiro persist.

Depois verifique os caminhos que dependem dos endereços. Uma rota enviada aos clientes, uma regra de firewall que admite uma sub-rede ou uma verificação de monitorização que espera um determinado anfitrião podem todos pressupor o intervalo antigo. Alterar o pool sem os ler desloca a falha para um local que parece não estar relacionado.

Aplique pelo ciclo de vida e depois verifique

Aplique a alteração como o serviço recebe normalmente a configuração — quer seja um ficheiro direto mais um reinício, quer uma camada de gestão que regenera o ficheiro. Uma edição manual num ficheiro gerado sobrevive até à geração seguinte, e não mais. Registe que mecanismo é o proprietário do ficheiro, porque o próximo operador precisará de saber onde fazer a mesma alteração. Depois reinicie uma vez e leia o registo antes de convidar um cliente.

systemctl restart openvpn-server@lab
journalctl -u openvpn-server@lab -n 30 --no-pager
# on a fresh client
ip -4 addr show tun0

Ligue um cliente que não estava ligado anteriormente e confirme que o endereço cai dentro do intervalo declarado e fora do conjunto reservado. Depois confirme o caminho de retorno: o cliente deve alcançar o que a política permite e nada mais. Um endereço que corresponde ao plano mas não tem rota funcional não é uma alteração bem-sucedida.

Volte a ligar um cliente que detinha um endereço do intervalo antigo. Deve receber um endereço do novo intervalo, e qualquer estado ao nível da sessão ligado ao endereço antigo deve ter desaparecido. Se mantiver o endereço antigo, algo mais o está a atribuir e o pool não é o proprietário que pensa.

Reverter uma alteração de intervalo

Guarde as três linhas anteriores no seu registo de alterações, não apenas o ficheiro anterior. Restaurá-las e reiniciar devolve a atribuição ao comportamento antigo, e os clientes que se reconectarem depois receberão endereços a partir dele.

Dois avisos pertencem ao registo. Os clientes já ligados quando reverte mantêm os endereços atuais até se reconectarem, pelo que uma reversão não é instantânea em toda a frota. E se o intervalo antigo se sobrepunha a uma atribuição fixa, restaurá-lo restaura também a colisão; essa sobreposição foi a razão da alteração, e precisa de uma correção diferente de uma reversão.

Uma alteração de pool está concluída quando um cliente novo recebe um endereço dentro do intervalo, um endereço reservado nunca é entregue e as rotas e regras que consomem esses endereços continuam a comportar-se como pretendido. Qualquer coisa menos deixa à pessoa seguinte a descoberta de qual das três não é verdadeira.