O OpenVPN continua a empurrar rotas antigas? Verifique o que carregou

Adiciona uma rota, reinicia o serviço, volta a ligar-se e a tabela do cliente fica exatamente como antes. Podem ser verdadeiras duas coisas diferentes: o servidor nunca carregou a sua alteração ou o cliente nunca instalou o que recebeu. Nada têm em comum além do sintoma, por isso o primeiro passo é descobrir qual dos dois casos tem.

A comparação abaixo segue do processo para fora, porque o processo é a única autoridade sobre qual ficheiro está em vigor.

O ficheiro que editou e o ficheiro que o processo lê

Comece pela unit e pela linha de comando que produziu. Num anfitrião systemd, o systemctl cat openvpn@server imprime a linha ExecStart, e uma unit de instância geralmente deriva o seu caminho de configuração do nome da instância, pelo que um daemon iniciado como openvpn@office lê um ficheiro diferente de um iniciado como openvpn@server. Compare isso com o argv do processo em execução. Uma ferramenta de gestão de configuração acrescenta outra forma de perder a alteração: pode escrever um ficheiro correto num local que a unit nunca menciona, e então uma implementação bem-sucedida parece não ter feito nada.

As datas e horas resolvem isso depressa: se o ficheiro for mais recente do que a hora de arranque do processo, o processo não o pode ter lido. O firmware do router acrescenta um terceiro caso, porque muitos modelos guardam as definições na flash e reconstroem a configuração durante o arranque, o que faz da edição de um ficheiro no disco a camada errada por completo.

O que o servidor empurra e o que o cliente instala

Uma rota empurrada tem de sobreviver a dois filtros. No servidor tem de estar na configuração carregada, não num bloco comentado nem num ficheiro específico de cliente cujo nome não corresponda. No cliente, o pull tem de estar ativo e nenhum pull-filter pode estar a descartar a opção. Ligue-se com verbosity 4 e leia as opções empurradas que o cliente relata: se a rota aparecer nessa lista, o servidor fez o seu trabalho e é o cliente que escolhe não a instalar.

Os ficheiros específicos de cliente são uma fonte frequente de confusão. Um ficheiro nomeado segundo o common name do certificado empurra opções apenas para esse cliente, e uma diferença de um caractere pára o envio em silêncio, sem erro de qualquer dos lados. O servidor registra o common name que viu na ligação, por isso compare esse valor com o nome do ficheiro, não com o que pensa que é o nome do cliente.

O prefixo empurrado e a rota de retorno são problemas diferentes

Um cliente que ignora deliberadamente o redirect-gateway para manter o seu caminho local para a internet cria uma segunda falha, sem relação. As sondas do servidor chegam ao endereço do túnel e as respostas nunca chegam, porque uma resposta dirigida ao IP do túnel do servidor é encaminhada pela gateway predefinida normal do cliente. A rota de sub-rede empurrada não tem culpa aqui; o que falta é uma rota que devolva o tráfego da rede do túnel do servidor pelo dispositivo de túnel.

Adicionar essa rota no cliente corrige as respostas às sondas iniciadas pelo servidor. Não substitui a rota de sub-rede empurrada, e o contrário também é verdade, porque as duas descrevem direções de viagem opostas.

Compare as tabelas nas duas pontas

Depois de qualquer alteração, volte a ligar-se e leia a tabela do cliente para o prefixo empurrado e para o dispositivo de túnel. Depois teste nos dois sentidos: do cliente para um anfitrião na sub-rede empurrada, e desse anfitrião de volta ao cliente. Uma rota que existe mas não transporta tráfego significa uma de três coisas: o lado remoto não reencaminha, uma firewall está a descartar o fluxo, ou a resposta não tem caminho de volta.

Mantenha três identificadores juntos: o caminho de configuração, o nome da unit ou da instância e a identidade do cliente com que testou.

Esses três transformam a próxima ocorrência numa verificação de cinco minutos em vez de outra investigação, e são o que um colega precisa quando o túnel passa a ser o problema de outra pessoa.

Um problema de rotas que sobrevive a um reinício muitas vezes não é um problema de encaminhamento de todo; a falha está acima da tabela que continua a ler.