El orden de servicios de macOS no controla las rutas de tu VPN

Algo falla en un sitio web, un compañero recuerda que existe el orden de servicios y Wi-Fi acaba arrastrado por encima de Ethernet. Nada cambia, porque esa lista nunca decidió adónde va un destino de VPN. Apple da prioridad a las conexiones VPN sobre las normales y las mantiene fuera de esa reordenación, así que el interruptor responde a una pregunta más estrecha que la que se plantea. El fallo necesita la ruta seleccionada y el resolver, no una nueva clasificación.

Qué cambia el orden de servicios y qué no toca nunca

«Definir orden de servicios» está en Ajustes del Sistema, Red, en el menú Acción, y clasifica las conexiones normales cuando hay dos o más activas. Esa clasificación elige el servicio primario, que aporta la ruta predeterminada y parte del comportamiento del resolver. Es un desempate entre iguales, no un interruptor para destinos privados detrás de un túnel. Un portátil con Wi-Fi y un adaptador Ethernet USB lo usa para responder a una pregunta sensata, y esa pregunta no trata del túnel.

Un perfil de VPN lleva rutas incluidas, destinos excluidos y a veces reglas por aplicación, y eso decide qué entra en el túnel; el menú de ordenación no las edita. Por eso un perfil de túnel dividido puede dejar el tráfico público fuera mientras la VPN sigue superando a todas las interfaces físicas. Arrastrar Wi-Fi arriba no hace alcanzable un rango privado ni detiene un destino que el perfil ya incluye. La lista mueve interfaces; el perfil mueve prefijos. Apple documenta la prioridad en su página sobre el orden de servicios de red, que merece una lectura antes de reordenar nada.

Lee la ruta que el equipo eligió en realidad

Pregunta al equipo adónde va una dirección concreta con route get 10.20.4.10 y repítelo para IPv6 con route -n get -inet6 2001:db8::10. Las dos familias son decisiones separadas, así que una ruta IPv4 que funciona no dice nada de la v6, y una subred conectada directamente o un prefijo más específico vence de todos modos a la etiqueta general de conexión, que es justo por qué la etiqueta sigue engañando a la gente.

Si la salida nombra la interfaz del túnel, el perfil capturó el destino y la ordenación es irrelevante. Si nombra la interfaz física, el perfil no lo hizo, y por mucho que arrastres no cambiarás la tabla de prefijos. Ambas salidas también nombran la dirección de origen que usaría el equipo, y ese es el campo que hay que citar al comparar dos ejecuciones. Guarda la salida antes de cambiar nada, porque es la única prueba que tendrás después.

DNS resuelve por nombre, no por interfaz

Los resolvers con ámbito y específicos de dominio hacen que la respuesta pueda variar por nombre en lugar de por interfaz. scutil --dns imprime la configuración de resolver que el sistema usa realmente, incluidas las entradas con ámbito. El orden de servicios influye en qué servicio aporta el resolver predeterminado, pero un ámbito específico de nombre puede ganar de todos modos.

Por eso un ping a una dirección puede funcionar mientras falla el nombre de host, o al revés. Lee ambas salidas antes de elegir un culpable.

Cambia el perfil y luego vuelve a leer las dos salidas

Cuando hay que cambiar una política de destinos, el dueño es el perfil de VPN: rutas incluidas, rutas excluidas y las reglas de túnel dividido que admita el proveedor. Cambiar interfaces solo mueve la discusión. En un Mac gestionado remotamente, guarda primero el estado de red actual, porque perder el túnel en una máquina que no puedes alcanzar es un viaje, no una reversión.

Reproduce el fallo, lee la ruta, lee el resolver, cambia una cosa y vuelve a leer las mismas dos salidas. Barajar varios servicios y perfiles a la vez deja un equipo que nadie puede explicar, incluida la persona que lo arregló. La prueba termina cuando ambas salidas coinciden con el cambio que pretendías. Si aún discrepan, el perfil y el equipo describen dos políticas distintas, y el perfil es el que hay que cambiar.