Por que copiar a configuração do servidor OpenVPN para uma filial falha

Copiar a configuração do servidor que funciona, trocar alguns endereços e chamar isso de perfil de filial costuma produzir uma conexão. Esse é o pior resultado, porque a filial passa a rodar com o papel errado, expõe material que não deveria sair do concentrador e deixa uma associação de rota que ninguém lembra ter criado. A conexão esconde três problemas de uma vez, e o túnel sobe antes de alguém verificá-los.

Tratar a filial como um par com identidade e papel de rede próprios é o que torna o perfil correto. A correção não é uma cópia melhor, e o restante desta página trata do que um cliente deveria realmente guardar.

Dois papéis que parecem um único arquivo

No modo TLS, os dois lados têm tarefas complementares. Um lado escuta, guarda o certificado e a chave do servidor e decide quais clientes podem conectar. O outro lado inicia, verifica o ouvinte e apresenta sua própria identidade.

Um arquivo de servidor contém diretivas que não fazem sentido em um cliente: um endereço de vinculação e porta para escutar, um conjunto de endereços para distribuir e, muitas vezes, uma lista de envio para configurações que os clientes deveriam receber. Copiar isso para uma filial produz um dispositivo que tenta ser ouvinte e cliente ao mesmo tempo.

A chave privada é a parte que mais importa. Um cliente nunca deve carregar a chave privada do servidor, e também não precisa da chave de assinatura da CA. Um certificado de CA é material público de confiança; a chave de assinatura pertence ao local onde os certificados são emitidos.

O que um perfil de filial deve conter

Um perfil de filial precisa do endpoint remoto e do transporte, da identidade de servidor confiável, do certificado e da chave próprios da filial, e das rotas e configurações de DNS que a filial realmente exige. Nada mais é obrigatório.

Mantenha a identidade da filial separada por site. Duas filiais compartilhando um certificado significam que revogar uma desativa a outra, e os registros do concentrador não conseguem distingui-las. Uma identidade por site é o que faz o rastro de auditoria e a história de revogação funcionarem.

Cuidado com os fluxos dos equipamentos. O pacote Client Export do pfSense gera perfis para contextos de Remote Access elegíveis, e sua lista de servidores inclui apenas servidores configurados em um modo Remote Access. Um servidor site a site de outro modo não aparece, e essa ausência é informação, não um convite para copiar os segredos do servidor.

Se o equipamento não exporta o perfil de que você precisa, use o fluxo de cliente site a site documentado ou monte o perfil a partir do exemplo suportado da versão instalada. Exporte um backup do servidor para a filial apenas se o plano for restaurar um servidor, o que não é o caso. Um backup também carrega material privado do concentrador, então movê-lo para uma filial é uma decisão de manuseio de chaves, não uma transferência de arquivo. Mantenha-o no concentrador e gere a identidade do cliente onde os certificados são emitidos.

A associação entre par e rede é separada

Um cliente de filial que conecta com sucesso ainda não consegue passar tráfego para sua LAN até que o concentrador saiba que este par possui esse prefixo. Essa associação vive no concentrador, vinculada à identidade do cliente, e é separada da rota própria da filial para as redes remotas. Sem ela, os hosts da filial parecem alcançáveis nas estatísticas do túnel e não são na prática. O registro do concentrador é o lugar onde se confirma se a associação foi aplicada.

Adicionar uma rota no sistema operacional do concentrador não é o mesmo que dizer ao OpenVPN qual cliente possui o prefixo. Sem a associação por cliente, o pacote chega à interface do túnel e é descartado porque nenhum par reivindica o destino.

No lado da filial, a necessidade correspondente é uma rota para as redes que ela deve alcançar, mais um roteador de LAN que saiba devolver o tráfego à filial. A propriedade no lado do servidor e as rotas de destino no lado do cliente são objetos distintos, e um túnel funcionando só prova o primeiro salto. Anote os dois nas notas de passagem da filial, porque o próximo engenheiro só encontrará um deles.

Provar que a filial é o par que você pensa

Verifique a identidade antes de verificar o tráfego. O registro do concentrador deve mostrar o nome comum do certificado da filial, e o endereço que o cliente recebeu deve corresponder ao conjunto ou à atribuição fixa que você pretendia. Se o registro mostrar outro nome, o perfil está carregando a identidade de outra pessoa.

Depois verifique a associação enviando uma requisição de um host da filial para um recurso do lado do concentrador e confirme que ela tem sucesso com o endereço de origem esperado. Teste um destino que a filial não deve alcançar e confirme que falha, porque uma rota permissiva que funciona por acaso não é o mesmo que uma política correta.

Por fim, revogue a identidade da filial e confirme que a conexão falha enquanto o certificado do próprio concentrador e os demais sites continuam funcionando. Se a revogação quebra o concentrador, papéis e identidades foram compartilhados em algum lugar, e esse é o achado que vale a pena levar de volta ao projeto.

Uma filial concluída é aquela com identidade documentada, perfil apenas de cliente, uma associação entre par e rede no concentrador e um caminho de volta testado. Inverter o texto de um arquivo de servidor não lhe dá nada disso.