Introdução

Uma VPN (Virtual Private Network, ou rede virtual privada) é, como o nome sugere,
uma redevirtual, criada para interligar duas redes distantes, através da Internet. Usar uma VPN
permite que você compartilhe arquivos e use aplicativos de produtividade e de gerenciamento,
como se todos os micros estivessem conectados à mesma rede local. Você pode até mesmo imprimir
em impressoras da rede remota, da mesma forma que faria com uma impressora local.
Antigamente, a única forma de interligar redes em dois locais diferentes era usar linhas de frame-
relay. Para quem não é dessa época, uma linha de frame-relay oferece um link dedicado de 64 kbits
entre dois pontos (a matriz e a filial de uma empresa, por exemplo), com um custo mensal fixo.
Você pode combinar várias linhas frame-relay em uma única conexão, de acordo com a
necessidade, o problema nesse caso é o preço. Atualmente, existem outras opções de conexões
dedicadas e de conexões de alta disponibilidade, oferecidas pelas operadoras, mas elas ficam fora
do orçamento da maioria das pequenas e médias empresas.

Usando uma VPN, você pode obter todos os benefícios de ter uma conexão dedicada entre dois
pontos usando conexões via ADSL ou cabo, que são muito mais baratas. Dependendo do volume de
uso da rede, você pode tanto utilizar a conexão que já tem quanto utilizar uma segunda conexão
apenas para a VPN, evitando assim que o tráfego prejudique a navegação dos usuários. Além de
interligar duas ou mais redes, a VPN pode (dependendo da configuração) ser acessada também por
funcionários trabalhando remotamente.

Todos dados que trafegam através da VPN são encriptados, o que elimina o risco inerente à
transmissão via Internet. Naturalmente, nenhuma VPN pode ser considerada "100% segura", já que
sempre existe um pequeno risco de alguém conseguir obter acesso aos servidores, de forma a roubar
as chaves de encriptação (por exemplo), mas, em uma VPN bem configurada, o risco é realmente
muito pequeno. É muito mais provável que um funcionário descontente sabote a rede interna, ou
envie informações sigilosas para fora, do que algum invasor consiga efetivamente obter acesso à
rede via Internet.

Nesse tópico, estudaremos como criar VPNs usando o OpenVPN. Além de ser mais simples de
configurar que a maioria das outras soluções de VPN e ser bastante seguro e flexível, ele possui
versões Linux e Windows, o que permite criar túneis interligando máquinas rodando os dois
sistemas sem grandes dificuldades.

Outras vantagens são que ele pode ser usado por clientes conectando através de uma conexão
compartilhada via NAT (apenas o servidor precisa de portas abertas) e a boa tolerância contra
conexões ruins, ou ao uso de conexões com IP dinâmico. A VPN pode ser configurada para ser
restabelecida de forma automática em caso de interrupção na conexão, o que torna o link bastante
confiável.
Com relação à segurança, o OpenVPN pode ser configurado para utilizar chaves estáticas, que
oferecem um nível mediano de segurança, em troca de uma configuração mais simples, ou para
utilizar certificados X509, onde a configuração é um pouco mais complexa, mas, em compensação,
a segurança é muito maior (bem superior à da maioria das soluções comerciais). Isso permite que
você escolha a melhor relação entre praticidade e segurança de acordo com a situação.

Instalando o OpenVPN e criando uma VPN básica

O primeiro passo é instalar o OpenVPN, tanto no cliente quanto no servidor. Nas distribuições
derivadas do Debian você pode instalá-lo rapidamente via apt-get:
# apt-get install openvpn
No final da instalação, ele exibirá uma mensagem, perguntando se o OpenVPN deve ser desativado
antes de ser atualizado ("Would you like to stop openvpn before it gets upgraded?"). Responda que
sim.

