Por que route-nopull por si só deixa inalcanzable o servidor de ficheiros
Ignorar as rutas empurradas é só a metade dun túnel dividido. Escolle o dono da ruta, engade o prefixo da oficina a man e proba tres fluxos antes de dalo por arranxado.
O servidor de ficheiros ábrese ben, e a videollamada da ventá de ao lado comeza a entrecortarse. Nada vai lento e ningún MTU está mal: o teu cliente aceptou a lista de rutas que lle entregou o servidor, así que agora cada paquete sae polo cortalumes da oficina. A solución non é outra bandeira de axuste senón unha decisión sobre quen é dono da táboa de rutas do cliente. Esa decisión pertence a un só lugar, e os modos de fallo de abaixo dinche que lugar escolliches en realidade.
Decide quen é dono da táboa de rutas
Hai tres donos posibles. O servidor pode empurrar rutas e unha pasarela predeterminada, e entón o cliente instala o que lle digan e convértese nun túnel completo. O perfil do cliente pode tomar a propiedade descartando os empurróns e levando as súas propias liñas de ruta. Un xestor de conexións de escritorio tamén pode ser dono da decisión mediante as súas propias propiedades de ruta e ruta predeterminada.
Cada opción falla dun xeito distinto, e por iso paga a pena ler a táboa antes de editar un perfil. A fila que coincide co teu síntoma é o dono que tes en realidade.
| Owner | Where it lives | Result |
|---|---|---|
| Server | server config, redirect-gateway, pushed routes | client becomes a full tunnel |
| Profile | route-nopull and its own route lines | tunnel up, office prefix missing |
| Manager | never-default plus its own routes | desktop decides, profile ignored |
Escolle un e anótao. Mesturar dous deixa un host cuxa ruta predeterminada contradí a súa propia documentación, e o seguinte enxeñeiro non pode saber que capa gañou. Borra o perdedor de forma explícita.
route-nopull filtra os empurróns, non engade rutas
route-nopull pertence ao perfil do cliente, e a súa orde nese ficheiro é irrelevante porque só descarta os valores que veñen do servidor. Descarta as rutas empurradas, incluída unha ruta predeterminada empurrada, mentres o túnel segue levantándose con normalidade.
A consecuencia que a xente pasa por alto é que as opcións DHCP empurradas van con elas. Os axustes de DNS que envía o servidor tamén se descartan, así que os nomes internos deixan de resolverse aínda que o túnel estea san e o servidor sexa alcanzable por enderezo.
Iso deixa un túnel sen camiño cara ao prefixo da oficina a menos que engadas un ti mesmo: route-nopull seguido de route 10.30.0.0 255.255.0.0 no mesmo perfil. Esa liña leva un enderezo e unha máscara; non nomea un seguinte salto.
Unha forma alternativa engade un token de pasarela, route 10.30.0.0 255.255.0.0 vpn_gateway, que apunta a entrada ao túnel polo seu nome. Os importadores difiren en se traducen esa variante, así que inspecciona a conexión gardada se a entrada falta da táboa do núcleo.
Verifica con consultas de ruta, non cun ping
Un ping dinche que algo respondeu. Unha consulta de ruta dinche que interface elixiría o núcleo, e esa é a pregunta que fixeches en realidade. Catro comandos curtos separan unha ruta ausente dunha ruta que apunta ao dispositivo equivocado.
Le o que instalou o túnel con ip route show dev tun0. Ningunha saída significa cero rutas, o que non é un túnel dividido que funcione, e é o resultado habitual de engadir o filtro sen a liña explícita.
Despois comproba un enderezo da oficina con ip route get 10.30.5.7, e un enderezo de internet corrente con ip route get 1.1.1.1. A segunda debería nomear a interface física; se nomea o túnel, o empurrón non se filtrou en absoluto.
Por último le ip rule, porque unha regra de política deixada por un intento anterior pode anular a táboa que acabas de corrixir. Un perfil correcto cunha regra obsoleta por riba parece exactamente un perfil roto. Borra a regra que engadiches a última vez antes de engadir outra.
As subredes superpostas parecen un túnel roto
Dous rangos privados poden ser idénticos desde o punto de vista do cliente, e aí é onde se culpa un túnel dividido de algo que non causou. Se a oficina reparte o mesmo prefixo que usa o teu router de casa, a ruta do túnel cobre o router e a rede da casa parece desaparecer.
Compara o enderezo da túa propia interface coa ruta que instala o perfil, usando unha listaxe de enderezos simple antes de cambiar nada. A superposición é real, e ningunha opción do perfil a resolve. O que si podes arranxar é o nomeado, para que a seguinte persoa vexa dous rangos en lugar de un.
Os arranxos honestos son renumerar un lado ou traducir enderezos na oficina. Fixar unha única ruta de host ao router funciona ata que cambia o enderezo do router, e entón convértese nun segundo misterio por riba do primeiro.
Fai que a decisión sobreviva a unha reconexión
As entradas escritas a man non sobreviven a unha reconexión, e un xestor de conexións reconstrúe a táboa cada vez que arrinca o perfil. Pon a decisión onde se crea a conexión, xa sexa o perfil ou os axustes gardados do xestor. Despois reinicia a conexión unha vez a propósito en lugar de descubrir o comportamento durante unha chamada. Un perfil que só funciona ata a próxima reconexión non está rematado.
Exercita tres camiños á vez: un host da oficina por enderezo literal, o mesmo host por nome, e un sitio público normal. O do medio depende do servizo de nomes que configuraches tras descartar as opcións DNS empurradas, e é o que falla en silencio.