O VPN do Mac volta a ligar-se sozinho logo após premir Desligar

Premir Desligar funciona, e dez segundos depois o túnel volta de qualquer forma. Esse ciclo raramente é o cliente VPN a comportar-se mal; é um script de recuperação que só fazia uma pergunta, «está em baixo?», e respondia-lhe ligando. Quando separa a pergunta a que o utilizador respondeu da pergunta que o sistema comunica, a correção passa a ser uma pequena quantidade de estado em vez de uma espera mais longa.

Duas perguntas, não uma

Este perfil deve estar ligado neste momento, e o que comunica o sistema neste instante? São perguntas diferentes com donos diferentes, e uma política de recuperação precisa das duas antes de agir. A intenção é algo que a sua ferramenta decide e memoriza. O estado observado é algo que a plataforma lhe diz.

Leia as linhas como uma política e não como uma lista de casos. A segunda linha é a que a maioria dos scripts omite, e é a única linha que distingue um monitor de uma máquina que insiste em ter razão.

O estado observado não é uma preferência

O modelo de estado Network Extension da Apple comunica os estados connecting, connected, disconnecting, disconnected e recovery. Todos os cinco descrevem a ligação. Nenhum deles diz «o utilizador pediu que este perfil ficasse em pausa», porque isso não é, de todo, um estado de ligação. Os clientes que não são construídos sobre essa estrutura expõem os seus próprios controlos e chamadas de estado suportados, e traçam a mesma linha no seu próprio vocabulário.

A consequência é que um estado desligado nunca pode ser interpretado sozinho. Significa uma de pelo menos três coisas: o túnel caiu, o utilizador parou-o, ou o sistema está entre tentativas. Só o seu próprio registo de intenção os consegue distinguir. Anote esse registo, conserve-o entre reinícios se tiver de sobreviver a um reinício, e atualize-o no momento em que o utilizador age em vez de o inferir mais tarde a partir de uma linha de registo.

scutil --nc list
scutil --nc status "Office VPN"

Quem mais pode iniciar este perfil

Uma pausa prometida pelo seu auxiliar é apenas tão forte como os outros donos do mesmo perfil. Uma regra On Demand, uma configuração gerida ou um segundo cliente podem todos pedir uma ligação, e o seu auxiliar parecerá avariado enquanto se comporta exatamente como está escrito.

Encontre todos os mecanismos que podem iniciar o perfil antes de prometer respeitar uma pausa, e anote qual ganha. Quando um serviço gerido retém deliberadamente uma opção de pausa pessoal, isso é uma decisão do administrador sobre a política, não uma lacuna que um script deva preencher lutando contra a gestão.

Torne as tentativas aborrecidas

Limite o número de tentativas e faça com que cada uma responda a algo que mudou: a rede voltou, a gateway respondeu, o pedido de credenciais terminou. Uma gateway indisponível, uma identidade expirada e um segundo fator rejeitado exigem três respostas diferentes, e um ciclo apertado dá a todas as três a mesma.

Veja o que uma tentativa rápida produz realmente no ecrã. As caixas de diálogo repetidas que o utilizador fecha são piores do que uma única mensagem de erro clara, e ensinam as pessoas a clicar nos avisos sem os ler.

A pausa e a política de tráfego são promessas separadas

Um túnel em pausa pelo utilizador deixa frequentemente o tráfego bloqueado de propósito, e é exatamente esse o objetivo de uma política ao estilo kill switch. Isso significa que Pausa deve prometer exatamente uma coisa: a recuperação pára. Não deve alterar silenciosamente o que a rede permite.

Decida o comportamento do tráfego separadamente, documente-o junto do controlo Pausa e mantenha-o coerente quer o túnel esteja em pausa, com falha ou ausente. Caso contrário, o utilizador aprende que premir Desligar faz algo imprevisível, e o próximo pedido de apoio é sobre uma rede que «às vezes deixa de funcionar» sem motivo visível.