[TUTORIAL] Criando VPN Avançada com OpenVPN - PARTE 02

Postador por Tiago Damasceno

Usar chaves estáticas permite criar VPNs rapidamente, interligando duas máquinas. A facilidade de configuração faz com que esta modalidade seja a mais utilizada, embora as limitações sejam claras. Nesta segunda parte do tutorial, estudaremos a configuração avançada do OpenVPN, utilizando certificados X509, opções adicionais de configuração e a criação de bridges, que permite efetivamente unir as duas redes, incluindo até mesmo tráfego de broadcast.

Clique aqui para ler a PARTE 01

Usar chaves estáticas permite criar VPNs rapidamente, interligando duas máquinas. A facilidade de configuração faz com que esta modalidade seja a mais utilizada, embora as limitações sejam claras.

Vamos agora criar uma configuração mais elaborada, utilizando certificados X509. Este método é chamado de PKI (Public Key Infraestructure) e permite criar VPNs mais complexas, envolvendo vários servidores e vários clientes, além de oferecer uma maior segurança.

Para isso, criaremos uma "entidade certificadora", que será usada para gerar os certificados usados pelo servidor e pelos clientes. Falar em uma "entidade certificadora" dá a impressão de que precisaremos contratar uma empresa especializada para gerar os certificados, mas, na verdade, tudo é feito internamente, usando scripts fornecidos junto com o OpenVPN.

Durante o processo, é gerado um certificado mestre (um arquivo, que pode ser tanto armazenado pelo próprio servidor quanto por outra máquina da rede) que é usado para gerar os certificados usados pelas máquinas. O uso dos certificados permite que o servidor verifique a identidade dos clientes e também que os clientes verifiquem a identidade do servidor, evitando a possibilidade do uso de ataques "man-in-the-middle", onde alguém substitui o servidor por outra máquina, configurada para capturar as credenciais dos clientes quando eles tentam estabelecer a conexão.

Os certificados podem ser criados rapidamente, conforme for necessário conectar mais máquinas à VPN. Quando é necessário bloquear o acesso a uma determinada máquina (um funcionários que se desligou da empresa, por exemplo), basta revogar o certificado para que o servidor deixe de aceitar a conexão.

CRIANDO CERTIFICADOS

Para criar os certificados, utilizaremos o easy-rsa, um conjunto de scripts incluídos no pacote do OpenVPN. Na maioria das distribuições, os scripts estão disponíveis dentro da pasta "/usr/share/doc/openvpn/examples/easy-rsa". Se a pasta não existir na sua instalação, use os comandos abaixo para localizar a pasta:

# updatedb
# locate easy-rsa

Duas localizações comuns são as pastas "/usr/share/doc/packages/openvpn/easy-rsa" e "/usr/share/doc/openvpn-2.0/easy-rsa". No Fedora, especificamente, é usada a pasta "/usr/share/openvpn/easyrsa" e no CentOS é usada a pasta "/usr/share/doc/openvpn-2.0.9/easy-rsa/" (onde o 2.0.9 é a versão do pacote).

O primeiro passo é copiar todo o diretório para dentro da pasta "/etc/openvpn" (você pode usar outro diretório se preferir). Isso evita que nossa configuração seja apagada ao atualizar o pacote do OpenVPN no futuro. No Debian o comando seria:

# cp -a /usr/share/doc/openvpn/examples/easy-rsa /etc/openvpn/

No Fedora, onde a localização da pasta é diferente, o comando seria:

# cp -a /usr/share/openvpn/easyrsa /etc/openvpn/

Isso criará o diretório "/etc/openvpn/easy-rsa", contendo os seguintes arquivos:

2.0 build-key build-req make-crl revoke-full
build-ca build-key-pass build-req-pass openssl.cnf sign-req
build-dh build-key-pkcs12 clean-all README.gz vars
build-inter build-key-server list-crl revoke-crt

Em outras distribuições basta verificar qual é a pasta onde estão os exemplos e ajustar o comando de acordo.

A partir daí, toda a configuração será feita dentro do novo diretório:

# cd /etc/openvpn/easy-rsa

Comece editando o arquivo "vars" usando seu editor de textos preferido:

# joe vars

No final do arquivo, você encontra um conjunto de parâmetros usados para gerar as chaves (país, estado, cidade, empresa, etc.), que devem ser editados, como em:

export KEY_COUNTRY=BR
export KEY_PROVINCE=SP
export KEY_CITY="Guarulhos"
export KEY_ORG="GDH"
export KEY_EMAIL="morimoto@guiadohardware.net"

Em seguida, usamos o comando "source" para carregar as variáveis contidas dentro do arquivo "vars" e em seguida executamos os scripts "clean-all" e "build-ca". O primeiro script limpa qualquer sobra de configuração anterior, enquanto o segundo gera o certificado raiz, usando o openssl. Como os scrips estão dentro do diretório atual, usamos o "./" ao executá-los:

# source vars
# ./clean-all
# ./build-ca

Generating a 1024 bit RSA private key
...................++++++
.....................++++++
writing new private key to 'ca.key'
-----
You are about to be asked to enter information that will be incorporated into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [BR]:
State or Province Name (full name) [SP]:
Locality Name (eg, city) [Guarulhos]:
Organization Name (eg, company) [GDH]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:
Email Address [morimoto@guiadohardware.net]:

