Llegar a un prefijo privado a través de una VPN es un requisito con duración: se mantiene mientras esa conexión es utilizable y termina cuando termina la conexión. Un script de inicio de sesión no puede expresarlo, porque el inicio de sesión y el levantamiento del túnel son momentos distintos, y el túnel que existe al iniciar sesión puede no ser el que transporta tráfico un minuto después. La primera decisión no es qué comando ejecutar. Es qué componente posee el prefijo.

El prefijo necesita un dueño, no un momento

Empieza por escribir el requisito como una frase con sujeto: llega 10.77.0.0/24 a través de la VPN de Oficina mientras esa conexión esté activa. Esa frase nombra el prefijo, la conexión y la condición, y descarta de inmediato dos sustitutos populares: un hook de inicio de sesión y un nombre de interfaz como ppp0 o utun2.

Los nombres de interfaz se asignan en tiempo de ejecución y no son estables entre reconexiones. Un hook que coincide con el nombre que vio la semana pasada o bien no se dispara o se dispara contra la interfaz de otro. Ambos resultados se presentan como un fallo de enrutamiento y no como la suposición obsoleta que son. La misma objeción se aplica a cualquier script atado a un nombre que solo existe mientras un túnel concreto está activo.

Usa una fuente admitida de intención de ruta

La puerta de enlace, un perfil gestionado o el mecanismo de rutas documentado del cliente propietario es donde corresponde esto, siempre que ese mecanismo pueda expresar el requisito. Cuál se aplica depende del protocolo y del proveedor, y las claves no viajan entre ellos, así que un valor que configura un perfil OpenVPN no te dice nada sobre el cliente nativo L2TP o IKEv2.

MechanismCan carry extra prefixesWho owns the lifetime
Gateway-pushed routesOften, if the gateway is configured for itThe connection
Managed profile settingsDepends on the client and profile formatThe profile
Provider tunnel settingsYes, as included and excluded routesThe provider process
Manual commandYes, onceNobody

Para quienes desarrollan túneles de paquetes, los ajustes de túnel IPv4 de Apple exponen explícitamente las rutas incluidas y excluidas, y IPv6 tiene su contraparte. Son API que usa el proveedor, no prueba de que todos los paneles VPN nativos ofrezcan al administrador una lista arbitraria de rutas. Si la combinación actual no puede expresar los prefijos que necesitas, el siguiente paso es una vía de configuración admitida por el operador, no otra aplicación instalada con la esperanza de que se comporte mejor.

La vida útil incluye la limpieza

A veces un ayudante externo es realmente necesario, y cuando lo es, «añade la ruta» es la parte más pequeña de su trabajo. Tiene que saber a qué conexión sirve y qué interfaz usa esa conexión, esperar a que el estado de red relevante se asiente, seguir siendo idempotente cuando se ejecuta dos veces seguidas, y no limpiar nada que no haya instalado él mismo.

Esa última cláusula es la que duele. Un ayudante que borra todas las rutas que coinciden con el prefijo de oficina, tarde o temprano borrará una ruta que no añadió. La caída resultante se achaca al cliente VPN, porque el cliente es la parte que el usuario ve. Decidir qué posee un ayudante antes de escribirlo sale más barato que explicar después por qué una subred local dejó de responder.

La carrera de la reconexión

Piensa en una reconexión rápida. La sesión A cae, la sesión B sube e instala su ruta, y luego por fin se ejecuta la limpieza retrasada de A. Si esa limpieza elimina rutas por prefijo, se lleva consigo el estado válido de B, y la conexión que funcionaba hace un segundo ahora enruta hacia la nada.

Es una carrera de propiedad, y añadir una espera al script solo cambia qué lado la gana. La solución es hacer la limpieza condicional a la identidad: compara la interfaz y la sesión que instaló el ayudante con las que siguen vigentes, y elimina solo cuando coincidan.

Qué probar y qué no puede hacer una ruta

La aceptación debe cubrir cuatro transiciones: la primera conexión, una reconexión a una interfaz distinta, un intento de conexión fallido y la desconexión final. Después de cada una, lee la ruta que el sistema eligió realmente para una dirección del lado remoto, no la que esperabas.

route -n get 10.77.0.5
netstat -rn -f inet

Incluye los casos incómodos en la misma pasada: IPv6 donde haga falta, un prefijo local que se solape con el remoto, y la ruta al propio punto final público de la VPN, que debe seguir funcionando mientras el túnel esté activo. Luego anota qué no es una ruta. Selecciona paquetes; no concede permiso en el lado remoto y no crea un camino de vuelta, y eso siguen siendo requisitos separados con dueños separados.

El resultado que quieres es un prefijo que sigue a su dueño de conexión admitido por cada transición, y no un comando que acertó una vez por casualidad en la máquina donde se escribió.

Artículos relacionados