Learning OpenVPN

Introdução

O OpenVPN é um software de código aberto que permite criar conexões VPN (Redes Virtuais Privadas) seguras e confiáveis. Com o OpenVPN, é possível criar uma rede privada virtual que conecta dispositivos em diferentes locais geográficos, permitindo a transmissão segura de dados através da Internet pública.

O OpenVPN suporta vários protocolos de criptografia, incluindo SSL (Secure Sockets Layer) e TLS (Transport Layer Security), que garantem a segurança das informações transmitidas. Além disso, o OpenVPN também usa a biblioteca OpenSSL para criação de configuração dos certificados usados. Inicialmente o OpenVPN não faz autenticação usando nome de usuário e senha, ele faz a autenticação e validação usando certificado digital, no entanto, é possível adicionar essa camada de proteção, para isso é usado plugins de autenticação, para mais detalhes veja aqui.

Uma das principais vantagens do OpenVPN é sua capacidade de operar em diferentes plataformas, incluindo Windows, Mac, Linux, Android e iOS. Isso significa que você pode usá-lo em praticamente qualquer dispositivo, desde desktops até smartphones. Outra vantagem do OpenVPN é que ele é bastante flexível e pode ser facilmente configurado para atender a diferentes requisitos de segurança. Por exemplo, é possível configurar o OpenVPN para autenticar usuários usando certificados digitais ou senhas.

Existem três tipos mais comuns de VPN:

VPN Intranet
Uma VPN Intranet é como uma rede privada que existe na Internet. Ela permite que funcionários de diferentes filiais ou escritórios de uma mesma organização se conectem entre si como se estivessem no mesmo local.
VPN Extranet
Uma VPN Extranet é como uma VPN Intranet, mas ela permite que usuários externos, como parceiros de negócios ou clientes, também se conectem à rede, compartilhando parcialmente com quem estiver conectado.
VPN de Acesso Remoto
Uma VPN de Acesso Remoto permite que usuários individuais ou dispositivos remotos se conectem à rede corporativa de forma segura pela Internet. É uma boa opção para funcionários que trabalham fora do escritório. A conexão é feita usando provedor de acesso (ISP) do cliente, a conexão também parte do cliente.

O OpenVPN suporta os dois modos de operação de VPN, sendo eles: site-to-site e gateway-to-gateway. A diferença principal entre os dois modos está no escopo da conexão VPN. No modo site-to-site, toda a rede de cada participante fica conectada, permitindo que todos os dispositivos dentro de ambas as redes se comuniquem como se estivessem na mesma rede local. Esse é o modo mais usual, quando um cliente se estabelece uma conexão com o servidor VPN voluntariamente.

Já no modo gateway-to-gateway os roteadores (gateways) de duas redes diferentes estão conectados diretamente por meio de uma VPN. A comunicação segura ocorre entre os gateways, criando um túnel seguro entre as duas redes. O objetivo principal dessa configuração é facilitar o acesso seguro a recursos específicos dentro de cada rede, em vez de permitir um acesso indiscriminado entre todos os dispositivos das duas redes. Isso proporciona maior controle sobre quais recursos podem ser acessados e por quem. Nesse modo o cliente nao faz uma conexão voluntária ao servidor VPN, o cliente se conecta na rede, e essa rede estará conectada no servidor VPN.

Por que usar VPN?

Geralmente as empresas precisam trafegar informações sensível por meio da Internet, para que a transmissão de dados seja feita de forma segura é usado uma Rede Virtual Privada (VPN), existem outras formas de fazer o mesmo mas teriam custos elevados, como o uso de links dedicados.

Além disso, a VPN também é usada para se conectar em uma rede que está em diferentes locais geográficos como se estivesse na mesma rede, como é criado um túnel criptografado entre o dispositivo e o servidor VPN, é como se o dispositivo conectado estivesse na mesma rede LAN.

Tunelamento

Quando falamos em "túnel" em uma VPN, não imagine um túnel físico, como em um ambiente geográfico, por exemplo, um túnel para passagens de veículos. Essa forma que falamos é uma metáfora para descrever que estamos usando uma conexão segura. O processo de tunelamento na VPN envolve o encapsulamento de um pacote em outro, criando um novo invólucro de proteção.

O que é Encapsulamento

O Encapsulamento é o processo de envolver dados em camadas adicionais de informações. Isso é feito para fornecer aos dados um contexto adicional que pode ser usado pelos dispositivos de rede para processá-los. Em Redes de Computadores, encapsulamento significa colocar os dados originais (chamados de payload) dentro de um novo invólucro (encapsulamento). Este invólucro contém informações de roteamento, segurança, controle de fluxo, cabeçalhos, metadados e etc.

No caso de uma VPN, o encapsulamento também adiciona informações de criptografia aos dados. Isso é necessário para proteger os dados de serem interceptados e lidos por terceiros. Alguns termos que podem ser vistos ao estudar sobre Encapsulamento e tunelamento:

Tunel é o termo mais usado para descrever um novo invólucro.
Encapsulation é um termo mais técnico, usado também para descrever um novo invólucro. O encapsulamento é um processo genérico que pode ser usado para adicionar informações adicionais a qualquer tipo de dados, mas no caso de VPN ou qualquer aplicação que crie um "túnel" (normalmente criptografado para proteção dos dados) é chamado de túnel.

A escolha de qual termo usar depende do contexto em que o novo invólucro está sendo aplicado.

O pacote original é chamado de payload, nele ficam armazenados os dados que desejamos transmitir, já o novo invólucro/pacote (que tem o pacote conhecido como payload dentro dele) é chamado de túnel. O túnel fornece um caminho seguro e isolado para o payload viajar através de uma rede pública, como a Internet. O túnel contém informações de roteamento (dentre elas o endereço IP de destino do servidor VPN), dessa forma o pacote (túnel) consegue chegar até o servidor VPN.

Enquanto o pacote (túnel) trafega pela Internet, ele protege o payload, garantindo que os dados permaneçam confidenciais e íntegros. Ao chegar no servidor VPN, o túnel é desencapsulado e as informações de roteamento e cabeçalhos são processadas, após isso o payload também é desencapsulado. Agora o servidor VPN contém um pacote com informações de roteamento que serão processados a partir do servidor VPN.

Os dados do payload são enfim encaminhados ao destino final, sendo na rede privada ou na internet, se for na internet, o dispositivo de origem (que está conectado na VPN) pode acessar as informações como se estivesse fisicamente localizado onde o servidor VPN está.

O tunelamento em uma VPN cria uma conexão criptografada entre um dispositivo e o servidor VPN. Isso é fundamental quando se utiliza uma rede pública. O túnel criptografado protege os dados transmitidos entre o dispositivo e o servidor VPN, fornecendo uma camada adicional de segurança. Como já foi dito, o tunelamento também permite que usuários acessem recursos de rede de forma segura como se estivessem fisicamente conectados à rede privada, mesmo estando em locais remotos. Isso é útil para acessar informações restritas por geolocalização, contornar restrições de censura ou melhorar a segurança em redes Wi-Fi públicas.

Um pouco mais sobre Túneis