No OpenSuSE, abra o Yast e, dentro da seção de gerenciamento de pacotes, faça uma busca pelo
pacote "openvpn". A busca resulta em dois resultados: "openvpn", que é o pacote em que estamos
interessados e "openvpn-devel", que contém o código fonte. Basta selecionar o pacote e concluir a
instalação.
No Fedora, a instalação pode ser feita usando o yum. Ele se encarregará de instalar também os
pacotes "openssl" e "lzo", que contém as bibliotecas usadas pelo OpenVPN para encriptar e
compactar o tráfego da rede:

# yum install openvpn

No CentOS, é necessário adicionar o repositório do RPMForge já que (até o CentOS 5.1), o pacote
OpenVPN não faz parte dos repositórios oficiais. Você pode adicionar o repositório seguindo as
instruções disponíveis aqui: http://wiki.centos.org/Repositories/RPMForge.
O primeiro passo é instalar a chave GPG do repositório:

# rpm --import http://dag.wieers.com/rpm/packages/RPM-GPG-KEY.dag.txt

Com a chave instalada, baixe o pacote RPM do repositório. Este pacote instala o arquivo com a
configuração do repositório dentro da pasta "/etc/yum/repos.d". Verifique o link do pacote para a
versão do CentOS que está utilizando na página com as instruções. No caso do CentOS 5.1, versão
32 bits, por exemplo, o pacote é o "rpmforge-release-0.3.6-1.el5.rf.i386.rpm". Se você está fazendo
a configuração via linha de comando, pode baixar o pacote usando o wget, como em:
# wget -c
http://apt.sw.be/redhat/el5/en/i386/RPMS.dag/rpmforge-release-0.3.6-1.el5.rf.i386.rpm

Em seguida, instale o pacote usando o comando "yum localinstall", como em:

# yum localinstall rpmforge-release-0.3.6-1.el5.rf.i386.rpm

A partir daí, você pode instalar o pacote do OpenVPN usando o yum, assim como no Fedora:

# yum install openvpn

No Mandriva, basta instalar o pacote "openvpn" usando urpmi. Assim como no Fedora, ele também
se encarrega de instalar as dependências:

# urpmi openvpn

Se você estiver utilizando uma distribuição que não inclua o pacote nos repositórios, ou se a versão
disponível for muito antiga, você pode também instalar a partir do pacote com o código fonte,
disponível no: http://openvpn.net/index.php/downloads.html
Depois de instalar o pacote, o próximo passo é carregar o módulo "tun" do Kernel, que é utilizado
pelo OpenVPN para criar interfaces virtuais. Cada VPN criada se comporta como se fosse uma
nova interface de rede, conectada à rede de destino. Imagine que a VPN se comporta como se
existisse um cabo de rede gigante ligando esta interface virtual à rede do outro lado do túnel.

# modprobe tun

Adicione a linha "tun" no final do arquivo "/etc/modules" para que o módulo passe a ser carregado
automaticamente durante o boot:

# echo tun >> /etc/modules

Estes três passos, ou seja, a instalação do OpenVPN, o carregamento do módulo e a adição da linha
no final do arquivo devem ser executados tanto no servidor quanto nos clientes.

Depois de concluída a instalação, você pode criar um túnel simples, não encriptado, usando os
comandos abaixo. Este túnel não pode ser considerado uma "VPN" já que não é seguro, mas serve
como um "hello word" dentro da configuração do OpenVPN.

Presumindo que as duas máquinas estejam ligadas em rede e que não exista nenhum firewall no
caminho, use o comando abaixo no cliente, especificando o endereço do servidor:

# openvpn --remote 192.168.1.1 --dev tun0 --ifconfig 10.0.0.1 10.0.0.2

Faça o mesmo no servidor, especificando agora o endereço do cliente:

# openvpn --remote 192.168.1.202 --dev tun0 --ifconfig 10.0.0.2 10.0.0.1

Rode o comando "ifconfig" no cliente e você verá que foi criada uma interface de rede virtual, a
"tun0", com o endereço "10.0.0.1":

