As rotas VPN adicionais do Mac precisam de um dono, não de um script de início de sessão

Alcançar um prefixo privado através de uma VPN é um requisito com duração: mantém-se enquanto essa ligação é utilizável e termina quando a ligação termina. Um script de início de sessão não consegue exprimir isso, porque o início de sessão e a subida do túnel são momentos diferentes, e o túnel que existe no início de sessão pode não ser o que transporta tráfego um minuto depois. A primeira decisão não é que comando executar. É que componente é dono do prefixo.

O prefixo precisa de um dono, não de um momento

Comece por escrever o requisito como uma frase com sujeito: alcance 10.77.0.0/24 através da VPN do Escritório enquanto essa ligação estiver ativa. Essa frase nomeia o prefixo, a ligação e a condição, e exclui imediatamente dois substitutos populares: um hook de início de sessão e um nome de interface como ppp0 ou utun2.

Os nomes de interface são atribuídos em tempo de execução e não são estáveis entre reconexões. Um hook que corresponde ao nome que viu na semana passada ou não dispara ou dispara contra a interface de outra pessoa. Ambos os resultados aparecem como um bug de encaminhamento e não como a suposição desatualizada que são. A mesma objeção aplica-se a qualquer script ligado a um nome que só existe enquanto um túnel específico está ativo.

Use uma fonte suportada de intenção de rota

O gateway, um perfil gerido ou o mecanismo de rotas documentado do cliente proprietário é o lugar certo, sempre que esse mecanismo consiga exprimir o requisito. Qual se aplica depende do protocolo e do fornecedor, e as chaves não viajam entre eles, por isso um valor que configura um perfil OpenVPN não lhe diz nada sobre o cliente nativo L2TP ou IKEv2.

Para quem desenvolve túneis de pacotes, as definições de túnel IPv4 da Apple expõem explicitamente as rotas incluídas e excluídas, e o IPv6 tem a sua contraparte. São API que o fornecedor usa, não prova de que todos os painéis VPN nativos ofereçam ao administrador uma lista arbitrária de rotas. Se a combinação atual não conseguir exprimir os prefixos de que precisa, o passo seguinte é um caminho de configuração suportado pelo operador, não outra aplicação instalada na esperança de se comportar melhor.

A vida útil inclui a limpeza

Por vezes um auxiliar externo é realmente necessário, e quando é, «adiciona a rota» é a parte mais pequena do seu trabalho. Tem de saber a que ligação serve e que interface essa ligação usa, esperar que o estado de rede relevante assente, manter-se idempotente quando corre duas vezes seguidas, e não limpar nada que não tenha instalado ele próprio.

A última cláusula é a que dói. Um auxiliar que apaga todas as rotas que correspondem ao prefixo do escritório acabará, mais cedo ou mais tarde, por apagar uma rota que não adicionou. A falha resultante é atribuída ao cliente VPN, porque o cliente é a parte que o utilizador vê. Decidir o que um auxiliar possui antes de o escrever é mais barato do que explicar depois porque é que uma sub-rede local deixou de responder.

A corrida da reconexão

Considere uma reconexão rápida. A sessão A cai, a sessão B sobe e instala a sua rota, e depois a limpeza atrasada de A finalmente corre. Se essa limpeza remover rotas por prefixo, leva consigo o estado válido de B, e a ligação que funcionava há um segundo encaminha agora para o nada.

Isto é uma corrida de propriedade, e acrescentar uma pausa ao script só muda que lado a ganha. A correção é tornar a limpeza condicional à identidade: compare a interface e a sessão que o auxiliar instalou com as que ainda estão em vigor, e remova apenas quando coincidirem.

O que testar, e o que uma rota não pode fazer

A aceitação tem de cobrir quatro transições: a primeira ligação, uma reconexão para uma interface diferente, uma tentativa de ligação falhada e a desconexão final. Depois de cada uma, leia a rota que o sistema realmente escolheu para um endereço do lado remoto, não a que esperava.

route -n get 10.77.0.5
netstat -rn -f inet

Inclua os casos incómodos na mesma passagem: IPv6 onde for necessário, um prefixo local que se sobreponha ao remoto, e a rota para o próprio ponto final público da VPN, que tem de continuar a funcionar enquanto o túnel estiver ativo. Depois anote o que uma rota não é. Seleciona pacotes; não concede permissão no lado remoto e não cria um caminho de regresso, e isso continuam a ser requisitos separados com donos separados.

O resultado que quer é um prefixo que segue o seu dono de ligação suportado através de cada transição, e não um comando que acertou uma vez por acaso na máquina onde foi escrito.