Apesar de ter explicado tecnicamente o que é o túnel, muitas vezes no cotidiano as pessoas se referem ao túnel como sendo uma conexão virtual ponto-a-ponto que é estabelecida entre um dispositivo de origem e um dispositivo de destino. Uma conexão SSH (assim como uma VPN), estabelece um túnel criptografado, ou seja, estabelece uma conexão virtual ponto-a-ponto entre um dispositivo de origem e o servidor SSH.

A criptografia é adicionada ao processo de tunelamento no momento em que os dados são encapsulados para serem transmitidos pelo túnel. Quando enviamos informações sensíveis, como nomes de usuário e senhas, esses dados são criptografados antes de serem transmitidos pelo túnel VPN, isso significa que nesse ponto o túnel já foi estabelecido com o servidor VPN.

Vale notar que nem sempre um túnel é criptografado, alguns exemplos são: Generic Routing Encapsulation, L2TP - Layer 2 Tunneling Protocol e Multiprotocol Label Switching.

Como que conexão TCP, usada para navegar na internet funciona se a VPN está usando proto udp? O tráfego TCP é encapsulado em pacotes UDP para que possa ser enviado através de uma VPN que usa o protocolo UDP. Isso permite que o tráfego TCP seja enviado através de um túnel VPN que usa o protocolo UDP, é mais eficiente do que usar o protocolo TCP diretamente em uma VPN, pois não é necessário estabelecer uma conexão TCP.

O problema é que pode introduzir um pouco de overhead, pois o tráfego TCP é encapsulado em pacotes UDP. Não é tão confiável quanto usar o protocolo TCP diretamente em uma VPN, pois o tráfego TCP pode ser perdido ou corrompido. Uma recomendação de uso é, usar o TCP-over-UDP apenas para tráfego que não seja crítico.

Tipos de túneis

No contexto de VPNs, temos dois tipos de túneis que são categorizados pela forma como os túneis são estabelecidos.

Túnel Voluntários
Os túneis voluntários, também conhecidos como túneis de acesso remoto ou túneis de cliente, são iniciados voluntariamente pelos dispositivos clientes (usuários finais). Isso significa que um usuário decide estabelecer uma conexão VPN com um servidor VPN.
Túnel Compulsórios
Em um tunelamento compulsório, um servidor de acesso remoto configura e estabelece uma VPN usando um dispositivo chamado de dial-up access server (servidor de acesso discado), que atua como o cliente do túnel. E o cliente (usuário) se conecta ao servidor de acesso remoto para ter acesso a infraestrutura através do tunel.

Tunelamento em diferentes níveis do Modelo OSI

O tunelamento de camada 2 e camada 3 são os diferentes níveis do modelo OSI nos quais ocorre o encapsulamento dos dados:

Tunelamento de Camada 3
São túneis que encapsulam pacotes de camada 3, como pacotes IP. Esses túneis são usados para criar uma conexão lógica entre dois dispositivos que não estão diretamente conectados na rede. Eles são frequentemente usados para criar redes privadas virtuais (VPNs), GRE (Generic Routing Encapsulation), IPSec (Internet Protocol Security). Eles encapsulam pacotes IP, permitindo que esses pacotes sejam transmitidos por uma rede que pode não ser a rede original.
Tunelamento de Camada 2
São túneis que encapsulam quadros de camada 2, como quadros Ethernet. O objetivo é transportar protocolo nível 3, encapsulados em quadros da camada 2 (Ethernet). Assim eles criam uma conexão lógica entre dois dispositivos que não estão diretamente conectados na rede. São frequentemente usados para estender uma rede local (LAN) através de uma rede WAN. Os protocolos usados aqui são: PPPoE, L2TP e IPX.

Para que servem esse túneis?

Túneis de camada 3

Túneis IPsec: São túneis que usam o protocolo IPsec para fornecer segurança aos dados transmitidos.
Túneis GRE: São túneis genéricos que podem ser usados para transportar qualquer tipo de protocolo.
Túneis L2TP: São túneis que usam o protocolo L2TP para transportar quadros de camada 2.

Túneis de camada 2

Túneis PPPoE: São túneis que usam o protocolo PPPoE para transportar quadros de camada 2 sobre uma rede Ethernet. Túneis L2TP: São túneis que usam o protocolo L2TP para transportar quadros de camada 2. Túneis IPX: São túneis que usam o protocolo IPX para transportar quadros de camada 2.

Modos de Operação

Os modos de operação se referem à maneira como a VPN estabelece as conexões e gerenciam o tráfego de dados entre os dispositivos. Existem dois modos principais de operação em VPNs: Transporte e Túnel.

Modo de Transporte
No modo transporte, payload (dados) do pacote é criptografado e enviados pela Internet. O cabeçalho do pacote IP original é removido (Significa que o endereço IP de origem/destino e outros campos do cabeçalho IP original não são mais visíveis na comunicação) e um novo cabeçalho IP (contendo as informações necessárias para rotear o pacote até o servidor VPN) é adicionado ao pacote criptografado. O novo cabeçalho IP indica o destino do pacote criptografado.
Modo de Túnel
No modo túnel, todo o pacote IP original é encapsulado em um novo pacote IP. O novo cabeçalho IP indica o destino do túnel, que é um dispositivo de VPN na outra extremidade da conexão. O modo túnel é mais seguro do que o modo transporte porque encapsula todo o pacote IP original. Isso significa que os dados do aplicativo original são protegidos contra ataques na Internet. No entanto, o modo túnel pode ser menos eficiente do que o modo transporte porque requer o encapsulamento de todo o pacote IP original.

O modo de operação mais adequado para uma VPN depende das necessidades específicas da aplicação. Por exemplo, se a aplicação requer eficiência, o modo transporte pode ser uma boa opção. Se a aplicação requer segurança, o modo túnel pode ser uma boa opção.

No OpenVPN é possível trabalhar com ambos os modos de operação. O modo de Transporte é usado quando o dev tun é especificado no arquivo de configuração. Já o modo de Túnel é usado quando o dev tap é especificado no arquivo de configuração. Abaixo segue uma descrição sobre esses tipos de interfaces.

Interfaces Tun e Tap

TUN e TAP são interfaces de rede virtual (VPN) que são suportadas inteiramente por software. Elas diferem de interfaces de rede físicas, que são suportadas por hardware. TUN, que significa "túnel de rede", simula um dispositivo de camada de rede e opera na camada 3, transportando pacotes IP (É usado para roteamento e VPNs).

Já o TAP simula um dispositivo de camada de enlace e opera na camada 2, transportando quadros Ethernet. Pode ser usado para criar pontes de rede ou para conectar dispositivos virtuais a uma rede física.

Característica	TUN	TAP
Camada de rede	3 (Transporte)	2 (Enlace)
Tipo de pacote	Pacote IP	Quadro Ethernet
Usos típicos	Roteamento, VPN	Pontes de rede, dispositivos virtuais
Tipo de VPN	VPN de Acesso Remoto	VPN Intranet e Extranet

O exemplo de demonstração de configuração que vou usar é para o modo de Transporte, usando o TUN (claramente), para configurar o OpenVPN em modo de Túnel veja esse link, ele também descreve a configuração do OpenVPN no modo de Transporte.

Protocolos para criação de VPN

Existem vários protocolos amplamente utilizados para a criação de VPNs (Virtual Private Networks), cada um com suas características específicas.

