L'ordre de serveis del macOS no controla les rutes de la VPN

Alguna cosa falla en un lloc web, un company recorda que l'ordre de serveis existeix, i el Wi-Fi s'arrossega per sobre d'Ethernet. No canvia res, perquè aquella llista mai no va decidir on va una destinació de VPN. Apple dona prioritat a les connexions VPN sobre les ordinàries i les manté fora d'aquell reordenament, així que l'interruptor respon a una pregunta més estreta que la que es fa. La fallada necessita la ruta seleccionada i el resolutor, no una nova classificació.

Què canvia l'ordre de serveis i què no toca mai

Defineix l'ordre de serveis és a Configuració del Sistema, Xarxa, al menú Acció, i classifica les connexions ordinàries quan dues o més estan actives. Aquesta classificació tria el servei primari, que proporciona la ruta per defecte i part del comportament del resolutor. És un desempat entre iguals, no un interruptor per a destinacions privades darrere d'un túnel. Un portàtil amb Wi-Fi i un adaptador Ethernet USB l'utilitza per respondre una pregunta sensata, i aquesta pregunta no tracta del túnel.

Un perfil de VPN porta rutes incloses, destinacions excloses i de vegades regles per aplicació, i aquestes decideixen què entra al túnel; el menú d'ordenació no les edita. Per això un perfil de túnel dividit pot deixar el trànsit públic a fora mentre la VPN encara supera cada interfície física. Arrossegar el Wi-Fi a dalt no pot fer accessible un rang privat, ni pot aturar una destinació que el perfil ja inclou. La llista mou interfícies; el perfil mou prefixos. Apple documenta la prioritat a la pàgina de l'ordre de serveis de xarxa, que val la pena llegir un cop abans de reordenar res.

Llegiu la ruta que la màquina ha seleccionat realment

Pregunteu a la màquina on va una adreça concreta amb route get 10.20.4.10, i repetiu-ho per a IPv6 amb route -n get -inet6 2001:db8::10. Les dues famílies són decisions separades, així que un camí IPv4 que funciona no diu res sobre el camí v6, i una subxarxa connectada directament o un prefix més específic guanya igualment l'etiqueta general de connexió, que és exactament per què l'etiqueta segueix enganyant la gent.

Si la sortida nomena la interfície del túnel, el perfil ha capturat la destinació i l'ordenació és irrellevant. Si nomena la interfície física, el perfil no ho ha fet, i cap quantitat d'arrossegar canviarà la taula de prefixos. Totes dues sortides també nomenen l'adreça d'origen que la màquina faria servir, i aquest és el camp a citar quan compareu dues execucions. Deseu la sortida abans de canviar res, perquè és l'única evidència que tindreu després.

El DNS resol pel nom, no per la interfície

Els resolutors amb abast i específics de domini fan que la resposta pugui diferir per nom més que per interfície. scutil --dns imprimeix la configuració del resolutor que el sistema fa servir realment, incloses les entrades amb abast. L'ordre de serveis influeix en quin servei proporciona el resolutor per defecte, però un abast específic d'un nom pot guanyar igualment.

Per això un ping a una adreça pot funcionar mentre el nom d'amfitrió falla, o al revés. Llegiu totes dues sortides abans de triar un culpable.

Canvieu el perfil i torneu a llegir totes dues sortides

Quan una política de destinació ha de canviar, el propietari és el perfil de VPN: rutes incloses, rutes excloses i les regles de túnel dividit que admeti el proveïdor. Canviar interfícies en lloc d'això només mou la discussió. En un Mac gestionat remotament, deseu primer l'estat actual de la xarxa, perquè perdre el túnel en una màquina que no podeu abastar és un viatge, no una reversió.

Reproduïu la fallada, llegiu la ruta, llegiu el resolutor, canvieu una cosa, i torneu a llegir les mateixes dues sortides. Barrejar diversos serveis i perfils alhora deixa una màquina que ningú no pot explicar, inclosa la persona que l'ha arreglada. La prova s'acaba quan totes dues sortides coincideixen amb el canvi que volíeu. Si encara no coincideixen, el perfil i la màquina descriuen dues polítiques diferents, i el perfil és el que cal canviar.