El servidor diu que ha enviat la ruta, el client diu que està connectat, i la destinació continua sent inabastable. Tres causes produeixen exactament aquesta imatge. L’addició de la ruta es va executar abans que existís el dispositiu, al client li faltaven permisos per canviar la taula, o una política va ordenar al client ignorar les opcions enviades.

Des de fora semblen idèntiques i necessiten correccions diferents. Llegiu el registre del client en el punt on es pren la decisió de la ruta.

Demostreu que la ruta és absent, no només espatllada

Comenceu demostrant que la ruta és absent, no que està espatllada. A Linux, ip route show dev tun0 llista què ha instal·lat el client al dispositiu de túnel. A Windows, route print o Get-NetRoute mostra el mateix en forma de taula.

Una ruta que existeix però no reenvia trànsit és un problema diferent. Això desplaça la investigació cap a les regles de reenviament i tallafocs, no cap a la instal·lació de la ruta.

Temps: l’addició es va executar abans que existís el dispositiu

El client analitza PUSH_REPLY del servidor després que el canal de control estigui aixecat i després d’haver configurat la interfície. Només llavors toca la taula d’encaminament, amb el mecanisme que la plataforma proporcioni. Linux passa per netlink; Windows fa servir una API que necessita un testimoni elevat. Un script o un client que afegeix rutes tan bon punt llegeix la configuració pot executar-se abans que existeixi el dispositiu TUN/TAP, i el nucli rebutja l’addició.

La mateixa cursa explica per què una ruta escrita a mà funciona mentre que l’automàtica no: quan l’escriviu, la interfície ja està aixecada.

route-delay existeix per a aquest cas, i route-up anomena un script que s’executa després de configurar la interfície i les rutes. Poseu les rutes que depenen de l’adreça del túnel en aquest ganxo, no en una etapa primerenca.

Permisos: qui pot canviar la taula

Canviar la taula d’encaminament de Windows necessita un testimoni elevat. Una GUI iniciada per un usuari estàndard pot establir l’adreça de l’adaptador mitjançant el servei i tot i així no poder afegir una ruta. Llavors el registre mostra un error d’estil accés denegat en lloc d’un enviament absent.

Iniciar la GUI com a administrador, o fer servir el client basat en servei, canvia aquest resultat. Una tasca programada que inicia el client sense el testimoni necessari no ho fa.

Comproveu amb quin compte s’executa realment el client abans de canviar res. La versió i el mode de servei decideixen quines causes són possibles, així que anoteu totes dues al costat de la sortida de la ruta.

Política: les rutes enviades es poden descartar a propòsit

route-nopull fa que el client ignori les rutes que el servidor envia, inclosa una ruta per defecte enviada, mentre l’adreça del túnel encara s’accepta. Les opcions DNS i DHCP enviades es descarten per la mateixa directiva. Aquest client no és defectuós; espera línies de ruta explícites a la seva pròpia configuració.

route-noexec és un control diferent: atura el client d’executar canvis de ruta del tot. Una topologia que el client no pot mapar pot produir un resultat semblant, amb la ruta registrada com a rebutjada en lloc d’afegida. Llegiu la línia del registre que informa de la decisió en lloc d’endevinar quina de les tres s’aplica. Després comproveu el perfil efectiu, perquè un importador o una eina de gestió pot afegir opcions que l’usuari mai no ha editat.

Un perfil que sembla net en un editor de text encara pot portar una directiva afegida en temps d’execució.

Compareu la llista d’enviament amb la taula

Després de connectar, poseu la llista d’enviament del servidor al costat de la taula del client. A Linux això és ip route show dev tun0; a Windows, route print o Get-NetRoute. Si la ruta és absent, primer arregleu la instal·lació. Si hi és i el trànsit falla, passeu a la política de reenviament i tallafocs.

Anoteu la versió del client, el compte amb què s’executa i si està basat en servei. Aquests tres fets diuen a la persona següent quines causes s’han descartat.

Articles relacionats