Protocolo	Características Principais	Uso Comum
IPsec	Autenticação e criptografia para comunicações IP	VPNs de site a site, VPNs de acesso remoto
OpenVPN	Código aberto, usa SSL/TLS, configurável	VPNs de acesso remoto, VPNs de site a site
L2TP/IPsec	Combinação de L2TP e IPsec para criar túneis seguros. O L2TP (Layer 2 Tunneling Protocol) por si só não inclui criptografia, por isso precisa ser usado em conjunto com IPSec.	VPNs de acesso remoto, VPNs de site a site
PPTP	Mais antigo, menos seguro	Menos comum devido a preocupações de segurança
SSTP	Proprietário da Microsoft, usa SSL/TLS	VPNs de acesso remoto em ambientes Windows
IKEv2	Troca de chaves rápida e segura, usado com IPsec	VPNs de acesso remoto
WireGuard	VPN de código aberto, simples e eficiente	Ganhou popularidade rapidamente
GRE	Protocolo de encapsulamento, geralmente usado com IPsec	Túneis VPN em conjunto com IPsec

Camada criptográfica do OpenVPN

A camada criptográfica do OpenVPN é responsável por garantir a segurança e a privacidade nas comunicações entre os pontos finais de uma VPN. Existem dois modos principais de autenticação no OpenVPN: Chave Estática e SSL/TLS.

No modo de Chave Estática, uma chave pré-compartilhada contém chaves para autenticação HMAC e criptografia. Ambos os lados usam as mesmas chaves por padrão, mas a direção pode ser ajustada para usar chaves independentes. Esse método fornece simplicidade e facilidade de implementação, também oferece um desempenho melhor devido à sua abordagem direta. Já a sua segurança é limitada, já que a chave é compartilhada entre os pares, representando um risco se comprometida. Traz uma dificuldade na troca ou atualização da chave, o que pode comprometer a segurança se não realizada regularmente.

Falta de identificação individualizada para cada cliente, tornando difícil distinguir clientes em caso de problemas de segurança. Não suporta autenticação bidirecional, não verificando a identidade do cliente pelo servidor. Esse modelo de Chave estática só é recomendado quando for para estabelecer um túnel entre dois servidores, já que a aplicação e implementação é extremamente simples e rápida.

O modo de configuração usando Chave Estática não será demonstrado aqui, mas foi demonstrado como se utiliza na documentação para LPIC-2, pode consultar aqui, ele é um resumo mais simples deste documento.

No modo SSL/TLS, ocorre uma autenticação mútua com certificados. Após a autenticação bem-sucedida, material de chave para criptografia e HMAC é gerado aleatoriamente e trocado entre os pares. Cada par possui chaves distintas. Durante a renegociação SSL/TLS, há uma janela de transição para evitar pressão de tempo. O pacote criptografado inclui um HMAC, um IV explícito e um envelope criptografado. O IV é randomizado, e o OpenVPN utiliza a interface EVP do OpenSSL para funções criptográficas.

O OpenVPN oferece segurança adicional permitindo o uso de uma frase secreta pré-compartilhada com a diretiva --tls-auth, gerando uma chave HMAC para autenticar os pacotes. A estrutura do OpenVPN permite uma abordagem eficaz e independente entre as camadas de confiabilidade e autenticação.

tls-crypt-v2 versus tls-auth

O TLS Crypt v2 e TLS Auth são mecanismos de segurança que fornecem proteção adicional ao canal de controle do OpenVPN. O TLS Crypt v2 foi introduzido na versão 2.4 do OpenVPN e oferece melhorias significativas em relação ao seu antecessor, o TLS Crypt. O TLS Crypt v2 usa chaves específicas para cada cliente, o que significa que se a chave de um cliente for comprometida, apenas esse cliente será afetado. Em contraste, o TLS Auth usa uma chave compartilhada, o que poderia expor todo o tráfego se um cliente for comprometido.

O TLS Auth também usa criptografia de chave pública para autenticar os participantes da conexão e verificar a integridade dos dados. No entanto, ele não criptografa todo o tráfego do canal de controle. Além disso, o TLS Auth usa uma chave compartilhada por todos os perfis de conexão, o que pode reduzir a segurança se uma chave for comprometida. É altamente recomendável usar o TLS Crypt v2, pois ele oferece uma maior segurança e resistência a ataques futuros. No entanto, se você precisar de compatibilidade com versões anteriores do OpenVPN, o TLS Auth é uma opção viável.

Criptografia

O OpenVPN suporta vários tipos de encriptação de dados para garantir a segurança das informações transmitidas através da rede VPN, garantindo que apenas os envolvidos possam ler os dados transmitidos. Entre as opções de criptografia suportadas pelo OpenVPN, destacam-se:

Cipher Block Chaining (CBC)
Um modo de operação de criptografia que usa blocos de dados para criptografar informações.
Cipher Feedback (CFB)
Um modo de operação de criptografia que permite o uso de algoritmos de criptografia de bloco para proteger a confidencialidade dos dados.
Electronic Codebook (ECB)
Um modo de operação de criptografia que divide os dados em blocos e criptografa cada bloco separadamente.
Galois/Counter Mode (GCM)
Um modo de operação de criptografia que combina o modo de contador com a autenticação de mensagens usando códigos de autenticação de mensagem (MAC).

A partir do OpenVPN 2.5 a cifra padrão é AES-256-GCM com fallback para AES-256-CBC em configurações mais recentes e BF-CBC em configurações mais antigas. Ambos AES-256-CBC e AES-256-GCM são considerados seguros e atendem a rigorosos requisitos de segurança.

A escolha entre eles é, em grande parte, uma questão de desempenho, pois o AES-GCM oferece uma combinação mais eficiente de criptografia e autenticação em versões mais recentes do OpenVPN. O HMAC SHA1 é utilizado para autenticação de pacotes quando o modo CBC é utilizado.

Tipos de implantação do OpenVPN

As informações abaixo foram retiradas do site oficial e apenas traduzidas, pode consultar o material original aqui.

O OpenVPN Access Server é uma solução auto-hospedada com uma interface de gerenciamento baseada na web que permite executar seu próprio servidor VPN com base no OpenVPN em seu próprio servidor. Recomendamos essa solução para empresas que precisam de uma solução confiável de nível empresarial em seu próprio hardware. Os usuários podem acessar o serviço usando o software OpenVPN Connect.

OpenVPN2 é a versão principal atual do OpenVPN, oferecendo uma solução completa de cliente e servidor em várias plataformas. OpenVPN3 é uma biblioteca cliente com multithreading usada em OpenVPN Connect, OpenVPN Cloud e OpenVPN3 Linux client, sendo este último um projeto da comunidade para um cliente de próxima geração com integração dbus e usando OpenVPN3.

O cliente OpenVPN Connect é a aplicação para Windows, macOS, Android e iOS recomendada para uso com as soluções comerciais da OpenVPN. É gratuito e deve ser compatível com servidores e serviços OpenVPN de código aberto, embora isso não seja garantido.

Como vamos instalar no nosso servidor, vamos focar em soluções auto-hospedada (self-hosted), mas não vou instalar usando interface web integrada, apesar de ser um boa para gerenciar várias conexões, o uso do CLI para uma rede pequena/média deve bastar, além do mais, se dominar a CLI, instalar e gerencia com web não será um problema. Portanto, no nosso caso vamos instalar o OpenVPN2, mais precisamente a versão 2.6.

Problemas com o uso da VPN

