Por que route -interface não alcança um host fora do enlace

route aceita o nome da interface Wi-Fi, sai sem reclamar e o host continua inalcançável. Nada está corrompido; a relação na rota está simplesmente errada: um sinalizador de interface diz em qual enlace um destino está, não qual router deve receber o tráfego de um destino que fica em outro lugar. O comando tem sucesso porque é sintaticamente válido, não porque descreve um caminho que funcione.

Essa distinção decide se uma exceção de rota ao lado de uma VPN vai funcionar ou apenas parecer plausível.

A interface é a saída, o próximo salto é a entrega

Num Mac com endereço 192.168.50.20 e um router em 192.168.50.1, outra máquina no mesmo enlace é alcançável diretamente. O quadro é endereçado a essa máquina e colocado no cabo. Nenhum router está envolvido, e uma rota limitada à interface expressa exatamente isso. Mude a extremidade remota para um host noutro edifício e o mesmo comando deixa de fazer sentido. O Mac não tem um endereço de segunda camada para colocar no cabo, então o sinalizador de interface não tem nada a descrever.

Um destino fora do enlace é diferente. O Mac não pode colocar no cabo um quadro endereçado a um host que não alcança na segunda camada; entrega o pacote a um router que consegue. A rota, portanto, precisa de um gateway, e o próprio gateway tem de ser alcançável no enlace ligado.

Usar o sinalizador de interface para um destino fora do enlace diz ao macOS para tratar esse destino como se estivesse no cabo. O kernel então não consegue resolver um endereço de segunda camada para ele, e o pacote é descartado sem nada útil no erro.

O que o sinalizador de interface realmente afirma

A referência de rotas da Apple define a forma de interface para destinos alcançáveis diretamente sem intermediário. É uma afirmação sobre o modelo de enlace, não uma preferência sobre qual adaptador usar. Alcançar um host de internet por Wi-Fi ainda exige um router nesse enlace Wi-Fi, e a rota tem de nomeá-lo.

O âmbito da interface é um atributo separado. Associa uma rota a uma interface específica para decisões de âmbito como qual endereço de origem se aplica, mas não cria alcançabilidade para um destino que a interface não consegue alcançar sozinha. Os dois atributos respondem a perguntas diferentes.

É por isso que um comando pode ser aceito, aparecer na tabela e ainda falhar. O kernel não valida a sua intenção; registra o que você afirmou, e a afirmação era que o destino está no enlace. Um sucesso silencioso seguido de descarte silencioso é o resultado esperado, não um bug. Releia a afirmação antes de culpar a rede.

A rota de que um destino fora do enlace precisa

Para um caminho aprovado até um endereço de documentação como 198.51.100.25 através do router LAN, a relação pretendida é um destino, um próximo salto de 192.168.50.1 e a interface LAN que alcança esse próximo salto. A interface é implícita pela consulta do próximo salto em vez de imposta pelo comando de rota.

No macOS, a inspeção só de leitura é route -n get 198.51.100.25. Leia as linhas de gateway e interface juntas e verifique se o gateway é um endereço que o Mac realmente alcança. Um gateway noutra sub-rede, ou que desapareceu desde a última mudança de rede, produz uma rota que parece correta e não encaminha nada.

Não codifique en0 numa instrução duradoura. Os nomes de interface mudam com adaptadores, docks e clientes VPN, e uma rota que nomeia o errado falha de um modo fácil de interpretar como uma falha de rede mais ampla.

Leia a escolha atual antes de substituí-la

Antes de acrescentar qualquer coisa, inspecione o que o sistema já escolheu e por quê. Essa saída diz se o tráfego passa pelo túnel, pelo router LAN ou por lugar nenhum, e dá uma base para comparar depois da mudança. Sem ela, não é possível saber se a nova rota teve efeito.

Depois verifique a família de endereços. Uma rota adicionada para IPv4 não faz nada por um destino IPv6, e um serviço que resolve para ambas as famílias pode parecer intermitentemente alcançável. A tabela de rotas e o resolver respondem a perguntas diferentes, e ambos precisam concordar com o caminho pretendido.

Por fim, lembre-se de que uma rota é uma seleção, não uma permissão. Um perfil de VPN gerenciado ou um filtro de cliente ainda pode proibir o caminho direto mesmo quando a tabela aponta para ele, então teste com a aplicação real em vez de supor que uma entrada bem-sucedida na tabela encerra a investigação.

Túneis e políticas mudam a forma

As interfaces ponto a ponto são um caso à parte. Um túnel pode carregar uma rota sem um endereço de gateway ao estilo Ethernet, e isso não é automaticamente errado. Aplique o modelo de enlace real da interface em vez de estender um exemplo de Wi-Fi a cada entrada da tabela que você vir.

Para pedidos de mudança, anote o destino, o caminho de rede aprovado, o gateway e a interface atuais, e quem se espera que mantenha a exceção. O proprietário importa porque uma rota pontual digitada no prompt não é uma política, e a próxima reconexão a apagará.

Se o requisito é alcançar este host com a VPN ativa, a resposta honesta costuma ser uma rota de host específica através do router local, instalada pelo gestor de rede que possui a interface. Se o requisito é alcançar qualquer coisa diretamente, o próprio requisito precisa de uma revisão de política antes de precisar de um comando de rota.