Rota VPN em falta no NetworkManager: política do perfil ou um script?

Liga-se, a interface do túnel aparece e um prefixo de que precisa simplesmente não está na tabela. O passo seguinte costuma ser procurar um script que o adicione. Essa procura leva a respostas que colam um auxiliar OpenVPN num perfil, e metade dessas respostas piora a situação em vez de a melhorar, porque uma rota em falta tem três donos possíveis e só um deles é um script em falta.

Decida qual dono é responsável antes de escrever o que quer que seja.

Três donos, um prefixo em falta

O prefixo pode faltar porque ninguém o forneceu, porque o perfil o recusou ou porque foi instalado num lugar onde não está a olhar. São falhas diferentes e têm correções diferentes.

O primeiro é o mais fácil de verificar: o servidor ou o plug-in alguma vez ofereceram a rota? Um backend que nunca recebeu o prefixo não o pode instalar, e um script auxiliar não pode inventar uma acessibilidade que o par nunca descreveu. O segundo é a política do perfil, que pode suprimir rotas que a ligação levaria de outra forma. O terceiro é uma tabela ou uma regra, que pode guardar a rota num sítio que a consulta predefinida nunca consulta.

Um quarto dono é você, mais tarde: um script que adiciona a rota ao ligar mas não a remove ao desligar. Isso produz um prefixo que sobrevive ao túnel, aponta para uma interface morta e confunde a pessoa seguinte que depurar a máquina.

Leia o perfil antes de adicionar seja o que for

Comece pelas propriedades da ligação guardada. Leia-as sem despejar segredos e use o UUID se o nome do perfil for ambíguo.

nmcli -f vpn.service-type,ipv4.never-default,ipv4.ignore-auto-routes,ipv4.route-table,ipv4.routes connection show office

vpn.service-type diz-lhe qual backend é dono da ligação, e isso importa porque os dados do plug-in são específicos do backend. Uma chave aceite por um plug-in não é uma instrução suportada por outro, pelo que um excerto copiado da documentação de outro cliente não é prova de nada.

ipv4.ignore-auto-routes e ipv4.never-default respondem a perguntas diferentes. O primeiro pode rejeitar rotas que a ligação levaria automaticamente de outra forma, e o segundo controla se o perfil pode tornar-se a rota predefinida. Um perfil que ignora as rotas automáticas e não se apoia em mais nada liga-se de forma limpa e não instala quase nada.

ip -4 rule show
ip -4 route show table all

Esses dois comandos resolvem a terceira possibilidade. Procure o seu prefixo em todas as tabelas, não só na main, e verifique se uma regra de política envia a consulta relevante para outro sítio. Se o prefixo estiver noutra tabela e nada o consultar, não tem uma rota em falta; tem uma consulta que nunca chega a ela.

O que um script não consegue corrigir

Adicionar um script auxiliar dá ao vpn.data do NetworkManager um programa para executar. É um mecanismo real, e é o errado para a maioria destes casos, porque o script recebe o controlo depois de a política do próprio perfil já ter decidido o que aceitar.

O script-security do OpenVPN é a outra confusão recorrente. É uma definição do OpenVPN que determina que scripts o cliente pode executar e o que pode colocar no ambiente deles; o nível 3 permite passar credenciais através do ambiente, o que é uma decisão sobre o tratamento de segredos e não uma correção de encaminhamento. Colá-lo num perfil cujo backend não é OpenVPN, ou aumentá-lo quando nenhum script precisa dele, acrescenta exposição sem acrescentar uma rota.

Depois há o reflexo de reiniciar. Reiniciar o serviço NetworkManager derruba e reconstrói cada ligação gerida, incluindo aquela através da qual está ligado se trabalhar remotamente. É uma ação disruptiva, não um diagnóstico inócuo, e num servidor pode ser a diferença entre uma sessão que sobrevive e uma que não sobrevive.

A decisão, por ordem

Faça três perguntas por ordem. O par forneceu o prefixo, o que o registo do backend ou a sua própria saída de estado mostrará? Se sim, o perfil está configurado para aceitar e instalar rotas, ou está a suprimi-las? Se a rota existir em algum sítio, o caminho de consulta está correto para o tráfego que está a testar?

Só quando a primeira resposta é sim, a segunda é sim e a terceira está correta é que um script suplementar se torna defensável, e mesmo assim deve perguntar se o backend suporta a rota nativamente. A referência de definições de VPN documenta service-type e o dicionário de dados específico do plug-in, e é aí que se deve começar antes de assumir que uma chave existe.

Depois de uma correção aprovada, volte a ligar e teste o destino por endereço e depois por nome, e em seguida desligue e volte a ligar para confirmar que o estado é repetível. Um dono, uma tabela e uma rota que desaparece com o túnel é o resultado que vale a pena.