Antes de iniciar de fato a instalação e configuração, tem um detalhe muito importante que pode e vai afetar muitas pessoas com o uso da VPN. A VPN geralmente envolve o uso de sub-redes privadas de diferentes locais, ou seja, normalmente é atribuído redes privadas para a VPN, enquanto que a rede LAN do cliente também usa uma rede privada.

Para melhor exemplificar, imagine que a rede da VPN seja 192.168.1.0/24, enquanto que a rede do cliente (que está se conectando na VPN) também seja 192.168.1.0/24, isso vai causar um conflito de sub-rede. Acontece que ambas as redes estão usando o mesmo intervalo de endereços IP (192.168.1.0/24), o que pode levar a problemas de roteamento, já que a máquina do cliente não sabe se o IP 192.168.1.10 deve ser acessado via VPN ou via rede local. Pode ocorrer também um roteamento assimétrico, onde os pacotes seguem caminhos diferentes dependendo da direção da comunicação. Isso pode levar a problemas de conectividade.

A solução para esse problema é evitar usar redes que sabemos que tem uma probabilidade maior de estarem em uso, principalmente em Aeroportos, Wifi públicas, Hotéis e etc. A documentação oficial recomenda usar algo dentro de 10.0.0.0/8, como 10.66.77.0/24. Lembrando que essa rede é a rede que será entregue para os clientes que se conectem no servidor VPN, na configuração ela se chama server como em server 10.0.0.0 255.255.255.0.

Lembrando que isso também é uma boa prática, nunca colocar a rede de conexão do servidor VPN na mesma rede em que ele está, por exemplo, o servidor VPN está na rede 192.168.1.0/24, nesse caso, devemos colocar os cliente VPN em outra rede. A imagem abaixo descreve um outro problema comum, um cliente conectado na rede de um Hotel se conecta no servidor VPN que está em sua casa, para acessar uma camera de segurança:

Rede com problema de roteamento

A imagem é apenas ilustrativa para evidenciar um problema, um muito comum alias. Nesse tipo de cenário teremos o mesmo problema descrito acima (conflito de sub-rede). Primeiro, a rede local do cliente é 192.168.1.0/24, já a rede de pool do servidor VPN é 10.80.200.0/24, isso segue duas boas práticas; não usar endereços de rede privadas que sejam muito comum, para não ter problemas de roteamento e não colocar o pool da VPN na mesma rede em que a VPN está na rede LAN (que nesse caso é 192.168.1.0/24).

Para o cliente acessar a camera na rede local dele, tera que injetar uma rota estática pela VPN e também liberar o roteamento no servidor VPN entre as interfaces da LAN e do Pool, esse processo é simples, mas o ponto é, quando o cliente tentar acessar 192.168.1.232/24 (camera de segurança) irá ocorrer um problema de roteamento. Lembra que injetamos a rota 192.168.1.0/24 pela VPN? Só que ela também é uma rede local do Hotel, temos novamente um conflito de sub-rede.

Um pool refere-se a um conjunto de endereços IP que estão disponíveis para serem atribuídos aos dispositivos conectados à VPN.

Infelizmente para resolver esse conflito, a rede LAN doméstica não poderá estar numa sub-rede previsível, ou seja, teremos que colocar a sub-rede da rede doméstica em outro endereço, esse problema é muito comum em VPNs que usam endereços privados na rede corporativa.

Download e Instalação

O OpenVPN pode ser instalado via código fonte (sendo necessário compilar) ou através de dois repositórios distintos, um deles é o repositório padrão da distribuição Linux nativa, no qual a versão deve ser um pouco antiga e o outro repositório é mantido pela comunidade.

Nesse momento, a versão no repositório do Ubuntu 22.04 é 2.5.9, enquanto que a versão no repositório da comunidade e a versão via código fonte é 2.6.8, vou usar o repositório. Outra coisa, farei todo o processo usando o usuário root.

# Crie o diretório para armazenar a chave do repositório do OpenVPN da comunidade:
mkdir -p /etc/apt/keyrings

# Baixe a chave e armazene no diretório criado:
curl -fsSL https://swupdate.openvpn.net/repos/repo-public.gpg | gpg --dearmor > /etc/apt/keyrings/openvpn-repo-public.gpg

# Adicione o repositório da comunidade:
echo "deb [arch=<arch> signed-by=/etc/apt/keyrings/openvpn-repo-public.gpg] https://build.openvpn.net/debian/openvpn/<version> <osrelease> main" > /etc/apt/sources.list.d/openvpn-aptrepo.list

Muita atenção no comando acima, é necessário modificar algumas informações no repositório:

Em <arch> devemos configurar a arquitetura que vamos usar, elas podem ser: amd64, arm64 e i386.
Em <version> devemos configurar a versão do OpenVPN, recomendo deixar stable, ela traz sempre a última versão do OpenVPN.
E em <osrelease> devemos colocar qual a nossa distribuição, algumas opções são:

stretch (Debian 9.x)
buster (Debian 10.x)
bullseye (Debian 11.x)
bookworm (Debian 12.x)
bionic (Ubuntu 18.04 LTS)
focal (Ubuntu 20.04 LTS)
jammy (Ubuntu 22.04 LTS)
kinetic (Ubuntu 22.10)
lunar (Ubuntu 23.04)

No meu caso a configuração ficou assim:

echo "deb [arch=amd64 signed-by=/etc/apt/keyrings/openvpn-repo-public.gpg] https://build.openvpn.net/debian/openvpn/stable jammy main" > /etc/apt/sources.list.d/openvpn-aptrepo.list

Vamos continuar a configuração:

# Após configurado, vamos instalar os pacotes abaixo:
apt-get update && apt dist-upgrade -y && apt-get -y install easy-rsa openvpn

O easy-rsa é um utilitário simples de CA baseado em Shell, você pode fazer todo o processo manualmente de criar um CA se preferir. Outro detalhe, alguns diretório serão criados em locais não muito padronizados, até existe um consenso de onde devem ficar alguns desses diretórios, mas não vou seguir para que o usuário do OpenVPN não possa ter acesso diretamente.

# Crie o grupo para o usuário do openvpn:
groupadd -g 130 openvpn

# Crie o usuário de sistema que vamos usar para executar o BIND:
adduser --system --gid 130 --uid 130 --disabled-login --disabled-password --home /etc/openvpn/ openvpn

# Verifique se foi criado:
getent passwd openvpn
openvpn:x:130:130:::/usr/sbin/nologin

# Verifique se o grupo foi criado (provavelmente foi):
getent group openvpn
openvpn:x:130:

Configurando o OpenVPN

Agora vamos configurar o OpenVPN.

# Crie o diretório abaixo:
mkdir -p /etc/openvpn/{server,keys,scripts}

