Este plugin do NetworkManager consegue executar duas VPN ao mesmo tempo?

Há duas entradas VPN na lista de conexões, ambas dizem conectado, e apenas uma delas transporta o tráfego que você esperava. Ou a segunda se recusa a iniciar, e ninguém consegue dizer se a culpa é do plugin, do cliente ou de uma política esquecida. As afirmações sobre um limite de uma única VPN descrevem implementações específicas, e as implementações diferem. Percorra primeiro a capacidade, depois a coordenação.

Conte os perfis salvos e depois as ativações

Um perfil salvo é um objeto de configuração, e uma conexão ativa é uma instância em execução. A lista funde visualmente os dois conceitos, por isso os dois relatos soam verdadeiros. Comece nomeando os objetos exatos com seus UUIDs, porque o nome exibido não é único e uma importação antiga costuma compartilhar um rótulo com uma entrada mais recente. Depois verifique a lista de ativos separadamente e veja quais UUIDs aparecem. Só então você saberá se está comparando duas configurações ou dois túneis vivos.

Ativar o mesmo UUID duas vezes é um terceiro caso, e não é concorrência. É uma reativação de uma única instância.

Leia os metadados do próprio plugin

Cada plugin de VPN traz um pequeno arquivo de metadados que o gestor lê, e esses arquivos podem declarar se o plugin suporta várias conexões ao mesmo tempo. Leia o arquivo instalado nesta máquina em vez de repetir o que um projeto upstream escreve agora, porque o pacote da distribuição decide o que você realmente tem. A mesma verificação vale por protocolo: uma resposta para um plugin não diz nada sobre outro. Anote a versão do pacote junto ao resultado, para que uma comparação posterior signifique algo.

Os conselhos antigos sobre um limite de uma única VPN descreviam integrações mais antigas. Não é nem sempre verdadeiro nem seguro tomá-lo como fixo, e o arquivo à sua frente resolve isso localmente.

Concorrente não é coordenado

Que dois plugins iniciem com sucesso prova a capacidade, não o desenho. Dois túneis que ambos oferecem uma rota padrão vão competir, e o que instalou a sua rota por último costuma vencer sem anunciar. Faixas privadas sobrepostas têm o mesmo problema em forma menor.

Decida quais destinos pertencem a qual perfil antes de ativar qualquer coisa. Renomear um perfil não distingue os destinos.

O DNS escolhe um vencedor, quer você faça isso ou não

As configurações do resolvedor são por perfil, e quando dois estão ativos a ordem de resolução é decidida por política e prioridade, não por intenção. O perfil que subiu por último pode possuir silenciosamente todos os nomes corporativos.

Atribua cada espaço de nomes privado ao resolvedor que deve responder por ele, e defina a preferência de roteamento deliberadamente em vez de confiar na ordem. Depois teste um nome de cada espaço com os dois túneis levantados, e de novo com um deles desconectado. Um resolvedor que só funciona enquanto os dois túneis estão levantados é um desenho que vai surpreender alguém no pior momento possível.

Implante numa ordem fixa e inspecione entre etapas

Ative um perfil, inspecione o estado das suas rotas e do resolvedor, depois ative o segundo e inspecione novamente. Comparar os dois estados diz o que mudou e qual perfil possui o quê. Não ative os dois e depois diagnostique o resultado.

Teste cada recurso necessário através do túnel que deve transportá-lo, depois desconecte um perfil e confirme que o outro mantém as suas rotas, o seu DNS e o seu comportamento de falha pretendido. Se o plugin implantado realmente não consegue fazer o que você precisa, escolha uma atualização compatível ou uma alternativa explicitamente isolada em vez de reviver um protocolo obsoleto ao lado do gestor. Um segundo túnel separado que ninguém administra não é isolamento; é outra fonte de rotas surpreendentes.