A ordem de serviços do macOS não controla as rotas da sua VPN

Algo num site falha, um colega lembra que existe a ordem de serviços, e o Wi-Fi é arrastado para cima do Ethernet. Nada muda, porque essa lista nunca decidiu para onde vai um destino de VPN. A Apple dá prioridade às conexões VPN sobre as comuns e as mantém fora dessa reordenação, então o interruptor responde a uma pergunta mais estreita do que a feita. A falha precisa da rota selecionada e do resolver, não de uma nova classificação.

O que a ordem de serviços muda, e o que ela nunca toca

«Definir ordem de serviços» fica em Ajustes do Sistema, Rede, no menu Ação, e classifica as conexões comuns quando duas ou mais estão ativas. Essa classificação escolhe o serviço primário, que fornece a rota predefinida e parte do comportamento do resolver. É um desempate entre iguais, não um interruptor para destinos privados atrás de um túnel. Um portátil com Wi-Fi e um adaptador Ethernet USB usa-a para responder a uma pergunta sensata, e essa pergunta não é sobre o túnel.

Um perfil de VPN carrega rotas incluídas, destinos excluídos e às vezes regras por aplicação, e são elas que decidem o que entra no túnel; o menu de ordenação não as edita. Por isso um perfil de túnel dividido pode deixar o tráfego público de fora enquanto a VPN continua acima de todas as interfaces físicas. Arrastar o Wi-Fi para o topo não torna um intervalo privado alcançável e não impede um destino que o perfil já inclui. A lista move interfaces; o perfil move prefixos. A Apple documenta a prioridade na sua página sobre a ordem de serviços de rede, que vale uma leitura antes de reordenar qualquer coisa.

Leia a rota que a máquina realmente escolheu

Pergunte à máquina para onde vai um endereço específico com route get 10.20.4.10, e repita para IPv6 com route -n get -inet6 2001:db8::10. As duas famílias são decisões separadas, então uma rota IPv4 a funcionar não diz nada sobre a v6, e uma sub-rede ligada diretamente ou um prefixo mais específico vence de qualquer forma a etiqueta geral de ligação, que é exatamente por isso que a etiqueta continua a enganar as pessoas.

Se a saída nomear a interface do túnel, o perfil capturou o destino e a ordenação é irrelevante. Se nomear a interface física, o perfil não o fez, e nenhum arrastar mudará a tabela de prefixos. Ambas as saídas também nomeiam o endereço de origem que a máquina usaria, e é esse o campo a citar quando compara duas execuções. Guarde a saída antes de mudar qualquer coisa, porque é a única prova que terá depois.

O DNS resolve por nome, não por interface

Resolvers com âmbito e específicos de domínio significam que a resposta pode variar por nome em vez de por interface. scutil --dns imprime a configuração de resolver que o sistema está realmente a usar, incluindo entradas com âmbito. A ordem de serviços influencia qual serviço fornece o resolver predefinido, mas um âmbito específico de nome pode ganhar mesmo assim.

Por isso um ping a um endereço pode funcionar enquanto o nome do anfitrião falha, ou ao contrário. Leia as duas saídas antes de escolher um culpado.

Mude o perfil e depois volte a ler as duas saídas

Quando uma política de destino tem de mudar, o dono é o perfil de VPN: rotas incluídas, rotas excluídas e todas as regras de túnel dividido que o fornecedor suporta. Mudar interfaces apenas move a discussão. Num Mac gerido remotamente, guarde primeiro o estado de rede atual, porque perder o túnel numa máquina que não consegue alcançar é uma viagem, não uma reversão.

Reproduza a falha, leia a rota, leia o resolver, mude uma coisa e depois volte a ler as mesmas duas saídas. Misturar vários serviços e perfis ao mesmo tempo deixa uma máquina que ninguém consegue explicar, incluindo quem a reparou. O teste termina quando as duas saídas concordam com a mudança que pretendia. Se ainda discordarem, o perfil e a máquina descrevem duas políticas diferentes, e é o perfil que tem de mudar.