Ruta VPN ausente en NetworkManager: política do perfil ou un script?

Conéctase, aparece a interface do túnel e un prefixo que necesita simplemente non está na táboa. O paso seguinte adoita ser buscar un script que o engada. Esa busca leva a respostas que pegan un auxiliar de OpenVPN dentro dun perfil, e a metade desas respostas empeora a situación en lugar de mellorala, porque unha ruta ausente ten tres propietarios posibles e só un deles é un script ausente.

Decida que propietario é responsable antes de escribir nada.

Tres propietarios, un prefixo ausente

O prefixo pode faltar porque ninguén o proporcionou, porque o perfil o rexeitou ou porque se instalou nun lugar onde vostede non mira. Son fallos distintos e teñen solucións distintas.

O primeiro é o máis fácil de comprobar: o servidor ou o complemento ofreceron algunha vez a ruta? Un backend que nunca recibiu o prefixo non pode instalalo, e un script auxiliar non pode inventar unha accesibilidade que o par nunca describiu. O segundo é a política do perfil, que pode suprimir rutas que a conexión tomaría doutro xeito. O terceiro é unha táboa ou unha regra, que pode gardar a ruta nun lugar que a consulta predeterminada nunca consulta.

Un cuarto propietario é vostede, máis adiante: un script que engade a ruta ao conectar pero non a elimina ao desconectar. Iso produce un prefixo que sobrevive ao túnel, apunta a unha interface morta e confunde á seguinte persoa que depure a máquina.

Lea o perfil antes de engadir nada

Comece polas propiedades da conexión gardada. Léaas sen verter segredos e use o UUID se o nome do perfil é ambiguo.

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

vpn.service-type dille que backend posúe a conexión, e iso importa porque os datos do complemento son específicos do backend. Unha clave aceptada por un complemento non é unha instrución admitida para outro, así que un fragmento copiado da documentación doutro cliente non é proba de nada.

ipv4.ignore-auto-routes e ipv4.never-default responden preguntas distintas. O primeiro pode rexeitar rutas que a conexión tomaría automaticamente doutro xeito, e o segundo controla se o perfil pode converterse na ruta predeterminada. Un perfil que ignora as rutas automáticas e non se apoia en nada máis conectarase limpiamente e non instalará case nada.

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

Eses dous comandos resolven a terceira posibilidade. Busque o seu prefixo en todas as táboas, non só en main, e comprobe se unha regra de política envía a consulta pertinente a outro sitio. Se o prefixo está noutra táboa e nada o consulta, non ten unha ruta ausente; ten unha consulta que nunca chega a ela.

O que un script non pode arranxar

Engadir un script auxiliar dálle a vpn.data de NetworkManager un programa que executar. É un mecanismo real, e é o equivocado para a maioría destes casos, porque o script recibe o control despois de que a política do propio perfil xa decidise que aceptar.

O script-security de OpenVPN é a outra confusión recorrente. É un axuste de OpenVPN que determina que scripts pode executar o cliente e que pode poñer no seu contorno; o nivel 3 permite pasar credenciais a través do contorno, o que é unha decisión sobre o manexo de segredos e non unha corrección de encamiñamento. Pegalo nun perfil cuxo backend non é OpenVPN, ou subilo cando ningún script o necesita, engade exposición sen engadir unha ruta.

Despois está o reflexo de reiniciar. Reiniciar o servizo NetworkManager derruba e reconstrúe cada ligazón xestionada, incluída aquela pola que está conectado se traballa en remoto. É unha acción disruptiva, non un diagnóstico inocuo, e nun servidor pode ser a diferenza entre unha sesión que sobrevive e unha que non.

A decisión, por orde

Faga tres preguntas en secuencia. O par proporcionou o prefixo, o que mostrará o rexistro do backend ou a súa propia saída de estado? Se si, está o perfil configurado para aceptar e instalar rutas, ou estáas suprimindo? Se a ruta existe nalgún sitio, é correcto o camiño de consulta para o tráfico que está a probar?

Só cando a primeira resposta é si, a segunda é si e a terceira é correcta, un script suplementario se volve defendible, e mesmo entón debería preguntar se o backend admite a ruta de forma nativa. A referencia de axustes de VPN documenta service-type e o dicionario de datos específico do complemento, e é aí onde hai que comezar antes de supoñer que unha clave existe.

Tras unha corrección aprobada, volva conectar e probe o destino por enderezo e logo por nome, despois desconecte e volva conectar para confirmar que o estado é repetible. Un propietario, unha táboa e unha ruta que desaparece co túnel é o resultado que paga a pena.