As rutas VPN adicionais do Mac necesitan un dono, non un script de inicio
Unha ruta engadida unha vez ao iniciar sesión non é unha política de reconexión. Dalle un dono aos prefixos remotos e decide como aparecen, cambian e desaparecen con esa conexión.
Chegar a un prefixo privado a través dunha VPN é un requisito con duración: mantense mentres esa conexión é utilizábel e remata cando remata a conexión. Un script de inicio de sesión non pode expresalo, porque o inicio de sesión e o levantamento do túnel son momentos distintos, e o túnel que existe ao iniciar sesión pode non ser o que transporta tráfico un minuto despois. A primeira decisión non é que comando executar. É que compoñente posúe o prefixo.
O prefixo necesita un dono, non un momento
Comeza escribindo o requisito como unha frase con suxeito: chega 10.77.0.0/24 a través da VPN de Oficina mentres esa conexión estea activa. Esa frase nomea o prefixo, a conexión e a condición, e descarta de inmediato dous substitutos populares: un hook de inicio de sesión e un nome de interface como ppp0 ou utun2.
Os nomes de interface asígnanse en tempo de execución e non son estables entre reconexións. Un hook que coincide co nome que viu a semana pasada ou ben non se dispara ou dispárase contra a interface doutro. Ambos os resultados preséntanse como un fallo de encamiñamento e non como a suposición obsoleta que son. A mesma obxección aplícase a calquera script atado a un nome que só existe mentres un túnel concreto está activo.
Usa unha fonte admitida de intención de ruta
A pasarela, un perfil xestionado ou o mecanismo de rutas documentado do cliente propietario é onde corresponde isto, sempre que ese mecanismo poida expresar o requisito. Cal se aplica depende do protocolo e do provedor, e as chaves non viaxan entre eles, así que un valor que configura un perfil OpenVPN non che di nada sobre o cliente nativo L2TP ou IKEv2.
| Mechanism | Can carry extra prefixes | Who owns the lifetime |
|---|---|---|
| Gateway-pushed routes | Often, if the gateway is configured for it | The connection |
| Managed profile settings | Depends on the client and profile format | The profile |
| Provider tunnel settings | Yes, as included and excluded routes | The provider process |
| Manual command | Yes, once | Nobody |
Para quen desenvolve túneles de paquetes, os axustes de túnel IPv4 de Apple expoñen explicitamente as rutas incluídas e excluídas, e IPv6 ten a súa contraparte. Son API que usa o provedor, non proba de que todos os paneis VPN nativos ofrezan ao administrador unha lista arbitraria de rutas. Se a combinación actual non pode expresar os prefixos que necesitas, o seguinte paso é unha vía de configuración admitida polo operador, non outra aplicación instalada coa esperanza de que se comporte mellor.
A vida útil inclúe a limpeza
Ás veces un axudante externo é realmente necesario, e cando o é, «engade a ruta» é a parte máis pequena do seu traballo. Ten que saber a que conexión serve e que interface usa esa conexión, esperar a que o estado de rede relevante se asente, seguir sendo idempotente cando se executa dúas veces seguidas, e non limpar nada que non instalase el mesmo.
Esa última cláusula é a que doe. Un axudante que borra todas as rutas que coinciden co prefixo de oficina, tarde ou cedo borrará unha ruta que non engadiu. A caída resultante achácaselle ao cliente VPN, porque o cliente é a parte que o usuario ve. Decidir que posúe un axudante antes de escribilo sae máis barato que explicar despois por que unha subrede local deixou de responder.
A carreira da reconexión
Pensa nunha reconexión rápida. A sesión A cae, a sesión B sobe e instala a súa ruta, e logo por fin se executa a limpeza atrasada de A. Se esa limpeza elimina rutas por prefixo, lévaa consigo o estado válido de B, e a conexión que funcionaba hai un segundo agora encamiña cara a ningures.
É unha carreira de propiedade, e engadir unha espera ao script só cambia que lado a gaña. A solución é facer a limpeza condicional á identidade: compara a interface e a sesión que instalou o axudante coas que aínda seguen vixentes, e elimina só cando coincidan.
Que probar e que non pode facer unha ruta
A aceptación debe cubrir catro transicións: a primeira conexión, unha reconexión a unha interface distinta, un intento de conexión fallido e a desconexión final. Despois de cada unha, le a ruta que o sistema elixiu realmente para un enderezo do lado remoto, non a que esperabas.
route -n get 10.77.0.5
netstat -rn -f inetInclúe os casos incómodos na mesma pasada: IPv6 onde faga falta, un prefixo local que se solape co remoto, e a ruta ao propio punto final público da VPN, que debe seguir funcionando mentres o túnel estea activo. Despois anota que non é unha ruta. Selecciona paquetes; non concede permiso no lado remoto e non crea un camiño de volta, e iso seguen sendo requisitos separados con donos separados.
O resultado que queres é un prefixo que segue o seu dono de conexión admitido por cada transición, e non un comando que acertou unha vez por casualidade na máquina onde se escribiu.