No exemplo, o servidor recebe o endereço "10.0.0.2". Você pode testar a conectividade usando o
ping ou qualquer outra ferramenta:
Como comentei, o OpenVPN possui também uma versão Windows, que está disponível
no http://openvpn.se.
Esta versão inclui um instalador gráfico e funciona em todas as versões do Windows a partir do
Windows 2000. Ela inclui também o driver tun/tap, que é instalado automaticamente, você precisa
apenas prestar atenção nas mensagens de instalação. Em um certo ponto, será exibida uma
mensagem avisando que o driver TAP/Win32 não passou pelo processo de certificação de
compatibilidade com o Windows. Responda "Continuar assim mesmo" para efetuar a instalação, do
contrário o OpenVPN não funcionará.

O processo de certificação dos drivers para o Windows é um processo caro e demorado, onde os
fabricantes de componentes submetem os drivers de dispositivo à Microsoft para que eles sejam
certificados. Este é um processo que não está ao alcance de projetos independentes, como o
OpenVPN, daí a exibição da mensagem. De qualquer forma, isso não significa que o software seja
instável ou inseguro, muito pelo contrário. Se a certificação da Microsoft fosse um indicador de
qualidade, softwares como o IIS e o IE não teriam tantas falhas e brechas de segurança.

Criando VPNs usando chaves estáticas

A forma mais simples de configurar o OpenVPN é utilizar chaves estáticas, onde um arquivo
contendo um algoritmo de encriptação é usado pelas duas partes para encriptar os dados
transmitidos através da VPN.

Nesse modo, você gera uma arquivo de texto no servidor, contendo a chave de encriptação e precisa
apenas copiá-la para o cliente e fazer uma configuração rápida para criar a VPN. Se você quer
apenas criar uma VPN doméstica, ou criar uma VPN temporária entre duas redes, esta é a
configuração recomendada.

O grande problema em utilizar uma chave estática é que, como o nome sugere, a mesma chave é
utilizada sessão após sessão, sem nunca mudar. Com isso, existe uma pequena possibilidade de um
atacante obstinado conseguir quebrar a VPN usando um ataque de força bruta. Como a chave é um
arquivo de texto, que é armazenado tanto no cliente quanto no servidor, existe também a
possibilidade de alguém conseguir copiá-lo, caso tenha acesso físico a uma das máquinas. Outra
limitação é que usando uma chave estática o servidor suportará a conexão de um único cliente por
VPN.

Para VPNs com vários clientes, ou em redes empresariais, onde a segurança é prioridade, é
recomendável utilizar uma estrutura baseada em certificados X509, como veremos no tópico
seguinte.

Vamos então à configuração de nossa primeira VPN. Para este exercício inicial, recomendo que
utilize duas máquinas da rede local, que não tenham firewall ativo. Depois de entender melhor
como o sistema funciona, passaremos para uma configuração mais elaborada.

O primeiro passo é gerar o arquivo com a chave, no servidor. O arquivo deve ser gerado dentro do
diretório "/etc/openvpn" (o diretório padrão de configuração), de forma que acessamos o diretório
antes de executar o comando que gera a chave:
# cd /etc/openvpn
# openvpn --genkey --secret static.key

Isso gerará o arquivo "static.key", que contém a chave de encriptação que será usada para criar a
conexão. Ele é um arquivo de texto simples, que contém uma chave de 2048 bits, como em:

#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
0600d007988a59c6f7895884d336d445
2679fd3d2c0b9e0b777b4da92ab97043
... (mais 13 linhas)
e871ed9077185a2a6904e67cd0869e15
-----END OpenVPN Static key V1-----

Este arquivo deve ser copiado para a pasta "/etc/openvpn" do cliente, usando (por exemplo) o SFTP.
Você pode usar também um pendrive, ou outra mídia de uso local, mas não é recomendável enviá-lo
por meios não seguros (e-mail por exemplo), já que qualquer um que tenha acesso ao arquivo
poderá se conectar à sua VPN ou desencriptar todo o tráfego transmitido através dela.