Isso criará a pasta "/etc/openvpn/easy-rsa/keys", contendo os seguintes arquivos:

ca.crt ca.key index.txt serial

O arquivo "ca.crt" contém o certificado raiz. Ele jamais deve sair do servidor, já que qualquer um que tenha acesso a ele poderá gerar certificados adicionais que, essencialmente, permitirão que qualquer um se conecte à VPN. A necessidade de manter esse arquivo secreto faz com que alguns administradores prefiram gerar as chaves em uma máquina desconectada da rede (apenas com acesso local) e copiar manualmente os certificados gerados para o servidor e as demais máquinas.

Depois de criar o certificado raiz, podemos passar para o para o passo seguinte, que é gerar os certificados para o servidor e para os clientes.

Para gerar o certificado do servidor, usamos o script "build-key-server", especificando como parâmetro o nome do arquivo que será gerado ("servidor" no exemplo). O nome é apenas para identificação dos hosts, você pode usar os nomes que preferir:

# cd /etc/openvpn/easy-rsa/
# ./build-key-server servidor

Ele começa confirmando as informações que serão incluídas no certificado (país, cidade, empresa, etc.), da mesma forma que ao rodar o build-ca. Em um certo ponto, ele perguntará pelo atributo "Common Name", onde você deve fornecer o nome do servidor, como em:

