Uma máquina dedicada a um gateway OpenVPN precisa de uma instalação de servidor suportada e do software para as tarefas que realmente executa. Um menu de instalação que oferece SSH, alojamento web e outras funções de servidor não é uma lista de pré-requisitos do OpenVPN. Uma implementação sem ecrã é perfeitamente razoável. O importante é separar três tarefas: transportar o túnel, administrar o anfitrião e emitir credenciais.

Esta é a ordem de inventário que utilizo, com a verificação que fecha cada passo.

1. Dê ao serviço de túnel o seu próprio pacote e perfil

O guia do servidor OpenVPN do Ubuntu utiliza o pacote openvpn da distribuição com uma linha de comandos e uma configuração de serviço. O mesmo pacote serve como cliente Linux, e a configuração escolhe a função.

Isso significa que instalar uma GUI de cliente não é o que transforma o anfitrião em servidor, e removê-la não é o que o torna sem ecrã. Registe que perfil lê a instância em execução, porque um segundo ficheiro de configuração no mesmo diretório pode ser carregado sem que ninguém repare, e o daemon comunica sucesso em ambos os casos. Quando existem dois perfis, o gestor de serviços decide qual ganha, e essa decisão pertence às suas notas e não a um palpite.

2. Decida o caminho de administração antes do túnel

O OpenSSH vem de um pacote openssh-server separado e corre como serviço próprio. É útil quando um administrador deve chegar à máquina por SSH, mas o OpenVPN não precisa de um servidor SSH para trocar pacotes VPN. Uma consola local ou um canal de gestão de plataforma aprovado é outro caminho válido. Decida em qual confia antes de alterar o encaminhamento ou a filtragem, porque um novo túnel nunca deve ser a única forma não testada de se reparar a si próprio.

3. Emita credenciais a partir do proprietário aprovado

O exemplo do Ubuntu instala o easy-rsa ao lado do OpenVPN para construir uma PKI pequena, o que é uma função de emissão de credenciais e não um serviço de túnel em funcionamento. Se a organização já tem um processo de emissão aprovado, use-o em vez de criar uma AC não relacionada só porque um tutorial inclui uma. Mantenha a chave privada e o certificado do gateway separados da chave de assinatura da AC, e escolha deliberadamente o local de assinatura e de cópia de segurança. Copiar todos os ficheiros de PKI para todos os anfitriões não é um requisito de software.

4. Deixe os plugins de ambiente de trabalho para os ambientes de trabalho

Um editor NetworkManager ou um plugin de importação tem um propósito numa máquina que usa esse fluxo de trabalho. Não é uma função de servidor adicional necessária porque o gateway fala OpenVPN.

Escolha um único proprietário para a ligação, e não inicie uma segunda cópia do mesmo perfil gerida a partir do ambiente de trabalho.

5. Aceite o gateway com um cliente real

Menos pacotes não é um gateway terminado. O servidor ainda precisa de um ouvinte aprovado, identidades, rotas, encaminhamento onde for necessário, uma política de firewall estreita e o caminho de retorno previsto. Anote onde aparecem os seus registos e como são aplicadas as atualizações, porque essas duas respostas decidem como uma falha será diagnosticada mais tarde.

Um desenho com saída para a internet e um desenho com acesso a uma rede privada têm requisitos de encaminhamento diferentes, por isso decida qual está a construir antes de abrir seja o que for. Levante um cliente aprovado e verifique o recurso previsto em vez do indicador do túnel. Depois reinicie o serviço de forma controlada e confirme o caminho de arranque sem supervisão, porque um gateway que só sobe enquanto alguém observa ainda não está implementado.

Artigos relacionados