# Crie o diretório/link abaixo para facilitar a administração:
mkdir ~/easy-rsa && ln -s /usr/share/easy-rsa/* ~/easy-rsa/

# Entre no diretório e vamos iniciar nossa pki:
cd ~/easy-rsa/ && ./easyrsa init-pki

init-pki complete; you may now create a CA or requests.
Your newly created PKI dir is: /root/easy-rsa/pki

# Agora vamos construir nossa CA:
./easyrsa build-ca

# Copie a CA para o diretório 'keys':
cp /root/easy-rsa/pki/ca.crt /etc/openvpn/keys/

# Crie o certificado do servidor VPN e depois assine usando a CA:
./easyrsa build-server-full servervpn nopass
./easyrsa sign-req server servervpn

# Copie o certificado e a chave privada para o diretório 'keys':
cp /root/easy-rsa/pki/private/servervpn.key /etc/openvpn/keys/
cp /root/easy-rsa/pki/issued/servervpn.crt /etc/openvpn/keys/

# Baixe a chave para o Diff Hellman
cd /etc/openvpn/keys/ && wget https://raw.githubusercontent.com/internetstandards/dhe_groups/master/ffdhe4096.pem

# Crie o certificado tls-crypt-v2:
/sbin/openvpn --genkey tls-crypt-v2-server vpn_server.pem

# Habilite o roteamento no servidor para rotear da rede virtual (VPN) para rede física:
echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.conf && sysctl -p /etc/sysctl.conf

# Corrija as permissões do diretório:
chown -R openvpn:openvpn /etc/openvpn

Agora vamos criar a configuração do servidor OpenVPN:

# Edite o arquivo abaixo:
vim /etc/openvpn/server/server.conf

############################
#          Global          #
############################

mode server
topology subnet
local 192.168.1.40
dev tun
proto udp
port 11094
server 10.80.122.0 255.255.255.0
persist-key
persist-tun
keepalive 10 60
float
max-clients 2
auth-nocache
explicit-exit-notify 1
user openvpn
group openvpn
#up "/etc/openvpn/scripts/up.sh"
#down "/etc/openvpn/scripts/down.sh"

############################
#          Segurança       #
############################

tls-crypt-v2 /etc/openvpn/keys/vpn_server.pem
dh /etc/openvpn/keys/ffdhe4096.pem
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/servervpn.crt
key /etc/openvpn/keys/servervpn.key
script-security 2
cipher AES-256-GCM
verify-client-cert require
# openssl x509 -noout -fingerprint -sha1 -in /etc/openvpn/keys/ca.crt
verify-hash 1D:5B:E7:3B:05:33:14:19:49:AE:64:DA:0F:D7:EC:D2:91:A0:E9:7A
#tls-verify "/etc/openvpn/scripts/verify-common_name.sh"
#client-connect "/etc/openvpn/scripts/client_connection.sh"
#crl-verify /etc/openvpn/keys/crl.pem 

############################
#          Push            #
############################

#push "route 192.168.1.0 255.255.255.0"

############################
#          Logs            #
############################
ifconfig-pool-persist /var/log/openvpn/ip-tun-pool.log
log /var/log/openvpn/openvpn.log
log-append /var/log/openvpn/openvpn.log
status /var/log/openvpn/status.log

# 0 is silent, except for fatal errors
# 4 is reasonable for general usage
# 5 and 6 can help to debug connection problems
# 9 is extremely verbose
verb 3

Não se esqueça de corrigir o fingerprint no arquivo acima:

openssl x509 -noout -fingerprint -sha1 -in /etc/openvpn/keys/ca.crt
sha1 Fingerprint=1D:5B:E7:3B:05:33:14:19:49:AE:64:DA:0F:D7:EC:D2:91:A0:E9:7A

Abaixo segue uma tabela descrevendo as opções de configuração usadas no OpenVPN:

Opção	Descrição
mode server	Define o modo de operação do servidor VPN.
topology subnet	Especifica a topologia de rede como sub-rede, permitindo que clientes se comuniquem entre si.
local 192.168.1.40	Define o endereço IP local do servidor OpenVPN.
dev tun	Indica o tipo de dispositivo virtual a ser usado (TUN para encapsulamento de camada 3).
proto udp	Especifica o protocolo de transporte UDP.
port 11094	Define a porta UDP na qual o servidor OpenVPN escutará conexões.
server 10.80.122.0 255.255.255.0	Especifica o endereço IP da rede virtual a ser distribuída aos clientes conectados.
persist-key	Mantém as chaves de criptografia na memória entre reinícios do servidor OpenVPN.
persist-tun	Mantém as interfaces virtuais na memória entre reinícios do servidor OpenVPN.
keepalive 10 60	Envia mensagens de verificação de atividade a cada 10 segundos e considera a conexão perdida após 60 segundos sem resposta.
float	Permite que o servidor OpenVPN altere seu endereço IP sem interromper as conexões dos clientes.
max-clients 2	Limita o número máximo de clientes conectados simultaneamente a 2.
auth-nocache	Não armazene em cache nome de usuário/senhas na memória virtual, serve para as opções `--askpass` ou `--auth-user-pass`.
explicit-exit-notify 1	Envia uma notificação explícita aos clientes quando o servidor OpenVPN é encerrado.
user openvpn	Executa o servidor OpenVPN como o usuário "openvpn".
group openvpn	Executa o servidor OpenVPN como o grupo "openvpn".
tls-crypt-v2 /etc/openvpn/keys/vpn_server.pem	Habilita a proteção TLS-Crypt v2 para fortalecer a segurança da conexão.
dh /etc/openvpn/keys/ffdhe4096.pem	Especifica o arquivo contendo parâmetros Diffie-Hellman para troca de chaves.
ca /etc/openvpn/keys/ca.crt	Especifica o certificado da autoridade certificadora (CA) para autenticação de clientes.
cert /etc/openvpn/keys/servervpn.crt	Especifica o certificado do servidor OpenVPN.
key /etc/openvpn/keys/servervpn.key	Especifica a chave privada do servidor OpenVPN.
script-security 2	Restringe a execução de scripts externos por motivos de segurança.
cipher AES-256-GCM	Define o algoritmo de cifragem AES-256-GCM para proteger o tráfego.
verify-client-cert require	Exige que os clientes apresentem um certificado válido para se conectarem.
#up "/etc/openvpn/scripts/up.sh"	Executa o script "up.sh" após o inicio do daemon do OpenVPN. Está comentado.
#down "/etc/openvpn/scripts/down.sh"	Executa o script "down.sh" após o encerramento do daemon do OpenVPN. Está comentado.
verify-hash 1D:5B:E7:3B:05:33:14:19:49:AE:64:DA:0F:D7:EC:D2:91:A0:E9:7A	Verifica a impressão digital SHA1 do certificado da CA para garantir sua autenticidade.
#push "route 192.168.1.0 255.255.255.0"	Envia uma rota estática para os clientes, permitindo acesso à rede 192.168.1.0/24. Está comentado.
ifconfig-pool-persist /var/log/openvpn/ip-tun-pool.log	Mantém um registro dos endereços IP atribuídos aos clientes para persistir a alocação entre reinicializações.
log /var/log/openvpn/openvpn.log	Especifica o arquivo de log principal do OpenVPN.
log-append /var/log/openvpn/openvpn.log	Acrescenta as novas entradas de log ao arquivo de log principal.
status /var/log/openvpn/status.log	Especifica o arquivo de log para registrar o status do servidor OpenVPN.
verb 3	Define o nível de verbosidade dos logs (3 é um nível razoável para uso geral).

Hardening da VPN

Como medida de segurança, para aumentar mais ainda a segurança de quem pode se conectar na VPN, vou criar dois scripts, um verifica o CN do certificado, se não for alterado nada no CA, o CN vai ter o nome do usuário, nesse caso, apenas quem tiver o nome num arquivo específico poderá logar na VPN.

O segundo script fará uma verificação do fingerprint do certificado de usuário que está se conectando, se o fingerprint não estiver no arquivo, significa que o certificado de usuário não será reconhecido por nós, nesse caso a conexão será negada. Isso é apenas uma camada a mais de segurança, o próprio OpenVPN faz algumas verificações para validar a conexão.

Esse passo é opcional e pode ser ignorado.

Liberando conexão por nome de usuário

Vamos criar um script para melhorar a segurança de quem pode conectar no servidor baseado no nome do usuário.

# Crie o script abaixo:
vim /etc/openvpn/scripts/verify-common_name.sh

################ Inicio ################

#!/usr/bin/bash 

depth=${1}
CN="${@:2}"

#echo "${depth} - ${CN}"

if [ ${depth} -eq 1 ];then

        if grep -q 'CN=My CA' <<< ${CN};then
                exit 0
        else
                exit 1
        fi

elif [ ${depth} -eq 0 ];then

        if grep -Eq "^${CN}$" /etc/openvpn/allowed_clients;then
                exit 0
        else
                exit 1
        fi

else
        echo "Error" >> /tmp/error-openvpn.log
fi
################ FIM ################

# Crie a entrada no arquivo, vamos permitir um certificado que tenha 'CN=fulano':
echo "CN=fulano" > /etc/openvpn/allowed_clients

# Agora dê permissão de execução:
chmod +x /etc/openvpn/scripts/verify-common_name.sh

Antes de encerrar, descomente a linha #tls-verify "/etc/openvpn/scripts/verify-common_name.sh" no arquivo server.conf.

Liberando conexão por fingerprint

Agora vamos criar o segundo script, só vamos aceitar conexões se for reconhecido o fingerprint do certificado do usuário.

# Crie o script:
vim /etc/openvpn/scripts/client_connection.sh

################ INI ################

#!/usr/bin/bash 

echo "Starting Client verification..."

ca_fingerprint_256="51:39:b9:46:3f:5a:b8:0b:14:17:1b:68:d2:cd:9e:de:25:6a:27:b1:8d:83:d6:0d:59:9a:bf:cb:2d:ab:0e:c3"

# temporary file:
#echo "${@}"

FINGERxCN=$(grep -E "^${common_name}-" /etc/openvpn/allowed_clients_fingerprint | tr '[:upper:]' '[:lower:]')
file_finger=$(cut -d '-' -f2 <<<${FINGERxCN} )

#echo -e "CN=${common_name} \nFile:${FINGERxCN} \nsha256-0: ${tls_digest_sha256_0} \nsha256-1: ${tls_digest_sha256_1} \nfilefinger: ${file_finger}"

if [ ${file_finger} == "${tls_digest_sha256_0}" ] && [ "${ca_fingerprint_256}" == ${tls_digest_sha256_1} ] ;then
    exit 0
else
    exit 1
fi

# openssl x509 -fingerprint -sha256 -in bruno/bruno.crt -noout
# echo "B0:A9:CD:35:5C:A7:2F:D2:05:FA:9A:8D:FB:14:B3:44:57:96:5E:DC:B5:7D:B8:E9:6E:09:A1:A8:70:32:4E:91" >> /etc/openvpn/allowed_clients_fingerprint

# https://build.openvpn.net/man/openvpn-2.5/openvpn.8.html#environmental-variables

################ FIM ################

# Agora dê permissão de execução:
chmod +x /etc/openvpn/scripts/client_connection.sh

# Não se esqueça de corrigir o fingerprint do arquivo acima:
openssl x509 -noout -fingerprint -sha256 -in /etc/openvpn/keys/ca.crt | tr 'A-Z' 'a-z'
sha256 fingerprint=51:39:b9:46:3f:5a:b8:0b:14:17:1b:68:d2:cd:9e:de:25:6a:27:b1:8d:83:d6:0d:59:9a:bf:cb:2d:ab:0e:c3

Antes de encerrar, descomente a linha #client-connect "/etc/openvpn/scripts/client_connection.sh" no arquivo server.conf.

Script para gerar o arquivo OVPN

Agora vamos criar o script que vai gerar o arquivo .ovpn dos usuário, dessa forma eles poderão importar no cliente VPN a configuração de acesso.

# Crie o diretório abaixo:
cd ~/vpn_clients/ 

# Crie o script:
vim make_ovpn.sh

############# Inicio #############
#!/bin/bash 

# 1 argument = Client_identifier
cat << EOF > ${1}.ovpn
client
dev tun
proto udp
persist-tun
persist-key
nobind
cipher AES-256-GCM
resolv-retry infinite
remote 192.168.1.40 11094 udp
remote-cert-tls server
verify-hash 1D:5B:E7:3B:05:33:14:19:49:AE:64:DA:0F:D7:EC:D2:91:A0:E9:7A
verb 3
#auth SHA256
#reneg-sec 0
#lport 0
#verify-x509-name "C=${1}" subject
#auth-user-pass
#auth-nocache
#user nobody
#group nobody
<ca>
$(cat ~/vpn_clients/ca.crt)
</ca>
<cert>
$(awk '/-----BEGIN CERTIFICATE-----/,/-----END CERTIFICATE-----/' ~/vpn_clients/${1}/${1}.crt)
</cert>
<key>
$(cat ~/vpn_clients/${1}/${1}.key)
</key>
<tls-crypt-v2>
$(cat ~/vpn_clients/${1}/${1}.pem)
</tls-crypt-v2>
EOF
############## FIM #############

# Não se esqueça de corrigir o fingerprint acima:
openssl x509 -noout -fingerprint -sha1 -in /etc/openvpn/keys/ca.crt
sha1 Fingerprint=1D:5B:E7:3B:05:33:14:19:49:AE:64:DA:0F:D7:EC:D2:91:A0:E9:7A

# Agora dê permissão de execução:
chmod +x make_ovpn.sh

Criando nosso primeiro acesso

Vamos criar os certificados para que o usuário possa acessar:

# Agora crie um diretório para ele dentro do diretório onde vamos armazenar os certificados de usuários:
mkdir -p ~/vpn_clients/fulano

# Crie um Link da CA para ~/vpn_clients:
cp /etc/openvpn/keys/ca.crt ~/vpn_clients/ca.crt

# Entre no diretório onde temos o pki, para gerarmos os certificados:
cd ~/easy-rsa/

# Gere o certificado do usuário 'fulano':
./easyrsa build-client-full fulano

# Assine o certificado assinado:
./easyrsa sign-req client fulano

# Entre dentro do diretório pki:
cd ~/easy-rsa/pki/

# Agora gere o tls-crypt-v2 para o usuário:
/sbin/openvpn --tls-crypt-v2 /etc/openvpn/keys/vpn_server.pem --genkey tls-crypt-v2-client ~/vpn_clients/fulano/fulano.pem

# Entre no diretório do usuário:
cd ~/vpn_clients/fulano

# Copie os arquivos dele:
cp /etc/openvpn-clients/fulano.pem .
cp ~/easy-rsa/pki/private/fulano.key .
cp ~/easy-rsa/pki/issued/fulano.crt .

# Agora para obter o certificado:
~/vpn_clients/make_ovpn.sh fulano

# Agora vamos liberar o login do usuário, primeiro com a parte do fingerprint:
openssl x509 -fingerprint -sha256 -in fulano.crt -noout

# Coloque o fingerprint no arquivo:
echo "fulano-0F:AA:96:CA:8D:5B:68:2C:BF:D7:8C:52:16:C8:CC:39:C4:B5:98:F7:3E:F2:A2:F6:D7:89:3E:FF:FF:75:C7:51" >> /etc/openvpn/allowed_clients_fingerprint

# Não esqueça de verificar o outro arquivo:
cat /etc/openvpn/allowed_clients
CN=fulano

Agora inicie o serviço da VPN:

systemctl start openvpn-server@server.service
systemctl status openvpn-server@server.service
systemctl enable openvpn-server@server.service

Agora basta enviar o fulano.ovpn para o usuário correto!

Gerando o CRL - Impedindo um usuário de logar

Quando um usuário tiver seus arquivos da VPN (certificados e tls-crypt-v2) comprometidos, temos que revogar o certificado para impedir que ele consiga logar novamente na VPN. Outro caso que temos que fazer isso é quando o certificado de usuário expirar, quando a CA expirar (nesse caso teremos que refazer o certificado de todos os usuários) ou quando o usuário sair da empresa ou coisa do tipo.

# Entre no diretório abaixo:
cd ~/easy-rsa/

# Revogue o certificado do usuário fulano:
/root/easy-rsa/easyrsa revoke fulano

# Gere um certificado contendo a lista de certificado revogados:
/root/easy-rsa/easyrsa gen-crl

# Agora copie essa lista para o diretório 'keys':
cp /root/easy-rsa/pki/crl.pem /etc/openvpn/keys/

# Reinicie o daemon do openvpn:
systemctl restart openvpn-server@server.service

Descomente a linha #crl-verify /etc/openvpn/keys/crl.pem no arquivo server.conf. Se você aplicou o Hardening, remova ou comente o CN do usuário no arquivo /etc/openvpn/allowed_clients e remova ou comente o Fingerprint do usuário no arquivo /etc/openvpn/allowed_clients_fingerprint.

Acessando outras redes

Esse arquivo de configuração do OpenVPN funciona, mas caso você queira se conectar num dispositivo que está em outra rede? Primeiro o servidor da VPN tem que ter acesso nessa rede, e caso tenha, teremos que fazer alguns ajustes.

No meu caso, eu quero acessar a rede 192.168.1.0/24, percebe que é a mesma rede em que o servidor da VPN está local 192.168.1.40, primeiro nós temos que injetar essa rota via VPN, para que os dispositivos conectado na VPN saibam que para acessar 192.168.1.0/24 é via VPN (lembra que isso pode dar conflito).

Para fazer isso descomente a linha #push "route 192.168.1.0 255.255.255.0" no arquivo server.conf. Como vamos estar conectados na rede 10.80.122.0/24 temos que liberar o redirecionamento de pacotes da rede 10.80.122.0/24 para a interface na rede LAN. Primeiro, descomente as linhas abaixo no arquivo server.conf.

#up "/etc/openvpn/scripts/up.sh"
#down "/etc/openvpn/scripts/down.sh"

Agora vamos criar esses scripts. O script up.sh será executado quando o daemon do OpenVPN for iniciado, já o script down.sh será o inverso, vai ser executado quando o daemon do OpenVPN for encerrado.

# Edite o arquivo abaixo:
vim /etc/openvpn/scripts/up.sh

#################### INICIO DO SCRIPT ####################
#!/usr/bin/bash

net_pool_vpn_ip="10.80.122.0/24"
net_external_ip="192.168.1.0/24"
net_external_interface="eth0"


echo "UP Scripting..."

## Assim que o daemon for iniciado, as regras abaixo serão aplicadas
# Regras aplicadas para liberar Internet via VPN:
iptables -t nat -A POSTROUTING -s ${net_pool_vpn_ip} -d ${net_external_ip} -o ${net_external_interface} -j MASQUERADE

# Liberando comunicação da rede do POOL para a Internet:
iptables -A FORWARD -s ${net_pool_vpn_ip} -d ${net_external_ip} -o ${net_external_interface}  -j ACCEPT
iptables -A FORWARD -d ${net_pool_vpn_ip} -s ${net_external_ip} -i ${net_external_interface}  -j ACCEPT

# Ativando o FORWARD de pacotes no Kernel:
echo 1 > /proc/sys/net/ipv4/ip_forward

exit 0
####################   FIM DO SCRIPT  ####################

# Adicione a permissão de execução:
chmod +x /etc/openvpn/scripts/up.sh

Mude o que for necessário para a execução correta do script acima. A variável net_pool_vpn_ip informa qual o endereço de pool que será usado pelo servidor VPN para entregar IP para os clientes da VPN, net_external_ip é a rede que queremos acessar e net_external_interface contém o nome da interface de rede no servidor VPN que tem acesso a outras redes e/ou até mesmo a internet.

Os mais familiarizados com Redes e regras de firewall podem se perguntar o porque estou usando MASQUERADE, já que o servidor VPN tem acesso a ambas as redes e que estou liberando o roteamento entre elas.

Acontece que quando o cliente VPN (na rede 10.80.122.0/24) tenta se comunicar com algum dispositivo na rede 192.168.1.0/24, o dispositivo que queremos acessar precisa saber como rotear os pacotes de volta para a sub-rede 10.80.122.0/24, como ele não sabe, a comunicação não vai funcionar. Adicionar uma rota estática no dispositivo que queremos acessar apontando para o gateway na sub-rede do OpenVPN resolveria esse problema, mas daria mais trabalho, criar um MASQUERADE é muito mais simples.

Esse é um exemplo real que uso na minha casa, numa rede corporativa, por favor, não corte caminhos, faça o roteamento de forma correta, fica até melhor para gerencia o acessos pelas redes.

Agora vamos criar o segundo script.

# Edite o arquivo abaixo:
vim /etc/openvpn/scripts/down.sh

#################### INICIO DO SCRIPT ####################
#!/usr/bin/bash

net_pool_vpn_ip="10.80.122.0/24"
net_external_ip="192.168.1.0/24"
net_external_interface="eth0"

echo "DOWN Scripting..."

## Assim que o daemon for encerrado, as regras abaixo serão removidas

# Regras aplicadas para liberar Internet via VPN:
iptables -t nat -D POSTROUTING -o ${net_external_interface} -s ${net_pool_vpn_ip} -d ${net_external_ip} -j MASQUERADE

# Liberando comunicação da rede do POOL para a Internet:
iptables -D FORWARD -i ${net_external_interface} -d ${net_pool_vpn_ip} -d ${net_external_ip} -j ACCEPT
iptables -D FORWARD -o ${net_external_interface} -s ${net_pool_vpn_ip} -s ${net_external_ip} -j ACCEPT

# Ativando o FORWARD de pacotes no Kernel:
echo 0 > /proc/sys/net/ipv4/ip_forward

exit 0
####################   FIM DO SCRIPT  ####################

# Adicione a permissão de execução:
chmod +x /etc/openvpn/scripts/down.sh

# Agora reinicie o daemon do OpenVPN:
systemctl restart openvpn-server@server.service

Ativando uma VPN com IPv6/Gateway default

A configuração que usamos não entrega IPv6 para os clientes e não adicionar um gateway default para os dispositivos conectados. O Gateway default Gateway padrão, é o dispositivo (gateway) que os clientes usam para acessar a Internet. É por meio dessa configuração que vamos criar uma VPN onde os clientes possam usar a conexão da VPN para acessar a Internet, seja em IPv4 ou IPv6.

Segue o arquivos de configuração do OpenVPN:

############################
#          Global          #
############################

mode server
topology subnet
local xxxx.xxxx.xxxx.xxxx
dev tun
proto udp
port 11094
server 10.88.60.0 255.255.255.0
server-ipv6 2001:db8:0:123::/64
persist-key
persist-tun
keepalive 10 60
float
max-clients 2
auth-nocache
explicit-exit-notify 1
user openvpn
group openvpn
up "/etc/openvpn/scripts/up.sh"
down "/etc/openvpn/scripts/down.sh"

############################
#          Segurança       #
############################

tls-crypt-v2 /etc/openvpn/keys/vpn_server.pem
dh /etc/openvpn/keys/ffdhe4096.pem
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/servervpn.crt
key /etc/openvpn/keys/servervpn.key
script-security 2
cipher AES-256-GCM
verify-client-cert require
# openssl x509 -noout -fingerprint -sha1 -in /etc/openvpn/keys/ca.crt
verify-hash xx:xx:xx:xx:xx:xx:xx:xx:xx:xx::xx:xx:xx:xx:xx:xx:xx:xx:xx
tls-verify "/etc/openvpn/scripts/verify-common_name.sh"
crl-verify /etc/openvpn/keys/crl.pem 
client-connect "/etc/openvpn/scripts/client_connection.sh"

############################
#          Push            #
############################

push "dhcp-option DNS 2001:4860:4860::8888"
push "dhcp-option DNS 2001:4860:4860::8844"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"

# A linha abaixo é usada para instruir os clientes a redirecionar todo o seu tráfego de rede através da conexão VPN.
push "redirect-gateway autolocal" 
push "redirect-gateway ipv6"

############################
#          Logs            #
############################
ifconfig-pool-persist /var/log/openvpn/ip-tun-pool.log
log /var/log/openvpn/openvpn.log
log-append /var/log/openvpn/openvpn.log
status /var/log/openvpn/status.log

# 0 is silent, except for fatal errors
# 4 is reasonable for general usage
# 5 and 6 can help to debug connection problems
# 9 is extremely verbose
verb 3

Basicamente a diferença desse arquivo para o outro está na tabela abaixo:

Aqui está a tabela com duas colunas descrevendo as opções da configuração OpenVPN:

Opção	Descrição
server 10.88.60.0 255.255.255.0	Especifica o endereço IP da rede virtual a ser distribuída aos clientes conectados.
server-ipv6 2001:db8:0:123::/64	Especifica o endereço IP da rede virtual IPv6 a ser distribuída aos clientes conectados.
push "dhcp-option DNS 2001:4860:4860::8888"	Envia uma opção DHCP para os clientes, definindo o endereço IP do servidor DNS 1 para 2001:4860:4860::8888.
push "dhcp-option DNS 2001:4860:4860::8844"	Envia uma opção DHCP para os clientes, definindo o endereço IP do servidor DNS 2 para 2001:4860:4860::8844.
push "dhcp-option DNS 8.8.8.8"	Envia uma opção DHCP para os clientes, definindo o endereço IP do servidor DNS 3 para 8.8.8.8.
push "dhcp-option DNS 8.8.4.4"	Envia uma opção DHCP para os clientes, definindo o endereço IP do servidor DNS 4 para 8.8.4.4.
push "redirect-gateway autolocal"	Envia uma opção DHCP para os clientes, instruindo-os a redirecionar todo o tráfego de rede IPv4 local para o servidor VPN.
push "redirect-gateway ipv6"	Envia uma opção DHCP para os clientes, instruindo-os a redirecionar todo o tráfego de rede IPv6 para o servidor VPN.

Basicamente o que importa é server-ipv6, redirect-gateway autolocal e redirect-gateway ipv6, os DNS v4 e v6 também são bem importantes. Agora temos que criar as regras de firewall para que tudo funcione, abaixo seguem os dados dos scripts.

Script up.sh:

vim /etc/openvpn/scripts/up.sh

#################### INICIO DO SCRIPT ####################
#!/usr/bin/bash

net_pool_vpn_ip="10.88.60.0"
net_pool_vpn_ip6="2001:db8:0:123::/64"
net_external_interface="eth0"

echo "UP Scripting..."

## Assim que o daemon for iniciado, as regras abaixo serão aplicadas

# Regras aplicadas para liberar Internet via VPN:
iptables -t nat -A POSTROUTING -s ${net_pool_vpn_ip} -o ${net_external_interface} -j MASQUERADE
ip6tables -t nat -A POSTROUTING -s ${net_pool_vpn_ip6} -o ${net_external_interface} -j MASQUERADE

# Liberando comunicação da rede do POOL para a Internet:
iptables -A FORWARD -s ${net_pool_vpn_ip} -o ${net_external_interface}  -j ACCEPT
iptables -A FORWARD -d ${net_pool_vpn_ip} -i ${net_external_interface}  -j ACCEPT

ip6tables -A FORWARD -s ${net_pool_vpn_ip6} -o ${net_external_interface} -j ACCEPT
ip6tables -A FORWARD -d ${net_pool_vpn_ip6} -i ${net_external_interface} -j ACCEPT

# Ativando o FORWARD de pacotes no Kernel:
echo 1 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv6/conf/all/forwarding

exit 0
####################   FIM DO SCRIPT  ####################

Script down.sh:

# Edite o arquivo abaixo:
vim /etc/openvpn/scripts/down.sh

#################### INICIO DO SCRIPT ####################
#!/usr/bin/bash

net_pool_vpn_ip="10.88.60.0"
net_pool_vpn_ip6="2001:db8:0:123::/64"
net_external_interface="eth0"

echo "DOWN Scripting..."

## Assim que o daemon for encerrado, as regras abaixo serão removidas

# Regras aplicadas para liberar Internet via VPN:
iptables -t nat -D POSTROUTING -o ${net_external_interface} -s ${net_pool_vpn_ip} -j MASQUERADE
ip6tables -t nat -D POSTROUTING -o ${net_external_interface} -s ${net_pool_vpn_ip6} -j MASQUERADE

# Liberando comunicação da rede do POOL para a Internet:
iptables -D FORWARD -i ${net_external_interface} -d ${net_pool_vpn_ip} -j ACCEPT
iptables -D FORWARD -o ${net_external_interface} -s ${net_pool_vpn_ip} -j ACCEPT

ip6tables -D FORWARD -i ${net_external_interface} -d ${net_pool_vpn_ip6} -j ACCEPT
ip6tables -D FORWARD -o ${net_external_interface} -s ${net_pool_vpn_ip6} -j ACCEPT

# Ativando o FORWARD de pacotes no Kernel:
echo 0 > /proc/sys/net/ipv4/ip_forward
echo 0 > /proc/sys/net/ipv6/conf/all/forwarding

exit 0

####################   FIM DO SCRIPT  ####################

A diferença aqui é que estamos habilitando o roteamento no Kernel para IPv4 e IPv6, assim como o masquerade inclui o IPv6, dessa forma, o cliente pode alcançar qualquer destino via VPN, seja ele com IPv4 ou IPv6.