Common Name (eg, your name or your server's hostname) []:Etch

Em seguida, ele oferece a opção de incluir um "challenge password", uma senha que será solicitada cada vez que o certificado for usado. Ela aumenta a segurança, mas em compensação reduz bastante a praticidade, já que você precisará digitar a senha cada vez que o certificado for utilizado, o que pode se tornar incrivelmente inconveniente em um servidor administrado remotamente. Se quiser manter as coisas simples, deixe o campo em branco:

A challenge password []:

Antes de terminar, ele confirma se você deseja assinar o certificado e pede mais uma confirmação antes de aplicar a alteração. Responda "y" em ambas, caso contrário a geração do certificado é abortada:

Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y

Em seguida, geramos as chaves que serão usadas pelos clientes, usando o script "build-key". Você pode gerar chaves para vários clientes em sequência, especificando nomes diferentes, como em:

# ./build-key cliente1
# ./build-key cliente2

Cada vez que o comando é executado, o script mostra a saída do comando do openssl usado para gerar a chave e confirma os parâmetros do certificado, como ao rodar o "build-key-server":

Generating a 1024 bit RSA private key
.++++++
.......................++++++
writing new private key to 'cliente1.key'

Se ele simplesmente for executado instantaneamente, sem exibir o indicador ou qualquer mensagem de erro, é sinal de que alguma coisa está errada, provavelmente com a atribuição das variáveis usada pelo script. Nesse caso, experimente rodar novamente o comando "source vars" e executar o script novamente, como em:

# source vars
# ./build-key cliente1

Não se esqueça de preencher a opção "commonName" com o nome da máquina (ou outro nome definido por você, diferente em cada chave). Deixando o campo em branco a chave não é gerada. No final não esqueça de responder as perguntas "Sign the certificate?" e "1 out of 1 certificate requests certified, commit?" com o valor "y".

Common Name (eg, your name or your server's hostname) []:cliente1
...
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y

Diferente do "build-key-server", ele não oferece a opção de proteger a chave usando uma senha. Se você quiser que os usuários precisem digitar uma senha antes de poderem efetuar a conexão usando o certificado, gere as chaves usando o script "build-key-pass" em vez do "build-key". Ele confirma todos os parâmetros (assim como o build-key-server) e oferece a opção incluir a senha:

# ./build-key-pass cliente2

Em seguida, usamos o script "build-dh" (sem parâmetros). Ele gera os parâmetros Diffie Hellman, que reforçam a segurança, permitindo que o servidor e os clientes troquem as chaves (de forma segura) no momento da conexão, confirmando suas identidades:

# ./build-dh

Generating DH parameters, 1024 bit long safe prime, generator 2
This is going to take a long time
....................................+...........+...............

O comando demora quase um minuto para gerar os parâmetros, mostrando um indicador de progresso durante o processo. Em caso de problemas, certifique-se de que está rodando os comandos a partir do diretório "/etc/openvpn/easy-rsa", rode o comando "source vars" para carregar as variáveis e tente novamente.

O processo de geração das chaves gera um conjunto de arquivos ".csr". Estes arquivos correspondem às requisições para a assinatura das chaves, que é feita durante o processo de criação. Eles podem ser removidos no final do processo:

# rm *.csr

Você ficará então com um conjunto de arquivos similar a esse dentro do diretório "/etc/openvpn/easy-rsa/keys":

ca.crt cliente1.key cliente2.key index.txt servidor.crt
ca.key cliente2.crt cliente3.crt index.txt.attr servidor.key
cliente1.crt cliente2.csr cliente3.key serial

Caso esteja curioso, estes scripts nada mais fazem do que executar os comandos correspondentes do OpenSSL, usando os parâmetros definidos no arquivo "vars". O script "build-key", por exemplo, executa os comandos:

cd $KEY_DIR && \
openssl req -days 3650 -nodes -new -keyout $1.key -out $1.csr -config $KEY_CONFIG && \
openssl ca -days 3650 -out $1.crt -in $1.csr -config $KEY_CONFIG && \
chmod 0600 $1.key

Note que é usado o parâmetro "-days 3650", que faz com que as chaves tenham validade de 10 anos. Se a sua VPN ainda estiver em uso até lá, não se esqueça de trocar as chaves antes do 3650° dia, caso contrário sua VPN parará de funcionar após completar o décimo aniversário. :)

Falta agora fazer a instalação das chaves, tanto no servidor quanto nos clientes. Para o servidor, crie o diretório "/etc/openvpn/keys" e copie para ele os arquivos "ca.crt", "servidor.crt" e "servidor.key", como em:

# cd /etc/openvpn/easy-rsa/keys
# mkdir /etc/openvpn/keys
# cp -a ca.crt servidor.crt servidor.key /etc/openvpn/keys/

Copie também o arquivo "dh1024.pem" (o número 1024 corresponde ao comprimento da chave e pode mudar de acordo com a configuração), ele contém os parâmetros Diffie Hellman, e é gerado ao rodar o script "build-dh":

# cp -a dh1024.pem /etc/openvpn/keys/

O passo final é fazer a cópia dos certificados para os clientes, usando o SFTP ou outra ferramenta de transferência de arquivos.

Todos os clientes devem possuir o arquivo "ca.crt", o arquivo "dh1024.pem" e os arquivos .crt e .key correspondentes a ele. O cliente1 receberia os arquivos "ca.crt", "dh1024.pem", "cliente1.crt" e "cliente1.key"; o cliente2 receberia os arquivos "ca.crt", "dh1024.pem", "cliente2.crt" e "cliente2.key", e assim por diante.

Nos clientes Linux, crie o diretório "/etc/openvpn/keys", e copie os três arquivos para ele. Se eles estiverem com o servidor SSH ativo (e você tiver a senha de root, pode fazer a cópia a partir do próprio servidor, usando o SFTP, como em:

# sftp root@192.168.1.21

Password:

sftp> mkdir /etc/openvpn/keys
sftp> cd /etc/openvpn/keys
sftp> put ca.crt
sftp> put dh1024.pem
sftp> put cliente1.crt
sftp> put cliente1.key

No caso dos clientes Windows, os quatro arquivos devem ser copiados para o diretório "keys", dentro do diretório de instalação do OpenVPN, como em "C:\Arquivos de programas\OpenVPN\config\keys". Assim como no caso dos clientes Linux, é necessário criar o diretório manualmente:

O uso de chaves torna necessário que os relógios das máquinas estejam sincronizados. No Linux, você pode acertar o relógio da máquina via web usando o comando:

# ntpdate -u pool.ntp.org

No Windows, marque a opção "Sincronizar automaticamente com um servidor de horário na Internet", disponível no Painel de Controle > Data e hora > Horário na Internet".

Ajustando a configuração

A parte mais complicada em usar certificados é a configuração inicial, que acabamos de fazer. Uma vez que os certificados já estão criados e instalados nos clientes, tudo fica mais simples.

Vamos começar com uma configuração básica, similar à VPN que criamos inicialmente utilizando chaves estáticas. Nesse exemplo, estou utilizando o sistema TAP (em vez do TUN, como no exemplo anterior) e estou utilizando os certificados anteriormente criados. A diferença entre o TUN e o TAP é que no TUN o tráfego da rede é roteado (o que elimina os pacotes de broadcast), enquanto no TAP tudo é transmitido, incluindo pacotes de broadcast e pacotes de outros protocolos de rede (como o IPX/SPX).

O arquivo "/etc/openvpn/server.conf" no servidor ficaria:

dev tap
ifconfig 10.0.0.1 255.255.255.0
tls-server
dh /etc/openvpn/keys/dh1024.pem
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/servidor.crt
key /etc/openvpn/keys/servidor.key

Veja que agora usamos a linha "tls-server" e especificamos a localização dos 4 arquivos com os certificados que instalamos nos passos anteriores. A linha "ifconfig" especifica o endereço IP que será usado pelo servidor, juntamente com a máscara de subrede.

A configuração no arquivo "/etc/openvpn/client.conf" nos clientes ficaria:

remote guiadohardware.no-ip.org
dev tap
tls-client
ifconfig 10.0.0.2 255.255.255.0
dh /etc/openvpn/keys/dh1024.pem
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/cliente1.crt
key /etc/openvpn/keys/cliente1.key

Criados os arquivos de configuração no servidor e no cliente, reinicie o serviço em ambas as máquinas, para que o daemon leia a nova configuração e estabeleça a conexão:

# /etc/init.d/openvpn restart

Se a VPN não funcionar, ou se você receber um "Starting virtual private network daemon: client(FAILED)" ao reiniciar o serviço, experimente ativar o OpenVPN manualmente (no cliente), usando o comando:

# openvpn --config client.conf

Isso faz com que ele exiba as mensagens geradas pelo programa durante a inicialização, o que pode ajudá-lo a identificar o problema. Pode ser que ele não esteja conseguindo contactar o servidor no endereço especificado (ou o firewall pode estar bloqueando a porta especificada na configuração), pode existir algum erro na configuração, ou pode ter havido algum problema durante a geração ou a cópia das chaves, por exemplo.

Nos clientes Windows, a configuração é quase idêntica, mudando apenas as linhas com a localização das chaves. Se você as colocou dentro da pasta "keys", no diretório de configuração, o arquivo "client.ovpn" ficaria como no screenshot abaixo:

Para permitir que vários clientes se conectem simultaneamente à VPN, é necessário fazer algumas mudanças na configuração. A principal delas é que em vez de especificar manualmente o endereço IP usado pelo servidor e pelo cliente usando o comando "ifconfig" como em "ifconfig 10.0.0.2 10.0.0.1", passamos a especificar uma faixa de endereços IP para a VPN e deixamos que o servidor atribua endereços para os clientes conforme eles se conectam.

Isso é mais simples do que parece. Na configuração do servidor utilizaremos a linha "server" (deixando de usar a linha do ifconfig), especificando a faixa de endereços e a máscara, como em:

server 10.0.0.0 255.255.255.0

É importante enfatizar que a faixa de endereços utilizada na VPN deve ser diferente da faixa de endereços utilizada na rede local à qual o servidor está ligado, que, por sua vez, também deve ser diferente da faixa de endereços de rede local utilizada pelo cliente.

Originalmente o cliente tem acesso apenas ao próprio servidor. Para permitir que ele possa acessar os demais hosts da rede local, adicionamos uma linha adicional, que faz com que o servidor inclua uma regra de roteamento na configuração do cliente, no momento da conexão. Ela especifica a faixa de endereços e a máscara usada na rede local:

push "route 192.168.1.0 255.255.255.0"

Com a regra, o cliente passará a usar o endereço IP do servidor na VPN como roteador para os pacotes destinados à faixa de endereços especificada. Essa linha substitui o comando "route add -net 192.168.1.0 netmask 255.255.255.0 gw 10.0.0.1 dev tun0" (executado no cliente) que usamos no tópico sobre VPNs com chaves estáticas.

Na configuração do cliente, adicionamos a linha "pull" (push = empurrar, pull = puxar), para que ele aceite as configurações fornecidas pelo servidor. Com isso, o cliente recebe automaticamente um endereço aleatório dentro da faixa "10.0.0.x", sem que você precise especificar a configuração de cada um manualmente:

pull

Aqui temos um exemplo de configuração completa do servidor, utilizando a interface tun, especificando uma porta UDP alternativa e utilizando as novas opções:

proto udp
port 22222
dev tun
server 10.0.0.0 255.255.255.0
push "route 192.168.1.0 255.255.255.0"
tls-server
dh /etc/openvpn/keys/dh1024.pem
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/servidor.crt
key /etc/openvpn/keys/servidor.key

A configuração correspondente para o cliente seria:

remote guiadohardware.no-ip.org
proto udp
port 22222
client
pull
dev tun
tls-client
dh /etc/openvpn/keys/dh1024.pem
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/cliente1.crt
key /etc/openvpn/keys/cliente1.key

Com essa configuração, o servidor passa a ser capaz de receber conexões a partir de vários clientes simultaneamente. O OpenVPN é capaz de gerenciar todas as conexões utilizando a mesma porta.

Para adicionar um novo cliente à VPN, você precisaria apenas gerar um novo certificado, usando o comando "./build-key" e copiar os quatro arquivos para dentro da pasta "/etc/openvpn/keys" (além de instalar o OpenVPN, naturalmente). Em resumo, os comandos para gerar um novo certificado são:

# cd /etc/openvpn/easy-rsa/
# source vars
# ./build-key novocliente

A configuração é a mesma que foi usada para o primeiro cliente, mudando apenas os arquivos dos certificados. Com isso, cada cliente recebe um endereço diferente dentro da faixa "10.0.0.x" e pode acessar o servidor através do endereço "10.0.0.1".

É necessário também ativar, no servidor, a regra de firewall que roteia os pacotes provenientes dos clientes da VPN para a interface de rede local. Como agora estamos utilizando endereços atribuídos automaticamente e não mais endereços estáticos, especificamos a faixa de endereços, em vez de especificar diretamente o endereço usado pelo cliente:

# echo 1 > /proc/sys/net/ipv4/ip_forward
# iptables -t nat -s 10.0.0.0/24 -A POSTROUTING -o eth0 -j MASQUERADE

Estes dois comandos precisam ser executados pelo servidor a cada boot. Você pode incluí-los no seu script de firewall, ou em algum dos scripts de inicialização do sistema.

Uma opção útil ao usar vários clientes é a opção "ifconfig-pool-persist". Ela faz com que o OpenVPN passe a armazenar uma lista cos os endereços IP usados por cada clientes da VPN e faça o possível para atribuir sempre os mesmos endereços em futuras conexões dos clientes. Isso não impede que os endereços mudem, mas torna as mudanças muito menos freqüentes. Esta opção é incluída apenas na configuração do servidor, especificando um arquivo de texto onde a lista será salva, como em:

ifconfig-pool-persist /etc/openvpn/ipp.txt

O arquivo é criado e atualizado automaticamente pelo OpenVPN, a única exigência é que ele deve ser criado dentro do diretório "/etc/openvpn" ou outra pasta à qual o usuário "openvpn", usado pelo daemon tenha acesso.

Uma opção que aumenta a segurança dos clientes é a "remote-cert-tls server" que faz com que os clientes verifiquem o certificado do servidor no momento da conexão. Ela é mais uma opção destinada a proteger os clientes contra ataques man-in-the-middle. Esta opção é adicionada apenas na configuração dos clientes:

remote-cert-tls server

Uma observação importante é que esta opção é suportada apenas pelo OpenVPN versão 2.1 (final) em diante. Se o cliente usar uma versão anterior (como o OpenVPN 2.1_rc4, usado no Debian Etch), a opção muda para "ns-cert-type server":

ns-cert-type server

Você pode verificar qual é a versão do OpenVPN usada e assim descobrir qual das duas opções deve ser utilizada usando o comando:

# openvpn --version

Usar a opção "remote-cert-tls server" em um cliente com uma versão antiga do OpenVPN faz com que o serviço simplesmente deixe de funcionar até que você a substitua pela "ns-cert-type server".

Outro problema comum é com relação ao uso da banda pelos usuários da VPN. Se uma única conexão web é dividida entre o uso da VPN e o acesso à web, você vai provavelmente querer restringir o uso de banda da VPN, para evitar que cópias de grandes arquivos e outras atividades que envolvam grande uso de banda saturem a conexão.

Isso é feito usando a opção "shaper", que limita o banda total de saída usada pela VPN a um determinado volume de tráfego. Se você usa um link ADSL com 512 kbits (ou seja, 64 kbytes) de upload, você poderia restringir o uso de banda pela VPN a 50 kbytes, por exemplo, de forma a deixar pelo menos uma pequena porção da banda reservada para outros usos.

A opção "shaper" pode ser incluída na configuração do servidor (para que seja aplicada ao tráfego de saída somado de todos os clientes conectados a ele), na configuração dos clientes (limitando assim o tráfego de saída permitido por cada um) ou em ambos. Basta especificar o limite desejado, em bytes, como em:

shaper 51200

Você pode também limitar o número de clientes simultâneos que será aceitos pelo servidor usando a opção "max-clients", especificando o número de clientes desejados, como em:

max-clients 10

Uma última opção, que pode ser usada para proteger sua VPN contra ataques DoS e oferecer uma camada adicional de segurança é a opção "tls-auth".

Com ela, uma chave compartilhada é usada para criar uma segunda camada de encriptação, sobre os pacotes já encriptados usando os certificados. O servidor só aceita pedidos de conexão encriptados com a chave compartilhada, o que faz com que pedidos de conexão de pessoas não autorizadas (que não terão a chave) sequer sejam processados pelo servidor.

Para utilizar a opção, é necessário criar uma chave estática, usando o comando "openvpn --genkey --secret", o mesmo que utilizamos no inicio para gerar a chave estática usada na nossa VPN inicial. Este arquivo pode ser armazenado no diretório "/etc/openvpn/keys", junto com os arquivos dos certificados:

# cd /etc/openvpn/keys
# openvpn --genkey --secret chave.key

O arquivo gerado deve ser então copiado para todos os clientes. O próximo passo é adicionar a opção, tanto na configuração do servidor quanto na dos clientes, especificando a localização do arquivo, como em:

tls-auth /etc/openvpn/keys/chave.key

Note que, nesse caso, a chave não permite acessar a VPN. Ela é apenas um pré-requisito para poder enviar requisições de conexão para o servidor. Além dela, é necessário ter os 4 arquivos com o certificado e as chaves, como nos exemplos anteriores.

Aqui temos um exemplo final de configuração para o servidor, utilizando todas as opções que vimos até aqui:

# /etc/openvpn/server.conf
proto udp
port 22222
dev tun
server 10.0.0.0 255.255.255.0
push "route 192.168.1.0 255.255.255.0"
comp-lzo
keepalive 10 120
persistkey
persisttun
float
ifconfig-pool-persist /etc/openvpn/ipp.txt
max-clients 10
shaper 51200
tls-server
dh /etc/openvpn/keys/dh1024.pem
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/servidor.crt
key /etc/openvpn/keys/servidor.key
tls-auth /etc/openvpn/static.key

Aqui vai o arquivo de configuração correspondente para os clientes:

# /etc/openvpn/client.conf
remote guiadohardware.no-ip.org
proto udp
port 22222
client
pull
dev tun
comp-lzo
keepalive 10 120
persistkey
persisttun
float
tls-client
dh /etc/openvpn/keys/dh1024.pem
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/cliente1.crt
key /etc/openvpn/keys/cliente1.key
tls-auth /etc/openvpn/static.key

Se você já está com o servidor OpenVPN ativo, precisa apenas reiniciar o serviço para que a nova configuração entre em vigor, como em:

# /etc/init.d/openvpn restart

ou:

# service openvpn restart

Se você receber um "Starting virtual private network daemon: server(FAILED).", verifique todas as opções e cheque se os arquivos dos certificados foram gerados e copiados corretamente.

Como comentei anteriormente, o conteúdo do arquivo de configuração nos clientes Windows é exatamente o mesmo, mudando apenas as linhas com as localizações dos arquivos com os certificados.

No Windows são usadas barras invertidas ao indicar a localização de arquivos e isso se aplica também à configuração do OpenVPN, entretanto as barras invertidas são também usadas como caracteres de escape no shell, por isso, ao indicas localizações de arquivos na configuração do OpenVPN no Windows, você deve duplicar todas as barras invertidas e colocar a localização entre aspas, como em:

static "C:\\Arquivos de programas\\OpenVPN\\keys\\static.key"

Um último truque é que, em um servidor com várias conexões, ou no caso de uma rede com vários servidores de VPN (onde os clientes podem se conectar a qualquer um dos servidores para obter acesso à rede), você pode criar um sistema simples de redundância e de balanceamento de carga especificando os endereços de todos os servidores na configuração dos clientes (criando várias linhas "remote") e adicionando a opção "remote-random", como em:

remote guiadohardware.no-ip.org
remote gdhn.com.br
remote gdhpress.com.br
remote-random

Isso faz com que o cliente escolha aleatoriamente entre os três endereços especificados a cada conexão, tentando os outros dois caso o primeiro esteja inacessível. Como cada cliente escolherá um servidor diferente a cada conexão, a carga acabará sendo dividida igualmente entre os servidores.

Revogando Certificados

ma parte importante do gerenciamento dos certificados no OpenVPN é a revogação dos certificados que não devem mais ser utilizados. Imagine o caso de um notebook que foi roubado, ou de um funcionário que foi demitido, por exemplo. Se os certificados não forem revogados, qualquer um em posse deles poderá (a menos que você inclua uma senha ao gerar os certificados) se conectar à VPN e assim ter acesso à rede interna da empresa.

O processo de revogação dos certificados consiste em criar um arquivo contendo a lista dos certificados revogados e configurar o servidor para utilizá-lo. A partir daí, não importa mais se os arquivos do certificado revogados sejam distribuídos, já que eles não terão mais serventia alguma.

Para criar a lista, acesse o diretório "/etc/openvpn/easy-rsa" no servidor (ou na máquina que estiver usando para gerar os certificados) e carregue as variáveis do arquivo "vars":

# cd /etc/openvpn/easy-rsa
# source vars

Execute o comando "revoke-full", especificando o certificado que será revogado, como em:

# ./revoke-full cliente1

Using configuration from /etc/openvpn/easy-rsa/openssl.cnf
Revoking Certificate 08.
Data Base Updated
Using configuration from /etc/openvpn/easy-rsa/openssl.cnf
cliente1.crt: /C=BR/ST=SP/O=GDH/CN=cliente1/emailAddress=foo@bar.com
error 23 at 0 depth lookup:certificate revoked

A mensagem "error 23" indica que o certificado foi revogado com sucesso, ou seja, ela não é exatamente uma mensagem de erro e sim uma confirmação.

O comando gera o arquivo "crl.pem", dentro do diretório "/etc/openvpn/easy-rsa/keys". O próximo passo é copiar o arquivo para o diretório "/etc/openvpn/keys" do servidor. Para que ele passe a ser utilizado pelo OpenVPN, adicione o parâmetro "" na configuração do servidor, especificando a localização do arquivo, como em:

crl-verify /etc/openvpn/keys/crl.pem

Para que a alteração entre em vigor, reinicie o OpenVPN:

# /etc/init.d/openvpn restart

Com isso, o cliente perde imediatamente o acesso à VPN e passa a receber um erro "TLS Error: TLS handshake failed" ao tentar se conectar novamente.

Para revogar mais chaves, repita o processo, não se esquecendo de copiar o arquivo atualizado para a pasta "/etc/openvpn/keys" do servidor a cada alteração. Se você está gerando as chaves usando o próprio servidor, pode também especificar diretamente o arquivo na pasta "/etc/openvpn/easy-rsa/keys" na opção; assim você elimina a necessidade de copiar manualmente o arquivo a cada alterãção:

crl-verify /etc/openvpn/easy-rsa/keys/crl.pem

Para que o OpenVPN leia o arquivo atualizado, use o parâmetro "reload" do serviço. Isso atualiza a configuração sem derrubar os clientes conectados:

# /etc/init.d/openvpn reload

Criando bridges

A configuração que vimos até agora faz com que o tráfego seja roteado através da VPN. Isso melhora o desempenho da VPN, pois elimina a transmissão do tráfego de broadcast e de qualquer outro protocolo de rede que não seja o TCP/IP. A desvantagem é que, sem a transmissão do tráfego de broadcast, recursos como a navegação no ambiente de redes (nos clientes Windows) ou a instalação automática de impressoras compartilhadas através do Cups (nos clientes Linux) deixem de funcionar.

Se você está disposto a sacrificar parte do link para que a VPN se comporte como uma rede local, como se todos os micros estivessem conectados ao mesmo switch, existe a opção de criar um bridge, unindo a interface virtual da VPN e a interface da rede local. Com isso, o servidor passa a usar o mesmo endereço, tanto na rede local quanto na VPN e os clientes conectados à VPN podem receber um endereço dentro da faixa usada na rede local e não apenas acessarem, mas também serem acessados pelos demais micros.

Para isso, precisaremos de um pacote adicional, o bridge-utils, que deve ser instalado no servidor. Este é um pacote padrão, que está disponível em todas as principais distribuições e pode ser instalado usando o gerenciador de pacotes, como em:

# apt-get install bridge-utils

ou:

# yum install bridge-utils

Em seguida, precisamos fazer algumas alterações na configuração do servidor. A primeira delas é a criação de dois scripts, um para ativar e o outro para desativar o bridge. Estes scripts serão executados juntamente com o OpenVPN, na ativação e desativação do serviço.

O primeiro deles é o script "/etc/openvpn/bridge-start", que contém os comandos que ativam o bridge. Veja que este script contém uma série de parâmetros (que coloquei em negrito), que precisam ser alterados de acordo com a configuração do servidor:

#!/bin/bash
# /etc/openvpn/bridge-start

br="br0"
tap="tap0"
eth="eth0"
eth_ip="192.168.1.101"
eth_gw="192.168.1.1"
eth_netmask="255.255.255.0"
eth_broadcast="192.168.1.255"

for t in $tap; do
openvpn --mktun --dev $t
done

brctl addbr $br
brctl addif $br $eth

for t in $tap; do
brctl addif $br $t
done

for t in $tap; do
ifconfig $t 0.0.0.0 promisc up
done

ifconfig $eth 0.0.0.0 promisc up
ifconfig $br $eth_ip netmask $eth_netmask broadcast $eth_broadcast
route add default gw $eth_gw dev $br

iptables -A INPUT -i tap0 -j ACCEPT
iptables -A INPUT -i br0 -j ACCEPT
iptables -A FORWARD -i br0 -j ACCEPT

A variável "eth" inclui o device da placa de rede e a "eth_ip" contém o endereço utilizado pelo servidor (nesse exemplo o servidor utiliza um endereço de rede interna, pois acessa através de uma conexão compartilhada, onde apenas a porta do OpenVPN é roteada para ele). A variável "eth_gw" inclui o gateway da rede (utilizado pelo servidor) enquanto a "eth_netmask" e "eth_broadcast" incluem a máscara e o endereço de broadcast da rede. Os três comandos finais incluem regras no firewall para permitir o tráfego nas interfaces.

Em seguida temos o script "/etc/openvpn/bridge-stop", responsável por desativar o bridge. Diferente do primeiro, os parâmetros são fixos, mudando apenas em configurações especiais:

#!/bin/bash
# /etc/openvpn/bridge-stop

br="br0"
tap="tap0"
ifconfig $br down
brctl delbr $br

for t in $tap; do
openvpn --rmtun --dev $t
done

Depois de criar os dois scripts, transforme-os em executáveis usando o comando "chmod +x", como em:

# chmod +x /etc/openvpn/bridge-start
# chmod +x /etc/openvpn/bridge-stop

Em seguida, temos as mudanças na configuração do servidor. A primeira mudança é que o bridge utiliza a interface "tap" em vez da "tun" (o tap transmite pacotes de broadcast e o tun não), por isso substituímos a linha "dev tun" por "dev tap0".

A linha "server 10.0.0.0 255.255.255.0" dos exemplos anteriores deixa de ser usada, dando lugar ao parâmetro "server-bridge", que contém um conjunto mais extenso de parâmetros:

server-bridge 192.168.1.101 255.255.255.0 192.168.1.210 192.168.1.220

O primeiro parâmetro (192.168.1.101) inclui o endereço IP do servidor, seguido pela máscara. Os dois endereços seguintes (192.168.1.210 192.168.1.220) especificam uma faixa de endereços que será fornecida aos clientes remotos. Diferente dos exemplos anteriores, usamos uma faixa de endereços dentro da faixa usada na rede local, por isso é importante que você reserve uma faixa de endereços que não seja usada por outros micros da rede e que esteja fora da faixa de endereços fornecidos pelo servidor DHCP.

A linha 'push "route 192.168.1.0 255.255.255.0"' (que define a regra de roteamento que permite aos clientes remotos acessarem a rede local) também deixa de ser usada, já que com o bridge eles passam a ter acesso direto à rede, sem necessidade deu usar roteamento.

Aqui temos um exemplo de arquivo de configuração completo para o servidor:

proto udp
port 22223
dev tap0
server-bridge 192.168.1.254 255.255.255.0 192.168.1.210 192.168.1.220
comp-lzo
keepalive 10 120
ifconfig-pool-persist /etc/openvpn/ipp.txt
tls-server
dh /etc/openvpn/keys/dh1024.pem
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/servidor.crt

Na configuração dos clientes, a única mudança é a substituição da linha "dev tun" por "dev tap" (note que, diferente do servidor, usamos "dev tap" e não "dev tap0"). Temos aqui um exemplo de configuração completo. Veja que continuamos usando a linha "pull", que faz com que o cliente obtenha a configuração de rede a partir do servidor:

remote guiadohardware.no-ip.org
proto udp
port 22223
client
pull
dev tap
comp-lzo
keepalive 10 120
tls-client
dh /etc/openvpn/keys/dh1024.pem
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/cliente2.crt
key /etc/openvpn/keys/cliente2.key
ns-cert-type server

Depois de ajustada a configuração, falta apenas ativar o bridge. Para isso, desativamos o serviço do OpenVPN, executamos o script que ativa o bridge e, por último, ativamos novamente o serviço do OpenVPN:

# /etc/init.d/openvpn stop
# chmod +x /etc/openvpn/bridge-start
# /etc/init.d/openvpn start

Se você estiver acessando o servidor remotamente, vai perceber que ele ficará alguns segundos sem responder. Isso acontece por que o sistema precisa "aprender" os endereços dos hosts ligados a cada uma das interfaces que compõe o bridge. Entretanto, se ele não voltar depois de uns 30 segundos, é provável que você deixou algum parâmetro incorreto na configuração, que acabou desconectando o servidor da rede. Nesse caso você vai precisar reiniciar o servidor, ou se logar localmente nele para ver o que deu errado.

Depois de ativado o bridge, o servidor ficará com três interfaces de rede. A interface "eth0" ficará sem endereço definido, assim como a interface "tap0", usada pela VPN. Uma terceira interface, a "br0" ficará com a configuração da rede, substituindo ambas. Isso acontece por que a "br0" é justamente a interface virtual do bridge, que combina o tráfego da rede local e da VPN, fazendo com que todos os dados que chegam em uma, sejam retransmitidos na outra.

Ao usar o bridge, não é usado o roteamento de pacotes, por isso não é necessário rodar o comando "echo 1 > /proc/sys/net/ipv4/ip_forward" no servidor, nem nenhum comando adicional no cliente. O sistema simplesmente passa a escutar as duas interfaces e encaminhar todo o tráfego de uma interface para a outra, tratando as duas interfaces como se fossem uma só.

No cliente a configuração é mais simples, você precisa apenas reiniciar o serviço do OpenVPN para que a alteração na configuração entre em vigor e a VPN seja restabelecida:

# /etc/init.d/openvpn restart

Uma vez que o cliente remoto se conecta à bridge, será criada a interface "tap0", utilizando um dos endereços da faixa definida na configuração do servidor, como em "192.168.1.220". Rodando o comando "route" (no cliente), você verá que o sistema automaticamente incluiu uma rota, associando a interface tap à rede "192.168.1.0".

A partir daí, o cliente pode acessar normalmente todos os demais micros da rede local, incluindo outros clientes remotos, e também ser acessado por eles. A única grande limitação é a velocidade do link. Você perceberá que ao utilizar a VPN através de uma conexão discada ou outro link lento, o acesso a compartilhamentos de arquivos e outros recursos ficará realmente muito lento.

Outra dica é que pode demorar alguns minutos até que outros micros da rede tenham acesso ao cliente, pois o sistema precisa receber conexões dos endereços antes de colocá-los na tabela. É normal que você não consiga acessar um cliente que acabou de se conectar à rede (o bridge ainda não aprendeu sobre ele) e consiga se conectar normalmente alguns minutos depois. Veja só:

$ ssh 192.168.1.210

ssh: connect to host 192.168.1.210 port 22: No route to host

$ ssh root@192.168.1.210 # (dois minutos depois)

The authenticity of host '192.168.1.210 (192.168.1.210)' can't be established.
RSA key fingerprint is ba:73:11:cd:e5:c5:c2:08:46:6e:d8:c4:02:f8:62:90.
Are you sure you want to continue connecting (yes/no)?

Se você tiver muitos micros com o Windows 95/98/ME na rede, o desempenho da VPN também será bastante penalizado pelo tráfego do protocolo NetBIOS (o compartilhamento de arquivos e impressoras). A melhor solução para minimizar o problema é configurar o servidor de arquivos da rede como servidor WINS e configurar todos os clientes para utilizá-lo.

O uso do servidor WINS é também a solução se você quiser que os clientes remotos tenham acesso aos compartilhamentos com a VPN utilizando interfaces tun, onde o tráfego é roteado.

Depois de testar a conexão, você pode automatizar a execução dos scripts para ativar e desativar o bridge adicionando as duas linhas abaixo ao arquivo de configuração do servidor:

up /etc/openvpn/bridge-start
down /etc/openvpn/bridge-stop

Com isso, o bridge passa a ser ativado automaticamente durante o carregamento do OpenVPN, sem que você precise executar comandos adicionais.

Usando esta configuração, o bridge deve ser ativado automaticamente durante a inicialização do servidor e (se você está mantendo o serviço do OpenVPN ativo nos clientes, em vez de conectar manualmente) eles devem se conectar à VPN automaticamente assim que alguma conexão estiver disponível.

Como todo o tráfego da VPN é encriptado e os certificados privados não são transmitidos durante o estabelecimento da conexão, você pode usar a VPN sem medo, mesmo ao acessar através de redes inseguras, como redes wireless públicas ou redes de terceiros.

CRÉDITOS/AUTORIA: Carlos E. Morimoto EM 04/04/2008