Clientes dinâmicos conectam e roteiam bem, mas o único cliente com endereço fixo não alcança o servidor de jeito nenhum. Nada mudou no firewall, e a linha CCD parece plausível. A causa usual é um segundo argumento escrito para uma topologia TUN diferente da que o servidor executa. A falha é silenciosa: o cliente sobe com um endereço e o servidor aceita a conexão, mas nenhum tráfego passa.

No net30 esse campo é um endereço de par; no subnet é uma máscara de sub-rede. As duas formas são alternativas, nunca uma sequência.

As duas formas, lado a lado

Numa implantação net30 tradicional, cada cliente possui um bloco /30: um endereço de rede, dois endereços utilizáveis e um endereço de broadcast. ifconfig-push recebe o endereço do cliente e o endereço do par, e o par é o outro endereço utilizável no mesmo bloco, usado pelo lado do servidor do link ponto a ponto.

# net30: client address and its peer
ifconfig-push 10.99.0.6 10.99.0.5
# topology subnet: client address and the pool netmask
ifconfig-push 10.99.0.20 255.255.255.0

Em topology subnet o cliente compartilha uma sub-rede com o servidor, e a mesma diretiva recebe um endereço e uma máscara de sub-rede. O endereço do próprio servidor vem da diretiva server, não do segundo campo. Misturar as formas produz um cliente que acredita estar num link ponto a ponto enquanto o servidor o roteia como host de sub-rede, ou o contrário. É por isso que uma máscara de sub-rede nunca deve ser combinada com net30.

As duas linhas do bloco são linhas únicas para um arquivo CCD. Um cliente recebe exatamente uma delas.

Leia a topologia que o servidor realmente executa

Leia a configuração em execução em vez do padrão do pacote, porque a topologia pode ter sido definida anos atrás e copiada adiante. Procure topology subnet ou sua ausência e depois verifique como a linha server aloca endereços. Uma configuração que nunca menciona topologia não é o mesmo que uma que define subnet.

Depois leia as configurações recebidas pelo cliente. O endereço, a máscara e o par que ele relata dizem qual interpretação o servidor aplicou.

Mantenha o endereço fixo fora do pool dinâmico

Um endereço fixo deve ficar fora do pool dinâmico, senão dois clientes podem receber o mesmo endereço. Com topologia subnet, nopool na linha server suprime o pool automático, e um intervalo explícito ifconfig-pool define o que os clientes dinâmicos recebem.

dev tun
topology subnet
server 10.99.0.0 255.255.255.0 nopool
ifconfig-pool 10.99.0.100 10.99.0.210 255.255.255.0
client-config-dir /etc/openvpn/ccd

O servidor toma 10.99.0.1 para si, e o endereço fixo do cliente fica fora do intervalo do pool. O arquivo CCD é nomeado pela identidade efetiva do cliente, não pelo nome do arquivo de perfil, e não leva extensão extra. Se username-as-common-name estiver ativo, o nome de usuário autenticado é a identidade a corresponder. Dois dispositivos que compartilham uma identidade também compartilharão o endereço fixo, o que é um problema de política e não de roteamento.

Verifique a atribuição que o cliente realmente recebeu

Reconecte o cliente pretendido e confirme qual arquivo CCD foi selecionado antes de verificar qualquer outra coisa. Depois verifique o endereço, a máscara ou o par, e a rota de volta ao servidor. Um cliente que mostra um endereço de par numa implantação subnet ainda usa a forma errada.

Mudar a topologia afeta cada cliente e cada substituição, então trate como migração e não como conserto de um cliente. Corrigir a linha estática para corresponder à topologia já em uso costuma ser a mudança menor. A referência server-options documenta o auxiliar e as substituições específicas de cliente.

Artigos relacionados