Rotas empurradas pelo OpenVPN não instaladas: tempo, permissões ou política

O servidor diz que empurrou a rota, o cliente diz que está ligado, e o destino continua inacessível. Três causas produzem exatamente essa imagem. A adição da rota correu antes de o dispositivo existir, o cliente não tinha permissões para alterar a tabela, ou uma política disse ao cliente para ignorar as opções empurradas.

De fora parecem idênticas e exigem correções diferentes. Leia o registo do cliente no ponto onde a decisão da rota é tomada.

Prove que a rota está ausente, não apenas avariada

Comece por provar que a rota está ausente em vez de avariada. No Linux, ip route show dev tun0 lista o que o cliente instalou no dispositivo de túnel. No Windows, route print ou Get-NetRoute mostra o mesmo em forma de tabela.

Uma rota que existe mas não encaminha tráfego é outro problema. Isso desloca a investigação para as regras de encaminhamento e firewall, não para a instalação da rota.

Tempo: a adição correu antes de o dispositivo existir

O cliente analisa o PUSH_REPLY do servidor depois de o canal de controlo estar ativo e de ter configurado a interface. Só então toca na tabela de encaminhamento, com o mecanismo que a plataforma fornecer. O Linux passa por netlink; o Windows usa uma API que exige um token elevado. Um script ou cliente que adiciona rotas assim que lê a configuração pode correr antes de o dispositivo TUN/TAP existir, e o kernel rejeita a adição.

A mesma corrida explica por que uma rota escrita à mão funciona enquanto a automática não: quando a escreve, a interface já está ativa.

route-delay existe para este caso, e route-up nomeia um script que corre depois de a interface e as rotas estarem configuradas. Coloque as rotas que dependem do endereço do túnel nesse gancho em vez de numa fase inicial.

Permissões: quem pode alterar a tabela

Alterar a tabela de encaminhamento do Windows exige um token elevado. Uma GUI iniciada por um utilizador padrão pode definir o endereço do adaptador através do serviço e ainda assim não conseguir adicionar uma rota. O registo mostra então um erro do tipo acesso negado em vez de um push em falta.

Iniciar a GUI como administrador, ou usar o cliente baseado em serviço, altera esse resultado. Uma tarefa agendada que inicia o cliente sem o token necessário não altera.

Verifique com que conta o cliente corre realmente antes de alterar alguma coisa. A versão e o modo de serviço decidem que causas são possíveis, por isso registe ambos ao lado da saída da rota.

Política: as rotas empurradas podem ser descartadas de propósito

route-nopull faz o cliente ignorar as rotas que o servidor empurra, incluindo uma rota predefinida empurrada, enquanto o endereço do túnel continua a ser aceite. As opções DNS e DHCP empurradas são descartadas pela mesma diretiva. Esse cliente não está avariado; espera linhas de rota explícitas na sua própria configuração.

route-noexec é um controlo diferente: impede o cliente de executar alterações de rota por completo. Uma topologia que o cliente não consegue mapear pode produzir um resultado semelhante, com a rota registada como rejeitada em vez de adicionada. Leia a linha de registo que relata a decisão em vez de adivinhar qual das três se aplica. Depois verifique o perfil efetivo, porque um importador ou uma ferramenta de gestão pode adicionar opções que o utilizador nunca editou.

Um perfil que parece limpo num editor de texto pode ainda transportar uma diretiva adicionada em tempo de execução.

Compare a lista de push com a tabela

Depois de ligar, coloque a lista de push do servidor ao lado da tabela do cliente. No Linux isso é ip route show dev tun0; no Windows, route print ou Get-NetRoute. Se a rota está ausente, corrija primeiro a instalação. Se está presente e o tráfego falha, passe para a política de encaminhamento e firewall.

Registe a versão do cliente, a conta com que corre e se é baseado em serviço. Esses três factos dizem à pessoa seguinte que causas foram excluídas.