Para acessar o servidor (a partir do cliente) via SFTP, use o comando "sftp ip" para se conectar e,
em seguida, use os comandos "cd /etc/openvpn" e "get static.key" para fazer a cópia, como em:

# cd /etc/openvpn
# sftp root@192.168.1.101

Password:
sftp> cd /etc/openvpn
sftp> get static.key
Fetching /etc/openvpn/static.key to static.key
sftp> quit

Com o arquivo contendo a chave presente nas duas máquinas, falta criar os arquivos de
configuração que serão usados pelo OpenVPN. Neste exemplo, criarei o arquivo
"/etc/openvpn/server.conf" no servidor e o arquivo "/etc/openvpn/client.conf" no cliente. Os nomes
podem ser diferentes, mas os arquivos devem ser criados dentro da pasta "/etc/openvpn" e devem
terminar com a extensão ".conf"

O arquivo "/etc/openvpn/server.conf", no servidor, fica com o seguinte conteúdo:

dev tun
ifconfig 10.0.0.1 10.0.0.2
secret static.key

A linha "ifconfig 10.0.0.1 10.0.0.2" inclui os endereços que serão usados pelas interfaces virtuais da
VPN, no servidor e no cliente. No exemplo, o servidor utilizará o endereço "10.0.0.1" e o cliente o
endereço "10.0.0.2". Você pode utilizar outros endereços se preferir. O importante é que os
endereços utilizados na VPN devem ser sempre diferentes dos endereços usados na rede local.

A linha "secret static.key" especifica o arquivo com a chave de encriptação, que criamos no passo
anterior. Não esqueça de alterar a linha caso o nome do arquivo seja diferente.

Em seguida, vem o arquivo "/etc/openvpn/client.conf", que deve ser criado no cliente:

remote 192.168.1.101
dev tun
ifconfig 10.0.0.2 10.0.0.1
secret static.key

A primeira linha especifica o endereço IP do servidor. No exemplo, estou utilizando um endereço de

rede local, já que estamos apenas testando a VPN, mas, em um exemplo real de uso, você utilizaria
o endereço IP de Internet do servidor ou (ao utilizar uma conexão com IP dinâmico) um domínio
virtual utilizado por ele. Se você ainda não tem um, acesse o no-ip.com ou o dyndns.org e faça o
registro.

Com os arquivos de configuração criados, inicializar a VPN é incrivelmente simples. Você precisa
apenas reiniciar o serviço "openvpn" tanto no cliente quanto no servidor, usando o comando:

# /etc/init.d/openvpn restart

Ao ser iniciado, o serviço procura por arquivos ".conf" dentro do diretório "/etc/openvpn" e inicia as
VPNs configuradas automaticamente (desde que o serviço esteja configurado para subir durante o
boot, o que é feito por padrão na maioria das distribuições). Isso não apenas simplifica a
configuração, mas faz com que a VPN passe a ser automaticamente restabelecida a cada boot. Para
desativá-la, basta parar o serviço:

# /etc/init.d/openvpn stop

Você pode, também, ativar o OpenVPN manualmente, usando (como root) o comando:

# openvpn --config /etc/openvpn/client.conf

(onde o "client.conf" é o arquivo de configuração que será usado)

Este comando manual permite acompanhar as mensagens de inicialização e de conexão, o que ajuda
a descobrir o que está errado em casos em que a VPN não funciona, embora a configuração pareça
estar correta.

