Aplicação VPN do fornecedor versus NetworkManager: quem é dono do estado?
Um perfil nomeia um plug-in, não o comportamento do cliente do fornecedor. Mapeie quem é dono do registo, do DNS, do bloqueio e das atualizações antes de trocar um portátil gerido.
Importar um perfil não é o mesmo que substituir um cliente. O NetworkManager guarda um tipo de plug-in juntamente com dados e segredos específicos do plug-in, e é o plug-in que possui esse tipo que decide o que a ligação pode fazer. Tudo o que a aplicação do fornecedor coloca por cima, desde o registo até ao bloqueio permanente, vive fora do ficheiro. Se a troca é segura depende das camadas em que realmente confia.
O ficheiro nomeia um plug-in, não um conjunto de funcionalidades
A referência de definições de VPN do NetworkManager descreve um tipo de serviço que seleciona o plug-in, além de um dicionário de dados opaco e um dicionário de segredos que só o plug-in interpreta. O perfil é um contrato com uma implementação, não a descrição de um comportamento que qualquer cliente possa reproduzir. Dois clientes podem falar o mesmo protocolo e ainda assim divergir no que negoceiam e nos caminhos de dados que ativam. O rótulo de um protocolo diz-lhe o que é o túnel, nunca o que o cliente em volta faz com ele.
Compare, portanto, requisitos em vez de invólucros. A questão não é se a alternativa consegue ligar-se, porque normalmente consegue; é se cada requisito que tornava o cliente original aceitável sobrevive à mudança. Escreva esses requisitos antes de instalar seja o que for, ou a comparação transforma-se numa caça ao que se quebra primeiro.
O que a aplicação do fornecedor acrescenta em torno do túnel
Os clientes dos fornecedores costumam agrupar o registo e as verificações de postura do dispositivo, um fluxo de segundo fator com interface própria, o bloqueio permanente, um canal de atualizações e ferramentas de suporte. Parte disso está ao lado do protocolo, e parte é um produto separado que apenas partilha um instalador. O NetworkManager pode substituir o túnel e o seu encaminhamento, e scripts de despachante podem disparar ações quando o estado da ligação muda. Não reproduz, porém, um motor de bloqueio, um fluxo de renovação de certificados nem uma suposição sobre que utilizador pode levantar a ligação.
Mais componentes não significa mais seguro, e menos não significa mais fraco. A questão é qual componente aplica a política que lhe disseram para seguir. Se um auditor perguntar o que bloqueia o tráfego quando o túnel cai, a resposta tem de nomear algo que realmente o faça, e um perfil que apenas liga não é essa resposta.
Onde a propriedade difere de facto
Leia isto como um mapa de propriedade e não como uma lista de verificação, porque as falhas abaixo são lacunas de propriedade e nenhuma quantidade de configuração do cliente as fecha. Cada linha nomeia a camada, o lado que normalmente a detém hoje e onde a lacuna aparece primeiro.
| Layer | Vendor application | NetworkManager connection | Where the gap shows up |
|---|---|---|---|
| Enrollment and posture | built into the client | absent unless something else supplies it | a managed device fails its next posture check |
| Address and resolver authority | the client sets both | the plugin plus dispatcher scripts | names resolve through the wrong resolver after a state change |
| Blocking on drop | a bundled engine | nothing by default | traffic continues in the clear after the tunnel dies |
| Upgrade path | the vendor's own channel | the distribution package and its plugin | a plugin update changes behaviour with no vendor note |
| Diagnostics and support | vendor tooling with client state | journal and dispatcher output | support cannot see why negotiation failed |
Associe cada linha a uma observação que possa repetir, e não a uma impressão sobre o cliente. Um nome resolvido pelo resolvedor previsto, uma rota que desaparece quando o túnel para e uma ligação bloqueada após um corte simulado são três observações que, em conjunto, cobrem a maior parte da tabela. Escreva a observação ao lado do requisito que prova, e guarde as que falharam, porque uma observação falhada é a única parte do registo que prevê o próximo incidente.
Trocar sem sobrepor a propriedade
Executar ao mesmo tempo o cliente do fornecedor e uma ligação do NetworkManager para o mesmo serviço é a forma mais comum de estas comparações correrem mal. Ambos instalam rotas, ambos podem definir o DNS e ambos podem tocar no estado da firewall. O que mede então é um terceiro arranjo que não corresponde ao comportamento documentado de nenhum dos dois clientes.
nmcli -f NAME,UUID,TYPE connection show
nmcli connection show work --show-secrets | grep -E "^vpn\."
journalctl -u NetworkManager -b --since "10 min ago"O primeiro comando diz se o perfil é sequer do tipo VPN. O segundo mostra o tipo de serviço do plug-in e que segredos estão guardados, o que importa quando se espera uma chave de um agente em vez do ficheiro. O registo é o local onde um plug-in que carregou mas não conseguiu negociar o dirá. Se nenhum dos três mostrar um problema, a lacuna está nas camadas de política acima do túnel e não na ligação.
Desligue o cliente antigo antes de ativar a nova ligação, mantenha os pontos finais e a conta idênticos, e anote qual componente é dono das rotas, das definições do resolvedor e do bloqueio. É essa nota que impede a próxima atualização de terminar com dois proprietários.