Três notebooks em uma mesma equipe, três menus de VPN diferentes e um chamado dizendo que a conexão funciona em todo lugar, menos no Mac. O plano por trás desses clientes pode ser idêntico mesmo quando os menus não são. O que precisa estar alinhado é mais estreito do que a maioria das implantações supõe: uma identidade de gateway, um tipo de credencial, um conjunto de rotas e uma política de resolvedor. Anote esses quatro pontos antes que alguém exporte um perfil, e o trabalho de plataforma vira uma lista de verificação em vez de uma investigação.

Comece pelo contrato de acesso, não pelo arquivo do cliente

O contrato de acesso são cinco linhas que um revisor consegue conferir sem abrir o console de um fornecedor. Ele nomeia os prefixos privados que precisam ser alcançáveis, os nomes internos que precisam resolver, o resolvedor que responde por eles, o tráfego autorizado a permanecer no caminho local e o certificado de gateway que o cliente deve esperar ver. Todo o resto da implantação é a tradução dessas linhas para um formato de arquivo.

Um exemplo de escritório deixa a forma concreta: servidores de aplicação em 10.60.0.0/16, nomes privados sob corp.example, um resolvedor interno em 10.61.0.53 e a navegação comum deixada no caminho que o dispositivo já usa. Esse último item é uma decisão de política, não um padrão do cliente, e vários clientes mandam tudo pelo túnel se ninguém disser o contrário. Registre o contrato com data e responsável, porque é esse registro que mais tarde dirá se mudou o túnel ou a política.

Escolha um protocolo e um par de autenticação que você consiga defender

IKEv2 com autenticação de gateway baseada em certificado e EAP para o usuário é a escolha usual quando as três plataformas precisam funcionar sem software extra, já que Windows, macOS e NetworkManager trazem cada um um cliente IKEv2. O problema é que suportar IKEv2 descreve um rótulo, não um conjunto de recursos. Métodos EAP, chaves respaldadas por hardware, mapeamento de certificado para conta e reconexão automática são implementados plataforma por plataforma. Uma combinação que funciona em duas das três é comum o bastante para você presumi-la até testá-la.

Teste o par em todas as plataformas alvo antes de escrever o guia de implantação, não depois. Um gateway que oferece tanto EAP-MSCHAPv2 quanto EAP-TLS dá margem para um fallback, desde que o fallback esteja documentado como suportado e não descoberto durante um incidente. Dois caminhos suportados são um seguro barato; um terceiro caminho não documentado é um chamado futuro.

Quando nenhum par cobre os três clientes, as opções honestas são acrescentar um cliente, acrescentar um perfil no gateway ou restringir a lista de plataformas suportadas. Desligar a validação de certificado na plataforma que reclama mais alto não é uma delas. Essa mudança transforma uma lacuna de compatibilidade em risco de interceptação, e nenhum passo posterior da implantação a conserta.

Construa um artefato por plataforma a partir do contrato

O Windows usa um perfil VPNv2, entregue por MDM ou criado localmente com Add-VpnConnection mais o payload XML. As partes que pegam são escopo e confiança. Um perfil com escopo de dispositivo e um com escopo de usuário são instalados em repositórios diferentes, então o certificado de que o cliente precisa deve estar no repositório que corresponde ao escopo escolhido. Errar esse pareamento gera um perfil que importa sem erro e falha na primeira conexão.

O macOS usa um perfil de configuração com o payload de VPN gerenciado, assinado e distribuído por MDM ou instalado à mão em um piloto. A identidade e a cadeia de CA viajam como payloads separados, e é por isso que um perfil pode instalar sem queixa e falhar na hora de conectar. Confira a lista de payloads, não só o resultado da instalação.

O Linux depende do backend por trás do NetworkManager, e strongSwan mais o plugin do NetworkManager são pacotes separados. As propriedades de conexão são específicas do plugin e não chaves genéricas de VPN, então uma chave copiada de outro plugin costuma salvar sem erro e falhar na ativação. Monte a conexão em uma imagem limpa para confirmar que o plugin está presente onde ela realmente vai rodar.

Os três artefatos diferem em formato, mas cada um codifica as mesmas cinco linhas do contrato. Esse é o teste para saber se um artefato está pronto: cada linha está representada em algum lugar e nada de extra foi inventado pelo caminho.

PlatformArtifactCheck before handoff
WindowsVPNv2 profile or Add-VpnConnectionScope matches certificate store
macOSManaged VPN payload plus certificate payloadBoth payloads present in one profile
LinuxNetworkManager connection with strongSwan backendPlugin package installed on the image

Verifique rotas, resolvedor e reconexão em uma conta limpa

Conectado não é o teste de aceitação. No Windows, Get-VpnConnection mostra o perfil e route print mostra se o prefixo privado foi parar na interface do túnel. No macOS, scutil --nc list confirma o serviço ativo enquanto scutil --dns mostra a ordem de resolvedores que o sistema realmente vai usar.

No Linux, nmcli connection show --active prova que a conexão está no ar e resolvectl status mostra o DNS por link. Um resolvedor presente no arquivo de conexão mas ausente da saída por link significa que o DNS dividido não está sendo aplicado. Essa é a diferença entre nomes que resolvem e nomes que resolvem pelo túnel, e ela muda qual equipe de suporte é dona do próximo passo. Compare a saída por link antes e depois de a conexão subir, não só depois.

Faça toda a verificação com uma conta nova, sem credenciais em cache e sem certificado instalado pelo administrador. Depois repita após uma suspensão e retomada, e mais uma vez após forçar a redigitação da credencial. Essas duas transições revelam a maior parte das falhas de reconexão que uma primeira conexão nunca mostra.

Versione o pacote e mantenha um caminho de rollback

Marque cada pacote de plataforma com a revisão de contrato que ele implementa e anote as versões de cliente e de gateway com que você o aceitou. Quando o comportamento muda após uma atualização de cliente, a marca aponta para um contrato a retestar em vez de um arquivo a adivinhar.

Mantenha o pacote anterior de cada plataforma recuperável e escreva o comando de remoção ao lado dele. Desinstalar um perfil de VPN não é a imagem espelhada de instalá-lo no Windows, no macOS ou no Linux, e as diferenças aparecem no pior momento possível. Ensaie a remoção uma vez em um dispositivo reserva para que o arquivo vire plano, não esperança.

Artigos relacionados