Rotas persistentes para uma VPN Mac: networksetup ou um hook de ligação?

Uma rota escrita após cada ligação resolve o momento e não a semana. No macOS, a escolha duradoura costuma ser um prefixo guardado com o serviço VPN, porque o serviço reinstala-o a cada ligação e remove-o quando o serviço está desligado. As alternativas são um route add transitório para testar e um hook de ligação para endereços que só são conhecidos após a negociação.

Decida se a rota pertence ao serviço ou à sessão

Pergunte de que depende o prefixo. Se for uma rede privada fixa atrás de um serviço VPN nativo, a rota pertence a esse serviço. Se depender de um endereço de par que muda a cada ligação, um hook ou uma tarefa guiada por estado podem ser o melhor proprietário. Se apenas verificar um caminho para os próximos cinco minutos, uma rota transitória basta.

A rota ligada ao serviço tem o ciclo de vida mais limpo. Aparece com o serviço e desaparece quando o serviço não está ligado, pelo que não pode sobreviver ao túnel para o qual aponta. Essa propriedade vale mais do que a comodidade de um comando de uma linha.

Uma rota ligada à sessão pertence à interface, e esse número muda sem aviso. Uma reconexão pode dar ao túnel um nome utun diferente do usado pela sessão anterior, o que transforma um comando codificado numa rota que não aponta para nada ou, pior, para outro túnel.

Leia o estado atual da rota e do serviço

Comece pelos nomes que o sistema realmente usa. O nome do serviço nas Definições de Rede é o identificador dos comandos abaixo, e a tabela de rotas atual mostra o que o cliente ligado instalou. Leia ambos enquanto o túnel está ativo.

scutil --nc list
networksetup -listnetworkserviceorder
netstat -rn | head -30
route get 10.20.5.5

Essa consulta mostra qual gateway e interface o kernel escolheria para este endereço neste momento. Se já escolhe o túnel, o prefixo está coberto e uma nova rota seria redundante. Se escolhe o router local, falta ao túnel esse prefixo.

Anote o endereço do par enquanto está ligado. Torna-se o valor de gateway na rota ligada ao serviço, e é normalmente o destino mostrado para a rota predefinida do túnel em netstat -rn.

Guarde o prefixo com networksetup

A ferramenta networksetup associa rotas adicionais a um serviço de rede. Para um serviço chamado OfficeVPN e um prefixo privado alcançado através do par do túnel, a forma é:

sudo networksetup -setadditionalroutes OfficeVPN 10.20.0.0 255.255.0.0 10.8.0.6
networksetup -getadditionalroutes OfficeVPN

Cada triplo após o nome do serviço dá um destino, a sua máscara de rede e o par do túnel como gateway. Uma só chamada pode transportar vários prefixos, e uma chamada vazia apaga a lista guardada. O leitor é o passo de verificação; se a lista estiver vazia, o conjunto não foi aplicado ao serviço que pensa.

O gateway deve ser o par do túnel, não o router físico. Uma rota que nomeia o gateway local envia o prefixo privado pela interface física, que é a falha original com passos extra. Um par obsoleto é a razão mais comum para uma rota com aspeto correto nunca transportar tráfego. Releia o par a partir do estado ligado em vez de copiar um endereço de uma nota antiga.

Use route add apenas para um teste

Uma rota direta é útil para provar que um prefixo funciona antes de o tornar permanente. A forma com interface evita uma consulta de gateway:

sudo route -n add -net 10.20.0.0/16 -interface utun4

A rota desaparece na próxima reconexão e depende do número de interface que existe hoje. Isso torna-a um diagnóstico, não uma implementação. Se o teste funcionar e a rota ligada ao serviço não, compare primeiro o valor de gateway; é o campo que mais frequentemente está errado.

Tenha cuidado com conselhos que substituem a rota predefinida da VPN para forçar a divisão. Um cliente que impõe um túnel completo pode reinstalar as suas rotas após uma reconexão ou uma atualização de política, pelo que a alteração manual é anulada em silêncio. Alguns prefixos privados são um problema de encaminhamento; manter todo o tráfego de internet local contra uma política de túnel completo é uma decisão do lado do servidor.

Escolha um hook só quando o endereço é negociado

Para ligações baseadas em PPP como L2TP, o macOS executa /etc/ppp/ip-up assim que a ligação é estabelecida. O script recebe o nome da interface e os endereços local e remoto negociados, pelo que pode acrescentar uma rota que depende do par atribuído pelo servidor. É exatamente o caso que uma rota de serviço fixa não consegue exprimir.

IKEv2 e clientes de fornecedores podem não usar de todo esse caminho PPP, o que significa que o script pode ficar calado durante toda a sessão. Quando isso acontece, uma tarefa launchd que consulta scutil --nc status e age perante uma mudança de estado é o mecanismo equivalente, com um pequeno atraso.

Seja qual for o hook que usar, torne-o idempotente e faça com que remova apenas as rotas que criou. Um script que apaga todas as rotas que mencionam o túnel acabará por apagar a rota que mantém o servidor VPN acessível, e a ligação cai assim que tiver êxito.

Termine verificando o destino privado, a navegação normal e um ciclo de reconexão ou de suspensão. Depois inspecione scutil --dns, porque a resolução de nomes é uma política separada e uma rota funcional não prova que os nomes privados são resolvidos.