A orde de servizos de macOS non controla as rutas da túa VPN

Algo falla nun sitio web, un compañeiro lembra que existe a orde de servizos e Wi-Fi acaba arrastrado por riba de Ethernet. Nada cambia, porque esa lista nunca decidiu por onde vai un destino de VPN. Apple dá prioridade ás conexións VPN sobre as normais e manténas fóra desa reordenación, así que o interruptor responde a unha pregunta máis estreita ca a que se formula. O fallo necesita a ruta seleccionada e o resolver, non unha nova clasificación.

Que cambia a orde de servizos e que non toca nunca

«Definir orde de servizos» está en Axustes do Sistema, Rede, no menú Acción, e clasifica as conexións normais cando hai dúas ou máis activas. Esa clasificación escolle o servizo principal, que fornece a ruta predeterminada e parte do comportamento do resolver. É un desempate entre iguais, non un interruptor para destinos privados detrás dun túnel. Un portátil con Wi-Fi e un adaptador Ethernet USB úsao para responder a unha pregunta sensata, e esa pregunta non trata do túnel.

Un perfil de VPN leva rutas incluídas, destinos excluídos e ás veces regras por aplicación, e iso decide que entra no túnel; o menú de ordenación non as edita. Por iso un perfil de túnel dividido pode deixar o tráfico público fóra mentres a VPN segue superando todas as interfaces físicas. Arrastrar Wi-Fi arriba non fai accesible un rango privado nin detén un destino que o perfil xa inclúe. A lista move interfaces; o perfil move prefixos. Apple documenta a prioridade na súa páxina sobre a orde de servizos de rede, que merece unha lectura antes de reordenar nada.

Le a ruta que o equipo escolleu en realidade

Pregunta ao equipo por onde vai un enderezo concreto con route get 10.20.4.10 e repítao para IPv6 con route -n get -inet6 2001:db8::10. As dúas familias son decisións separadas, así que unha ruta IPv4 que funciona non di nada da v6, e unha subrede conectada directamente ou un prefixo máis específico vence de todos os xeitos a etiqueta xeral de conexión, que é xusto por que a etiqueta segue enganando a xente.

Se a saída nomea a interface do túnel, o perfil capturou o destino e a ordenación é irrelevante. Se nomea a interface física, o perfil non o fixo, e por moito que arrastres non cambiarás a táboa de prefixos. Ambas saídas tamén nomean o enderezo de orixe que usaría o equipo, e ese é o campo que hai que citar ao comparar dúas execucións. Garda a saída antes de cambiar nada, porque é a única proba que terás despois.

DNS resolve por nome, non por interface

Os resolvers con ámbito e específicos de dominio fan que a resposta poida variar por nome en lugar de por interface. scutil --dns imprime a configuración de resolver que o sistema usa realmente, incluídas as entradas con ámbito. A orde de servizos inflúe en que servizo fornece o resolver predeterminado, pero un ámbito específico de nome pode gañar de todos os xeitos.

Por iso un ping a un enderezo pode funcionar mentres falla o nome de host, ou ao revés. Le ambas saídas antes de escoller un culpable.

Cambia o perfil e despois volve ler as dúas saídas

Cando hai que cambiar unha política de destinos, o dono é o perfil de VPN: rutas incluídas, rutas excluídas e as regras de túnel dividido que admita o provedor. Cambiar interfaces só move a discusión. Nun Mac xestionado remotamente, garda primeiro o estado de rede actual, porque perder o túnel nunha máquina que non podes alcanzar é unha viaxe, non unha reversión.

Reproduce o fallo, le a ruta, le o resolver, cambia unha cousa e volve ler as mesmas dúas saídas. Barallar varios servizos e perfís á vez deixa un equipo que ninguén pode explicar, incluída a persoa que o arranxou. A proba remata cando ambas saídas concordan co cambio que pretendías. Se aínda discrepan, o perfil e o equipo describen dúas políticas distintas, e o perfil é o que hai que cambiar.