Se a VPN é usada pelos clientes apenas esporadicamente, você pode criar um ícone no desktop, ou
um pequeno script contendo o comando, para que o usuário possa se conectar à VPN apenas quando
precisar. Outra opção é instalar o kvpnc (http://home.gna.org/kvpnc/), um cliente gráfico que pode
ser usado para se conectar a VPNs baseadas em diversos protocolos, incluindo o OpenVPN:

Depois de estabelecida a VPN, o cliente passará a ter uma nova interface de rede, a "tun0", com o
endereço IP "10.0.0.2", que funciona como um link ponto-a-ponto com a interface "tun0" do
servidor, que recebe o endereço "10.0.0.1":

Teste a conexão usando o ping, ou acessando algum serviço disponível no servidor, como em:

# ssh 10.0.0.1

Depois do teste inicial, você pode fazer um teste realizando a conexão via Internet (você pode usar
uma conexão discada ou outra conexão temporária no cliente para fazer o teste). Para isso, você vai
precisar apenas alterar a configuração no cliente, adicionando o endereço de internet do servidor,
como em:

remote guiadohardware.no-ip.org
dev tun
ifconfig 10.0.0.2 10.0.0.1
secret static.key

Não se esqueça de reiniciar o OpenVPN para que a alteração entre em vigor:

# /etc/init.d/openvpn restart
Configuração das portas no OpenVPN
Diferente de outras soluções de VPN, o OpenVPN utiliza uma única porta de entrada, mesmo que
sejam utilizadas várias VPNs simultaneamente. Isso facilita bastante a configuração do firewall ou
do roteamento de portas no servidor.

No OpenVPN 2.x é utilizada por padrão a porta 1194 UDP, que deve estar aberta no firewall do
servidor (versões antigas, anteriores à 2.0-beta16 utilizavam a porta 5000 UDP). Se o servidor
acessa através de uma conexão compartilhada, é necessário configurar o gateway da rede (ou o
modem ADSL) para encaminhar a porta para ele.
Como de praxe, é possível alterar a porta padrão usada pelo OpenVPN, desde que você especifique
a nova porta tanto na configuração do servidor quanto do cliente. Para isso, usamos a opção "proto
udp", seguida pela porta desejada, que deve ser incluída tanto na configuração do servidor quanto
na do cliente, como em:

proto udp
port 22222

É possível, também, usar uma porta TCP. Nesse caso, usamos a opção "proto tcp-server" na
configuração do servidor (/etc/openvpn/server.conf) e a opção "proto tcp-client" na configuração do
cliente (/etc/openvpn/client.conf), como em:
proto tcp-server
port 22222

e:

proto tcp-client
port 22222

O grande problema em utilizar o TCP no OpenVPN é que o desempenho da VPN será

perceptivelmente pior do que se utilizada uma porta UDP.

Isso ocorre porque no UDP os pacotes são transmitidos diretamente, sem nenhum overhead, o que
garante o melhor desempenho. No UDP não existe correção de erros nem retransmissão de pacotes
perdidos, mas isso não é um problema no caso do OpenVPN, pois ele é o responsável apenas pela
criação do link de dados. Sobre ele, temos o protocolo TCP/IP e as diferentes camadas do sistema
operacional, que se encarregam dessa tarefa.

Ao utilizar uma porta TCP, o próprio OpenVPN é obrigado a fazer a checagem e a retransmissão de
pacotes, respeitando o modo de funcionamento do protocolo. Isso aumenta bastante a latência da
conexão e faz com que cada vez que um pacote é perdido, o OpenVPN precise parar a transmissão
de todos os pacotes subsequentes até que a retransmissão seja feita. Quanto maior for o volume de
dados que trafegam pela VPN, mais desvantajoso é o uso do TCP no caso do OpenVPN, de forma
que é mais recomendável utilizar uma porta UDP sempre que possível.

Estabilizando e otimizando a conexão

Usando a configuração simplificada do exemplo anterior, você notará que a VPN não será muito
estável, pois qualquer interrupção na comunicação entre as duas máquinas derrubará o link, até que
você reinicie o serviço do OpenVPN (no cliente), forçando a reconexão, como em:
 # /etc/init.d/openvpn restart

Vamos então a um conjunto de parâmetros de configuração que permitem estabilizar a VPN,

fazendo com que o OpenVPN passe a monitorar a conexão e restabelecê-la automaticamente
sempre que necessário.

O primeiro, e mais importante, é o parâmetro "keepalive", que faz com que o servidor e o cliente
monitorem a conexão, enviando pings periódicos um para o outro, e reiniciem a VPN
automaticamente caso não recebam resposta dentro de um período determinado. Esta opção é
especialmente importante em VPNs usadas através de links ADSL ou qualquer outro tipo de
conexão que não seja completamente estável. Um exemplo de uso seria:
keepalive 10 120

O primeiro número especifica o intervalo dos pings e o segundo o timeout, depois do qual a VPN é
reiniciada. Nesse caso, o ping é enviado a cada 10 segundos sem atividade e a VPN é reiniciada
depois de 120 segundos sem respostas. Caso o link seja interrompido, o cliente tenta restabelecer a
VPN periodicamente, até que tenha sucesso. Esta linha deve ser incluída tanto na configuração do
servidor quanto na do cliente.

Opcionalmente, você pode incluir a linha "inactive", para especificar um tempo máximo para as
tentativas de reconexão. Se quiser que o cliente desista depois de uma hora, por exemplo, inclua a
linha:
inactive 3600

O parâmetro "comp-lzo" faz com que o OpenVPN passe a compactar os dados transmitidos através
do túnel (é necessário que o pacote "lzo" esteja instalado). O algoritmo usado pelo OpenVPN é
bastante leve, por isso o uso adicional de processamento, tanto no servidor quando nos clientes é
pequeno. A compressão dos dados não faz milagres, mas é uma boa forma de melhorar o
desempenho da VPN ao utilizar links lentos ou congestionados. Esta é outra opção que deve ser
incluída tanto no servidor quanto nos clientes para que seja usada:
comp-lzo

Outras duas opções, úteis para tornar a VPN mais confiável e mais resistente a problemas de
conectividade, são a "persistkey" e a "persisttun". Elas fazem com que o daemon mantenha a
interface tun aberta e as chaves carregadas quando é reiniciado (quando a VPN é restabelecida
depois de uma queda de conexão, por exemplo), o que torna mais rápida a restauração do link e
evita problemas diversos:
persistkey
persisttun

Outra opção útil ao utilizar conexões com IP dinâmico é a opção "float", que permite que o túnel
continue aberto mesmo que o endereço IP da outra máquina mude. Em situações normais, a
mudança de IP faria com que a conexão fosse encerrada e o túnel fosse interrompido até que fosse
reiniciado (seja manualmente ou seja pelo uso da opção keepalive). A opção "float" torna o processo
mais transparente, já que o OpenVPN passa a monitorar as mudança de endereços, mantendo o
túnel aberto enquanto houver conexão entre as duas partes. Essa opção também deve ser incluída
tanto na configuração do servidor quanto na do cliente:
float
Temos aqui um exemplo mais incrementado de configuração do servidor, onde a porta é
especificada manualmente e são usados os parâmetros que acabamos de ver:
dev tun
proto udp
port 22222
keepalive 10 120
comp-lzo
persistkey
persisttun
float
ifconfig 10.0.0.1 10.0.0.2
secret static.key

A configuração no cliente é praticamente a mesma, com a adição da linha "remote", que especifica
o endereço do servidor e a mudança na linha "ifconfig", onde a ordem dos endereços são trocados:
remote guiadohardware.no-ip.org
dev tun
proto udp
port 22222
keepalive 10 120
comp-lzo
persistkey
persisttun
float
ifconfig 10.0.0.2 10.0.0.1
secret static.key

Roteando pacotes através da VPN

Originalmente, o cliente terá acesso apenas ao próprio servidor. Para que ele tenha acesso aos
demais hosts da rede, é necessário realizar alguns passos adicionais.

O primeiro é ativar o roteamento de pacotes no servidor, de forma que ele passe a encaminhar os
pacotes recebidos do cliente para a interface de rede local. Mesmo que o servidor possua uma única
placa de rede, a VPN é vista pelo sistema como uma interface separada, de forma que, do ponto de
vista do sistema operacional, a VPN e a rede local são duas placas de rede separadas.

O roteamento é feito usando dois comandos (executados no servidor):

# echo 1 > /proc/sys/net/ipv4/ip_forward

# iptables -t nat -s 10.0.0.2 -A POSTROUTING -o eth0 -j MASQUERADE

O primeiro ativa o roteamento de pacotes no Kernel e o segundo orienta o sistema a encaminhar os

pacotes recebidos a partir do endereço IP do cliente (10.0.0.2, no exemplo) para a interface de rede
local (eth0, no exemplo). Estes dois comandos precisam ser adicionados em algum dos scripts de
inicialização do sistema (como o "/etc/rc.local) para que sejam executados a cada boot.

O próximo passo é executar o comando abaixo no cliente, de forma que ele passe a consultar o
servidor ao tentar acessar endereços dentro da faixa usada pela rede local:

# route add -net 192.168.1.0 netmask 255.255.255.0 gw 10.0.0.1 dev tun0

Note que o comando especifica a faixa de endereços usada na rede local (192.168.1.0, no exemplo),
a máscara, o endereço IP do servidor do outro lado da VPN e a interface virtual usada pela VPN
(tun0).

A partir daí, o cliente conseguirá acessar outros micros da rede, montar compartilhamentos ou até
mesmo imprimir em impressoras compartilhadas. É importante notar, entretanto, que se o cliente
também estiver conectado a uma rede local (acessando através de uma conexão compartilhada, por
exemplo), ela deve utilizar uma faixa diferente de endereços.

Configuração do OpenVPN no Windows

A configuração da versão Windows do OpenVPN é bastante similar à da versão Linux, com
exceção de alguns detalhes e algumas adaptações feitas devido às diferenças entre os dois sistemas.
Depois de baixar o pacote no http://opnvpn.se e instalar o programa, acesse a opção "OpenVPN
configuration file directory", dentro da pasta "OpenVPN" que será criada no iniciar:

O atalho leva à pasta "config" dentro do diretório de instalação do programa, onde irão a chave de
encriptação e o arquivo de configuração, de forma similar à pasta "/etc/openvpn" que temos no
Linux.

Se você pretende usar a máquina Windows como servidor, pode usar a opção "Generate a static
OpenVPN key", usando o atalho dentro do menu iniciar. Isso gerará um arquivo "key.txt" dentro do
diretório de configuração, que precisa então ser copiado para o cliente.

Se, por outro lado, você quer usar a máquina Windows para se conectar a um servidor Linux,
comece copiando o arquivo "static.key" do servidor para dentro da pasta de configuração:

É necessário criar também um arquivo de configuração, com a extensão "ovpn" (usando o bloco de
notas), onde são especificadas as opções de configuração. O conteúdo do arquivo é exatamente o
mesmo que usaríamos em um cliente Linux:

Depois de copiar a chave e gerar o arquivo de configuração, clique com o botão direito sobre ele e
use a opção "Start OpenVPN on this config file" para ativar a VPN:

Isso abrirá uma janela do prompt do MS-DOS mostrando o progresso da conexão:

Assim como no Linux, a VPN aparece como uma nova interface de rede, que recebe o endereço IP
definido na configuração:
Depois de testar a conexão, é possível fazer com que ela seja inicializada automaticamente ativando
o serviço do OpenVPN, que passa então a monitorar o diretório de configuração, carregando
automaticamente os arquivos de configuração colocados dentro dele, assim como no Linux.

Para isso, acesse o "Painel de Controle > Ferramentas Administrativas > Serviços" e mude a
configuração do "OpenVPN Service" de "Manual" para "Automático":

OpenVPN avançado: Certificados e bridges

Introdução
Na Primeira parte do tutorial (http://www.guiadohardware.net/tutoriais/openvpn/) aprendemos a
criar VPNs usando chaves estáticas, assim como rotear pacotes e solucionar problemas.
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ário que se
desligou da empresa, por exemplo), basta revogar o certificado para que o servidor deixe de aceitar
a conexão.
Criando certificados X509

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 localizá-la:
# 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, que muda de acordo com a versão do CentOS usada).

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 muda para:

# 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 scripts 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 seqüê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 ao executar o comando "./build-key nome" 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 do processo, 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 são feitas 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. :)

Instalando os certificados
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 é gerado ao rodar o script "build-dh" e é
importante, pois contêm os parâmetros Diffie Hellman:

# 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. Em resumo, temos:
Arquivos na pasta "/etc/openvpn/keys" do servidor:

ca.crt, dh1024.pem, servidor.crt, servidor.key

Arquivos na pasta "/etc/openvpn/keys" do cliente:

ca.crt, dh1024.pem, cliente.crt, cliente.key

Nos clientes Linux, crie o diretório "/etc/openvpn/keys" e copie os quatro 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
programasOpenVPNconfigkeys". 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 e roteando pacotes

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

Note que o "ifconfig 10.0.0.1 255.255.255.0" na configuração do servidor e o "ifconfig 10.0.0.2

255.255.255.0" na configuração do cliente indicam os endereços que serão usados pelas interfaces
de rede virtual. Eles não tem relação nenhuma com os endereços reais das máquinas. O único local
onde o endereço "real" do servidor é especificado, é na opção "remote", incluída na configuração do
cliente.

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 a seguir:
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" (que usamos nos exemplos onde foi utilizada a interface tun) ou "ifconfig 10.0.0.1
255.255.255.0" (usado no exemplo com o tap), 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 rota padrão 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

Temos aqui 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 com os endereços IP usados por cada cliente da VPN e faça
o possível para atribuir sempre os mesmos endereços em futuras conexões. 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 a 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ão 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.

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, ou seja, apenas uma acamada adicional de proteção.
Além dela, é necessário ter os 4 arquivos com o certificado e as chaves, como nos exemplos
anteriores.

Temos aqui 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 (por estranho que possa parecer), ao indicar 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 e bloqueando clientes

Uma 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, 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, a partir daí, 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, a mesma pasta utilizada pelos arquivos com
os certificados.
Para que ele passe a ser utilizado pelo OpenVPN, adicione o parâmetro "crl-
verify" 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 alteração. Um exemplo de configuração seria:
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:

Criando bridges no OpenVPN

A configuração que vimos até agora faz com que o tráfego seja roteado através da VPN. Isso
melhora o desempenho, 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. Com isso, eles passam a não apenas
acessar, mas também a 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 responsável por
permitir o acesso à rede local por parte dos clientes remotos) também deixa de ser usada, já que
com o bridge eles passam a ter acesso direto à rede, sem necessidade de usar roteamento.

Temos aqui 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 em relação aos exemplos anteriores é 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 porque 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 porque a "br0" é
justamente a interface virtual do bridge, que combina o tráfego da rede local e da VPN, fazendo
com que todo o tráfego que chega em uma, seja retransmitido 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 é ainda 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, já que em vez de 100 megabits com latência inferior a 10 milissegundos, como em uma
conexão de rede local, você passará a ter uma linha ADSL com apenas 256 ou 512 kbits de upload e
uma latência muito mais alta. Com isso, o acesso a compartilhamentos de arquivos e outros recursos
pode ficar realmente muito lento, utilizável apenas para a transferência de pequenos arquivos.

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 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

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. Afinal, esta é justamente a grande
vantagem de utilizar uma VPN. :)