Rutas persistentes para una VPN de Mac: ¿networksetup o un hook de conexión?

Una ruta escrita tras cada conexión resuelve el momento y no la semana. En macOS, la elección duradera suele ser un prefijo guardado con el servicio VPN, porque el servicio lo reinstala en cada conexión y lo elimina cuando el servicio está caído. Las alternativas son una route add transitoria para probar y un hook de conexión para direcciones que solo se conocen tras la negociación.

Decida si la ruta pertenece al servicio o a la sesión

Pregunte de qué depende el prefijo. Si es una red privada fija detrás de un servicio VPN nativo, la ruta pertenece a ese servicio. Si depende de una dirección de par que cambia en cada conexión, un hook o una tarea guiada por estado pueden ser el mejor propietario. Si solo comprueba una ruta para los próximos cinco minutos, una ruta transitoria basta.

La ruta ligada al servicio tiene el ciclo de vida más limpio. Aparece con el servicio y desaparece cuando el servicio no está conectado, así que no puede sobrevivir al túnel al que apunta. Esa propiedad vale más que la comodidad de un comando de una línea.

Una ruta ligada a la sesión pertenece a la interfaz, y ese número cambia sin aviso. Una reconexión puede dar al túnel un nombre utun distinto del que usó la sesión anterior, lo que convierte un comando codificado en una ruta que no apunta a nada o, peor, a otro túnel.

Lea el estado actual de la ruta y del servicio

Empiece por los nombres que el sistema usa realmente. El nombre del servicio en Ajustes de red es el identificador de los comandos siguientes, y la tabla de rutas actual muestra lo que ha instalado el cliente conectado. Lea ambos mientras el túnel está activo.

scutil --nc list
networksetup -listnetworkserviceorder
netstat -rn | head -30
route get 10.20.5.5

Esa consulta muestra qué puerta de enlace e interfaz elegiría el kernel para esta dirección en este momento. Si ya elige el túnel, el prefijo está cubierto y una ruta nueva sería redundante. Si elige el enrutador local, al túnel le falta ese prefijo.

Anote la dirección del par mientras está conectado. Se convierte en el valor de la puerta de enlace en la ruta ligada al servicio, y suele ser el destino que se muestra para la ruta predeterminada del túnel en netstat -rn.

Guarde el prefijo con networksetup

La herramienta networksetup adjunta rutas adicionales a un servicio de red. Para un servicio llamado OfficeVPN y un prefijo privado alcanzado a través del par del túnel, la forma es:

sudo networksetup -setadditionalroutes OfficeVPN 10.20.0.0 255.255.0.0 10.8.0.6
networksetup -getadditionalroutes OfficeVPN

Cada terna tras el nombre del servicio da un destino, su máscara de red y el par del túnel como puerta de enlace. Una sola llamada puede llevar varios prefijos, y una llamada vacía borra la lista guardada. El lector es el paso de verificación; si la lista está vacía, el conjunto no se aplicó al servicio que usted cree.

La puerta de enlace debe ser el par del túnel, no el enrutador físico. Una ruta que nombra la puerta local envía el prefijo privado por la interfaz física, que es el fallo original con pasos extra. Un par obsoleto es la razón más común de que una ruta que parece correcta nunca transporte tráfico. Vuelva a leer el par desde el estado conectado en lugar de copiar una dirección de una nota antigua.

Use route add solo para una prueba

Una ruta directa es útil para demostrar que un prefijo funciona antes de hacerlo permanente. La forma con interfaz evita una consulta de puerta de enlace:

sudo route -n add -net 10.20.0.0/16 -interface utun4

La ruta desaparece en la próxima reconexión y depende del número de interfaz que existe hoy. Eso la convierte en un diagnóstico, no en un despliegue. Si la prueba funciona y la ruta ligada al servicio no, compare primero el valor de la puerta de enlace; es el campo que más a menudo está mal.

Tenga cuidado con los consejos que sustituyen la ruta predeterminada de la VPN para forzar la división. Un cliente que impone un túnel completo puede reinstalar sus rutas tras una reconexión o un refresco de política, así que el cambio manual se deshace en silencio. Un puñado de prefijos privados es un problema de enrutamiento; mantener todo el tráfico de internet local contra una política de túnel completo es una decisión del servidor.

Elija un hook solo cuando la dirección se negocia

Para enlaces basados en PPP como L2TP, macOS ejecuta /etc/ppp/ip-up una vez establecido el enlace. El script recibe el nombre de la interfaz y las direcciones local y remota negociadas, así que puede añadir una ruta que dependa del par que asignó el servidor. Es exactamente el caso que una ruta de servicio fija no puede expresar.

Puede que IKEv2 y los clientes de proveedores no usen en absoluto esa ruta PPP, lo que significa que el script puede quedarse callado toda la sesión. Cuando eso ocurre, una tarea launchd que consulta scutil --nc status y actúa ante un cambio de estado es el mecanismo equivalente, con un pequeño retraso.

Sea cual sea el hook que use, hágalo idempotente y haga que elimine solo las rutas que creó. Un script que borra todas las rutas que mencionan el túnel acabará borrando la ruta que mantiene accesible el servidor VPN, y la conexión caerá en cuanto tenga éxito.

Termine comprobando el destino privado, la navegación normal y un ciclo de reconexión o de reposo. Después inspeccione scutil --dns, porque la resolución de nombres es una política aparte y una ruta que funciona no demuestra que los nombres privados se resuelvan.