O VPN sob demanda do iPhone liga-se ao Wi-Fi do escritório, não à rede móvel
A sua regra de exclusão existe e mesmo assim perde. As listas sob demanda são lidas de cima para baixo, por isso uma regra inicial que apanha tudo decide a manhã antes de a regra do escritório ser vista.
Às nove, o telefone junta-se à rede sem fios do escritório, e o túnel sobe sozinho e fica lá o dia inteiro. A rede móvel depois comporta-se exatamente como todos pretendiam. Alguém acrescentou uma exclusão para a rede corporativa há semanas, por isso o perfil parece limpo na revisão, e cada manhã continua a produzir o mesmo resultado. O dispositivo segue a lista que lhe foi dada, e a lista diz algo diferente do que o seu autor acreditava.
A lista é lida de cima, e a primeira correspondência ganha
As entradas são avaliadas por ordem. A primeira cujas condições se verificam decide o resultado para esse momento, e tudo o que está abaixo nunca é olhado. A ordem carrega, portanto, tanta carga de significado como qualquer condição escrita dentro de uma regra. Ler a matriz de cima explica um perfil que parece ignorar uma exclusão que claramente contém.
Uma entrada geral de ligação sem fios colocada acima da exclusão do escritório garante um túnel no local. Nada mais na carga precisa de se mover para o comportamento se inverter.
Uma entrada de desligar faz dois trabalhos
Quando a ação é Desligar, a entrada fecha uma sessão que já corre e bloqueia uma nova enquanto as suas condições se mantiverem verdadeiras. As duas metades importam para uma exclusão, e a segunda tende a ser esquecida. A mesma entrada num segundo perfil explica um piso onde o VPN se recusa a arrancar enquanto o resto do edifício funciona. Ninguém tocou no túnel; foi a lista.
A tabela mostra a forma, a exclusão primeiro, com nomes que têm de vir da sua própria implementação. Normalmente duas entradas bastam, e uma terceira para a rede móvel mantém o resto previsível.
| Order | Action | Conditions |
|---|---|---|
| 1 | Disconnect | Wireless interface plus office network name |
| 2 | Connect | Wireless interface |
| 3 | Connect | Cellular interface |
Mantenha as duas condições na exclusão
Combine o nome da rede com o tipo de interface. Um nome sozinho pode disparar numa ligação partilhada que leve a mesma etiqueta, enquanto um tipo de interface sozinho exclui todas as redes sem fios que o utilizador visita nesse dia. As duas metades pertencem a uma entrada, não a duas regras que por acaso estão lado a lado.
A comparação do nome é exata e distingue maiúsculas de minúsculas. Isso serve para uma rede conhecida e aperta em todo o resto, porque as redes de convidados reutilizam etiquetas familiares, os locais são renomeados após uma fusão, e uma secretária com cabo não tem nome nenhum. Peça à equipa de rede a etiqueta exata em vez de a ler num painel na parede.
Quando uma sonda vence um nome
Uma entrada de sonda pede um URL e lê uma resposta bem-sucedida como condição verdadeira. Escolha um anfitrião que só responda de dentro, como um serviço de intranet que não possa ser resolvido publicamente, e a regra deixa de se importar com o nome que a rede dá a si mesma. Uma sonda que responde de qualquer lugar testa a internet, não o edifício. A propriedade que decide se isto funciona é a resposta chegar sem redirecionamento; um portal de convidados que devolve todos os pedidos transforma a sonda em ruído.
As regras baseadas em domínio são uma forma à parte: NEEvaluateConnectionRule corresponde aos domínios pedidos e pode ligar-se quando um nome é resolvido. O seu curinga só é aceite como a etiqueta mais à esquerda, por isso *.example.com é válido enquanto example.*.com não é. Se um perfil não usa nem condições de interface nem sondas de alcance, verifique se usa antes esse tipo de regra.
O que as regras sob demanda não controlam
As regras escolhem se um túnel arranca e não têm palavra em mantê-lo a funcionar. Uma sessão que aparece e depois desaparece minutos depois aponta para temporizadores de inatividade, limites de sessão da gateway ou o tamanho do caminho. Cada um deixa um rasto diferente, e é por isso que convém eliminar a lista de regras antes de alterar qualquer um deles. As definições de keep-alive não explicam esse padrão, e alterá-las desloca o trabalho sem tocar na causa.
Os utilizadores podem desativar a função sob demanda nas Definições, e uma atribuição gerida pode restaurá-la no próximo registo. Quando o interruptor continua a voltar à posição anterior, a atribuição é a parte ativa. A distinção importa, porque a aplicação forçada volta sozinha enquanto uma oferta fica desligada.
Confirme que grupo de perfis possui o dispositivo e se a intenção é impor o túnel ou apenas oferecê-lo. Essa resposta decide se a preferência do utilizador conta como erro ou como funcionalidade.