Rutas persistentes para unha VPN de Mac: networksetup ou un hook de conexión?

Unha ruta escrita tras cada conexión resolve o momento e non a semana. En macOS, a elección duradeira adoita ser un prefixo gardado co servizo VPN, porque o servizo reinstálao en cada conexión e retírao cando o servizo está caído. As alternativas son un route add transitorio para probar e un hook de conexión para enderezos que só se coñecen tras a negociación.

Decida se a ruta pertence ao servizo ou á sesión

Pregunte de que depende o prefixo. Se é unha rede privada fixa detrás dun servizo VPN nativo, a ruta pertence a ese servizo. Se depende dun enderezo de par que cambia en cada conexión, un hook ou unha tarefa guiada polo estado poden ser o mellor propietario. Se só comproba unha ruta para os próximos cinco minutos, unha ruta transitoria abonda.

A ruta ligada ao servizo ten o ciclo de vida máis limpo. Aparece co servizo e desaparece cando o servizo non está conectado, así que non pode sobrevivir ao túnel ao que apunta. Esa propiedade vale máis que a comodidade dun comando dunha liña.

Unha ruta ligada á sesión pertence á interface, e ese número cambia sen aviso. Unha reconexión pode dar ao túnel un nome utun distinto do que usou a sesión anterior, o que converte un comando codificado nunha ruta que non apunta a nada ou, peor, a outro túnel.

Lea o estado actual da ruta e do servizo

Comece polos nomes que o sistema usa realmente. O nome do servizo en Axustes de rede é o identificador dos comandos seguintes, e a táboa de rutas actual mostra o que instalou o cliente conectado. Lea ambos mentres o túnel está activo.

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

Esa consulta mostra que porta de enlace e interface escollería o núcleo para este enderezo neste momento. Se xa escolle o túnel, o prefixo está cuberto e unha ruta nova sería redundante. Se escolle o encamiñador local, ao túnel fáltalle ese prefixo.

Anote o enderezo do par mentres está conectado. Convértese no valor da porta de enlace na ruta ligada ao servizo, e normalmente é o destino que se mostra para a ruta predeterminada do túnel en netstat -rn.

Garde o prefixo con networksetup

A ferramenta networksetup engade rutas adicionais a un servizo de rede. Para un servizo chamado OfficeVPN e un prefixo privado alcanzado polo par do túnel, a forma é:

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

Cada terna tras o nome do servizo dá un destino, a súa máscara de rede e o par do túnel como porta de enlace. Unha soa chamada pode levar varios prefixos, e unha chamada baleira borra a lista gardada. O lector é o paso de verificación; se a lista está baleira, o conxunto non se aplicou ao servizo que vostede cre.

A porta de enlace debe ser o par do túnel, non o encamiñador físico. Unha ruta que nomea a porta local envía o prefixo privado pola interface física, que é o fallo orixinal con pasos extra. Un par obsoleto é a razón máis común de que unha ruta que parece correcta nunca transporte tráfico. Volva ler o par desde o estado conectado en lugar de copiar un enderezo dunha nota antiga.

Use route add só para unha proba

Unha ruta directa é útil para demostrar que un prefixo funciona antes de facelo permanente. A forma con interface evita unha consulta de porta de enlace:

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

A ruta desaparece na próxima reconexión e depende do número de interface que existe hoxe. Iso convértea nun diagnóstico, non nun despregamento. Se a proba funciona e a ruta ligada ao servizo non, compare primeiro o valor da porta de enlace; é o campo que máis a miúdo está mal.

Teña coidado cos consellos que substitúen a ruta predeterminada da VPN para forzar a división. Un cliente que impón un túnel completo pode reinstalar as súas rutas tras unha reconexión ou un refresco de política, así que o cambio manual desfaise en silencio. Un puñado de prefixos privados é un problema de encamiñamento; manter todo o tráfico de internet local contra unha política de túnel completo é unha decisión do servidor.

Escolla un hook só cando o enderezo se negocia

Para as ligazóns baseadas en PPP como L2TP, macOS executa /etc/ppp/ip-up unha vez establecida a ligazón. O script recibe o nome da interface e os enderezos local e remoto negociados, así que pode engadir unha ruta que dependa do par que asignou o servidor. É exactamente o caso que unha ruta de servizo fixa non pode expresar.

Pode que IKEv2 e os clientes de provedores non usen en absoluto esa ruta PPP, o que significa que o script pode quedar calado toda a sesión. Cando iso ocorre, unha tarefa launchd que consulta scutil --nc status e actúa ante un cambio de estado é o mecanismo equivalente, cun pequeno atraso.

Sexa cal sexa o hook que use, fagao idempotente e faga que elimine só as rutas que creou. Un script que borra todas as rutas que mencionan o túnel acabará borrando a ruta que mantén accesible o servidor VPN, e a conexión caerá en canto teña éxito.

Remate comprobando o destino privado, a navegación normal e un ciclo de reconexión ou de repouso. Despois inspeccione scutil --dns, porque a resolución de nomes é unha política aparte e unha ruta que funciona non demostra que os nomes privados se resolvan.