Rutes dividides L2TP al Mac: per què no funciona una adreça d'host

La VPN es connecta, la barra de menús ho mostra i un host intern continua sense respondre. En aquesta situació hi ha tres causes candidates, i quina s'aplica depèn de com es va configurar el túnel. O bé l'ordre de ruta va fer servir una adreça d'host on calia una adreça de xarxa, o bé el perfil mateix instal·la una ruta per defecte que engoleix la decisió, o bé el client és un túnel PPP que necessita un ganxo en lloc d'una clau de perfil. Comproveu-les en aquest ordre, perquè la primera és la més barata de descartar.

La destinació és una adreça de xarxa, la màscara descriu el prefix

networksetup -setadditionalroutes pren triples de destinació, màscara de subxarxa i passarel·la. La crida que envia una subxarxa interna pel túnel té aquest aspecte:

sudo networksetup -setadditionalroutes "VPN (L2TP)" 192.168.1.0 255.255.255.0 10.2.0.0

Fixeu-vos en què és la destinació: l'adreça de xarxa, no l'adreça del servidor que intenteu assolir. En el cas que va produir aquest article, l'ordre idèntica amb 192.168.1.20 en aquella posició no va fer res d'útil, i substituir-la per 192.168.1.0 va funcionar immediatament. Mateixa màscara, mateixa passarel·la, un número diferent. Aquesta és tota la fallada en miniatura.

La raó és aritmètica, no política. Una adreça d'host aparellada amb una màscara /24 no descriu 192.168.1.0/24; descriu una cosa que la taula d'encaminament no pot retenir de manera útil, així que l'entrada es rebutja o s'ignora i el túnel acaba portant menys del que preteníeu.

Quan vulgueu exactament un host, feu servir l'adreça d'host amb una màscara 255.255.255.255. Els parells mixtos són on això falla, no l'ús d'una adreça d'host com a tal. Una /32 construïda a partir d'una adreça és una ruta legítima; una /24 construïda a partir d'una adreça és un error.

La crida substitueix la llista, i el nom és literal

Dos comportaments sorprenen la gent al primer intent. L'ordre estableix la llista completa de rutes addicionals en lloc d'afegir-hi, així que una crida que afegeix un prefix elimina en silenci els altres que hi havia abans. Construïu tot el conjunt en una sola invocació.

El nom del servei tampoc no és l'etiqueta que us heu inventat. Llegiu-lo de l'eina i copieu-lo exactament, inclòs el sufix de tipus:

networksetup -listallnetworkservices

Un nom que difereix en un caràcter no produeix cap error que valgui la pena llegir ni cap ruta. Copiar i enganxar és la tècnica correcta aquí, no tornar a escriure de memòria.

Quan el perfil reclama la ruta per defecte

Les rutes dividides perden contra una ruta per defecte per a qualsevol destinació que no cobreixin explícitament, i un perfil L2TP configurat per a túnel complet instal·la exactament això. Si el perfil diu que tot passa pel túnel, la llista de rutes addicionals canvia molt poc. La vostra entrada no és incorrecta; simplement és irrellevant per a les destinacions que no nomena mai. El control d'això normalment és a la configuració d'enviar tot el trànsit del perfil, no en cap ordre de ruta.

Decidiu quin model voleu realment abans d'editar més entrades. El túnel complet amb excepcions és una configuració diferent del túnel dividit amb prefixos concrets, i barrejar els dos produeix una taula que ningú no pot predir.

Si l'organització requereix túnel complet, deixeu d'intentar dividir-lo localment i porteu el requisit a qui posseeixi la política. Una ruta afegida localment que la contradigui serà eliminada per la propera actualització del perfil de tota manera.

Els túnels PPP necessiten un ganxo en lloc d'una clau

Per als túnels basats en PPP, defaultroute és la clau del perfil que crea una ruta per defecte; traieu-la i el client deixa de reclamar cada destinació. Les rutes s'afegeixen després que aparegui la interfície, normalment des de /etc/ppp/ip-up:

#!/bin/sh
/sbin/route add -net 192.168.1.0 -interface ppp0

Manteniu l'script propietat de root i executable, i afegiu una guàrdia al nom de la interfície quan hi hagi més d'un perfil de túnel a la màquina. Un ganxo que s'executa per a cada enllaç PPP i assumeix un sol nom de dispositiu és un error petit amb una vida llarga.

Verifiqueu la divisió amb tres peticions

Captureu la taula mentre esteu connectats i anoteu quina interfície serveix el túnel. Després comproveu la destinació concreta en lloc de confiar en l'estat de sortida de l'ordre que la va crear. Un codi de sortida informa si l'eina va acceptar els arguments, no si el trànsit segueix el camí que preteníeu.

Acabeu amb tres peticions que demostrin la divisió: un host intern per adreça, un nom intern a través del resolutor intern i un lloc públic que encara hauria d'usar la connexió local. Si el lloc públic ara també viatja pel túnel, la divisió no va passar mai, digui el que digui la llista de rutes.

Torneu a connectar i repetiu la petició interna, perquè les rutes afegides a mà poden sobreviure a la interfície que les va fer vàlides i silenciosament converteixen el trànsit en un forat negre després que caigui el túnel.