Rutes persistents per a una VPN de Mac: networksetup o un hook de connexió?

Una ruta escrita després de cada connexió resol el moment i no la setmana. A macOS, l’opció duradora sol ser un prefix desat amb el servei VPN, perquè el servei el reinstal·la a cada connexió i el retira quan el servei està aturat. Les alternatives són una route add transitòria per provar i un hook de connexió per a adreces que només es coneixen després de la negociació.

Decidiu si la ruta pertany al servei o a la sessió

Pregunteu de què depèn el prefix. Si és una xarxa privada fixa darrere d’un servei VPN natiu, la ruta pertany a aquell servei. Si depèn d’una adreça de parell que canvia a cada connexió, un hook o una tasca guiada per l’estat poden ser el millor propietari. Si només comproveu un camí durant els cinc minuts vinents, una ruta transitòria és suficient.

La ruta lligada al servei té el cicle de vida més net. Apareix amb el servei i desapareix quan el servei no està connectat, així que no pot sobreviure al túnel al qual apunta. Aquesta propietat val més que la comoditat d’una ordre d’una línia.

Una ruta lligada a la sessió pertany a la interfície, i aquest número canvia sense avís. Una reconnexió pot donar al túnel un nom utun diferent del que va fer servir la sessió anterior, cosa que converteix una ordre codificada en una ruta que no apunta enlloc o, pitjor, a un altre túnel.

Llegiu l’estat actual de la ruta i del servei

Comenceu pels noms que el sistema fa servir realment. El nom del servei a Configuració de xarxa és l’identificador de les ordres següents, i la taula de rutes actual mostra què ha instal·lat el client connectat. Llegiu tots dos mentre el túnel està actiu.

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

Aquesta consulta mostra quina porta d’enllaç i quina interfície triaria el nucli per a aquesta adreça en aquest moment. Si ja tria el túnel, el prefix està cobert i una ruta nova seria redundant. Si tria l’encaminador local, al túnel li falta aquest prefix.

Anoteu l’adreça del parell mentre esteu connectats. Esdevé el valor de la porta d’enllaç a la ruta lligada al servei, i normalment és la destinació que es mostra per a la ruta per defecte del túnel a netstat -rn.

Desa el prefix amb networksetup

L’eina networksetup adjunta rutes addicionals a un servei de xarxa. Per a un servei anomenat OfficeVPN i un prefix privat abastat pel parell del túnel, la forma és:

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

Cada triplet després del nom del servei dona una destinació, la seva màscara de xarxa i el parell del túnel com a porta d’enllaç. Una sola crida pot portar diversos prefixos, i una crida buida esborra la llista desada. El lector és el pas de verificació; si la llista és buida, el conjunt no s’ha aplicat al servei que creieu.

La porta d’enllaç ha de ser el parell del túnel, no l’encaminador físic. Una ruta que nomena la porta local envia el prefix privat per la interfície física, que és la fallada original amb passos extra. Un parell obsolet és el motiu més habitual que una ruta que sembla correcta no transporti mai tràfic. Torneu a llegir el parell des de l’estat connectat en lloc de copiar una adreça d’una nota antiga.

Feu servir route add només per a una prova

Una ruta directa és útil per demostrar que un prefix funciona abans de fer-lo permanent. La forma amb interfície evita una consulta de porta d’enllaç:

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

La ruta desapareix a la reconnexió següent i depèn del número d’interfície que existeix avui. Això la converteix en un diagnòstic, no en un desplegament. Si la prova funciona i la ruta lligada al servei no, compareu primer el valor de la porta d’enllaç; és el camp que més sovint és incorrecte.

Aneu amb compte amb els consells que substitueixen la ruta per defecte de la VPN per forçar la divisió. Un client que imposa un túnel complet pot reinstal·lar les seves rutes després d’una reconnexió o d’un refresc de política, així que el canvi manual es desfà en silenci. Un grapat de prefixos privats és un problema d’encaminament; mantenir tot el trànsit d’internet local contra una política de túnel complet és una decisió del servidor.

Trieu un hook només quan l’adreça es negocia

Per als enllaços basats en PPP com L2TP, macOS executa /etc/ppp/ip-up quan l’enllaç s’estableix. L’script rep el nom de la interfície i les adreces local i remota negociades, així que pot afegir una ruta que depèn del parell que ha assignat el servidor. És exactament el cas que una ruta de servei fixa no pot expressar.

IKEv2 i els clients de proveïdors poden no fer servir gens aquest camí PPP, cosa que significa que l’script pot quedar en silenci tota la sessió. Quan passa això, una tasca launchd que consulta scutil --nc status i actua en un canvi d’estat és el mecanisme equivalent, amb un petit retard.

Sigui quin sigui el hook que feu servir, feu-lo idempotent i feu que només elimini les rutes que ha creat. Un script que esborra totes les rutes que esmenten el túnel finalment esborrarà la ruta que manté el servidor VPN accessible, i la connexió caurà tan bon punt tingui èxit.

Acabeu comprovant la destinació privada, la navegació normal i un cicle de reconnexió o de repòs. Després inspeccioneu scutil --dns, perquè la resolució de noms és una política separada i una ruta que funciona no demostra que els noms privats es resolguin.