Uma VPN secundária pertence a um perfil Wi-Fi, não a todos

Configure uma VPN como secundária da conexão Wi-Fi de casa e tudo funciona, até que o portátil se junte a outro ponto de acesso e o túnel fique inativo. A nova conexão é um objeto de configuração separado com o seu próprio UUID, e não tem qualquer razão para conhecer o vínculo que criou para o seu antecessor. Nada avariou; a associação simplesmente nunca existiu.

A referência de conexões do NetworkManager define as secundárias como UUID que se ativam juntamente com uma determinada conexão base. Refere também que os perfis VPN comuns não implementam a ativação automática como as conexões base. Ambas as afirmações conduzem à mesma conclusão: a associação é por perfil, e alguém tem de a criar para cada novo.

O que é realmente uma secundária

Uma conexão base tem uma identidade, um UUID e uma lista de secundárias. Quando se ativa, o gestor também ativa essas secundárias por ordem, e é assim que uma VPN acaba por seguir uma rede Wi-Fi sem um clique manual. A relação reside na conexão base, escrita como cadeias UUID em vez de nomes. Essa escolha de representação não é casual; é o que faz a associação sobreviver a uma mudança de nome.

Esse detalhe sobre os nomes importa mais do que parece. Mudar o nome de um perfil VPN deixa o seu UUID intacto, pelo que as associações existentes continuam a funcionar. Apagar o perfil antigo e importar um novo produz um UUID novo, e todas as associações que apontavam para o antigo passam a não apontar para nada.

Reveja a lista existente antes de acrescentar. Um perfil doméstico com uma secundária não é uma regra que sirva para todos os SSID; é uma linha num objeto, e não será consultada quando uma base diferente se ativar.

Coloque a associação onde os perfis são criados

Numa máquina pessoal, faça do anexo da secundária pretendida uma parte de adicionar cada perfil Wi-Fi permitido. É um hábito mais do que uma funcionalidade, mas um hábito que produz um estado consistente, e custa um comando ou duas visitas ao diálogo por rede. Mantenha uma nota curta sobre quais redes devem transportar o túnel, porque a lista é a política.

Nos dispositivos geridos, faça com que o fluxo de aprovisionamento crie a entrada Wi-Fi e a sua associação VPN no mesmo passo, e aplique o mesmo tratamento aos perfis permitidos que já existem. Distribuir um perfil VPN isoladamente deixa as relações base por especificar, e é assim que uma frota acaba com um túnel que apenas metade dos portáteis utiliza.

Onde os utilizadores ainda podem criar perfis fora do caminho gerido, decida explicitamente o que acontece a essas entradas. Supor que herdam uma associação não é uma política; é uma esperança com um custo de suporte associado.

Planeie a mudança de identidade da VPN

A fonte de aprovisionamento precisa do UUID da VPN pretendida, não de um nome de apresentação que alguém adivinhou. Quando a manutenção substituir essa VPN por um objeto recentemente importado, atualize o modelo de aprovisionamento e as associações existentes afetadas na mesma alteração. Mudar o nome não é substituir, e tratar os dois como equivalentes é como uma implementação funcional se quebra uma semana depois.

Guarde o UUID junto ao motivo pelo qual existe. Um engenheiro futuro que encontre um UUID nu numa lista de secundárias não tem forma de saber se está atual, e provavelmente irá apagá-lo enquanto arruma.

A ativação não é aplicação forçada

Um pedido de secundária ocorre no momento da ativação. Não bloqueia as aplicações durante o intervalo antes de a autenticação terminar, e não para o tráfego depois de o túnel falhar. São propriedades diferentes, fornecidas por mecanismos diferentes, e confundi-las produz um desenho que parece rigoroso no perfil e é permissivo na prática.

Bloquear o tráfego direto é uma funcionalidade separada com a sua própria configuração e os seus próprios modos de falha, e tem de considerar o tráfego que tem de chegar à rede antes de qualquer túnel poder existir: portais cativos, páginas de início de sessão, o próprio ponto final. Uma política de bloqueio que não pode ser satisfeita antes da autenticação deixa a máquina fora da rede de que necessita.

Inclua essa distinção nas instruções que os utilizadores realmente leem. Uma nova rede Wi-Fi pode pedir o túnel; a aplicação forçada decide se algo pode sair quando não consegue ligar-se. Os utilizadores a quem só se conta a primeira metade vão relatar que o desenho está avariado.

Teste com um perfil genuinamente novo

Utilize uma rede de teste aprovada e um perfil base recentemente criado, não a entrada doméstica que já funciona. Observe a ativação da base, o UUID de secundária solicitado e qualquer pedido de autenticação em sequência, e anote em que etapa bloqueia quando bloqueia. Um agente secreto que fica disponível após o início de sessão no ambiente de trabalho não está automaticamente presente em todos os contextos de arranque, pelo que um reinício pertence ao plano de testes. Depois verifique o recurso pretendido e o caminho de falha: o túnel sobe antes de a aplicação precisar dele, e o que acontece a essa aplicação quando a autenticação falha?

Depois verifique o recurso pretendido e o caminho de falha: o túnel sobe antes de a aplicação precisar dele, e o que acontece a essa aplicação quando o túnel não consegue autenticar-se? Essas duas observações são os critérios de aceitação, e nenhuma delas é visível no próprio perfil.