Uma linha de servidor que mistura um sufixo CIDR com uma máscara com pontos para o daemon antes mesmo de abrir uma porta. O auxiliar server para IPv4 quer dois argumentos separados: um endereço de rede alinhado e, depois, a máscara de rede em forma com pontos. Tudo o resto nessa linha é inferência, e é na inferência que os tamanhos do pool e as máscaras dos clientes dão errado.

Os dois argumentos que o auxiliar aceita

Escreva primeiro a rede e depois a máscara, sem nada ligado ao endereço:

server 10.72.16.0 255.255.240.0

Esta é a forma para um /20. A linha abaixo é o erro, e falha na análise das opções, não em tempo de execução:

server 10.72.16.0/20 255.255.240.0

Mantenha as duas ideias separadas quando depurar isto. O comprimento do prefixo e uma máscara com pontos descrevem o mesmo intervalo, mas o auxiliar não aceita ambos ao mesmo tempo, e uma linha rejeitada produz um erro de opções que nomeia a diretiva e não a aritmética.

Alinhe a rede antes de escrever a máscara

O primeiro endereço é o endereço de rede do intervalo, não um endereço de cliente conveniente dentro dele. Para um /20 o intervalo vai de 10.72.16.0 a 10.72.31.255, e só o primeiro deles é um argumento de rede válido. Um /21 usa 255.255.248.0 e abrange de 10.72.16.0 até 10.72.23.255, pelo que a sua linha é server 10.72.16.0 255.255.248.0.

Mudar o prefixo muda o intervalo e nada mais. Não muda quantos endereços um único cliente recebe, porque isso é uma propriedade da topologia, não da máscara nesta linha.

Confirme o pool do lado do servidor

Inicie a instância em primeiro plano com registo detalhado e leia as linhas que o auxiliar emite. O pool que construiu é impresso no arranque, o que é mais fiável do que calcular a aritmética à mão:

openvpn --config /etc/openvpn/server.conf --verb 4 --dev tun9 --port 1195

Procure o resumo do pool perto do topo da saída. Ele lista o intervalo que o auxiliar reservou, e se esse intervalo não corresponder à sua intenção, os argumentos na linha estão errados, diga o que disser a aritmética da máscara.

Depois ligue um cliente e encontre a linha que registra o endereço que lhe foi entregue. Esse único endereço, junto ao intervalo do pool, diz-lhe se o cliente ficou dentro do bloco reservado ou noutro lugar que não esperava. Se os dois não coincidirem, corrija os argumentos e não o cliente. Se coincidirem e o cliente continuar sem alcançar nada, o pool nunca foi o problema.

Leia a máscara do cliente com a topologia em mente

Um cliente que mostra um /30 na sua interface de túnel não é prova de um pool avariado. Com endereçamento ponto a ponto cada cliente recebe um bloco pequeno e a máscara da sua interface descreve esse bloco, enquanto o pool do servidor cobre o conjunto. Com uma topologia de sub-rede, a máscara do cliente coincide, em vez disso, com a máscara do pool. A máscara sozinha diz, portanto, que topologia está em jogo, não se o pool foi escrito corretamente.

Verifique a topologia configurada e o endereço atribuído em conjunto antes de tirar uma conclusão:

ip -4 addr show tun0

Se o endereço estiver dentro do pool e a máscara for mais estreita do que o pool, é a topologia a fazer o seu trabalho. Se o endereço estiver fora do pool, o pool está errado, e nenhuma inspeção do lado do cliente o corrigirá.

Alterar um pool em funcionamento

Escolha um intervalo que não se sobreponha ao pool atual, à LAN nem a qualquer rota já enviada aos clientes. A sobreposição é a falha que sobrevive a um reinício e depois, dias mais tarde, surge como um sítio inalcançável a partir de uma direção.

Altere a linha, reinicie e volte a ler o pool de arranque antes de deixar os utilizadores entrar. Se o novo intervalo colidir com algo, a mesma saída de arranque mostra-o de imediato, e reverter é uma edição de uma linha mais outro reinício.

Mantenha o intervalo antigo reservado durante algum tempo após a mudança. Os clientes que se reconectam tarde ainda podem deter um endereço do pool anterior, e um novo intervalo que reutilize esses endereços produz atribuições duplicadas que parecem uma falha de encaminhamento. O manual do OpenVPN 2.6 documenta os argumentos do auxiliar e a sua expansão, o que vale a pena ler antes de assumir que uma diretiva usa a mesma notação que a sua vizinha.

Artigos relacionados