Atenção: esse artigo tem um vídeo complementar. Clique e assista!

Do que se trata o artigo:

Este artigo trata de como planejar e criar um ambiente seguro de comunicação em um canal público de dados (Internet).


Para que serve:

Serve para garantir que os dados trafegados em um canal de dados públicos possam ser protegidos de acessos indevidos.


Em que situação o tema é útil:

Em um ambiente no qual você está utilizando uma infraestrutura pública, como a Internet, e deseja prover privacidade nas informações trafegadas quando se comunica com servidores corporativos de sua empresa.

O ambiente globalizado e competitivo no qual nos inserimos faz com que o trabalho remoto, quer seja a partir de casa, do aeroporto, no hotel ou em um Cliente seja uma realidade.

Nestas condições é cada vez mais comum que tenhamos que usar um canal de comunicação externo, e normalmente público, para acessar recursos sensíveis dentro de nossas redes corporativas.

Em função desse ambiente, este artigo apresentará alguns procedimentos necessários para se planejar e implementar uma solução open-source para a comunicação segura. Iremos criar um canal criptografado para a troca de informações entre um usuário externo e uma rede interna usando a Internet.

O cenário atual e o perigo envolvido

O trabalho em rede faz parte do nosso dia-a-dia já há algum tempo e o uso de sistemas cliente-servidor já é lugar comum dentro do ambiente corporativo. Este vem se intensificando nos últimos 15 anos com o advento e popularização da Internet comercial de alta velocidade.

Se somarmos a esse fato a globalização da economia, temos um contingente nunca antes visto trabalhando fora das redes corporativas. Hoje não é raro ver consultores trabalhando dos escritórios de seus clientes, desenvolvedores trabalhando de casa e designers interagindo remotamente a partir de hotspots em praças de alimentação de shoppings.

A ligação que une todos os profissionais acima é a Internet. Um meio de comunicação conhecido pela sua falta de segurança. É, entretanto, através dele que muitos de nós nos mantemos conectados com o mundo, quer seja para diversão ou trabalho.

A presença quase que universal do acesso faz com que muitas vezes não nos perguntemos como a segurança é tratada nesse meio. E na verdade a resposta seria em muitos casos que a segurança não é sequer um ponto relevante na construção e manutenção desse acesso.

Hoje em dia nenhum exemplo ilustra mais isso do que os pontos de acesso públicos utilizados em aeroportos e shopping centers. Estes pontos normalmente não utilizam nenhuma tecnologia para criptografar os dados e permitem, por exemplo, que qualquer membro da rede possa capturar todo o tráfego que por ela passa. Nessa situação, senhas, e-mails e quaisquer informações não protegidas pelo usuário podem ser acessados sem que o remetente ou destinatário saibam.

Ao consideramos a gravidade dessa situação em nossas vidas pessoais é possível ver que o dano se estivermos trocando informações corporativas é ainda maior.

Resta então nos perguntar o que pode ser feito para se mitigar o risco envolvido nessa comunicação.

Alternativas

Segurança na comunicação de redes é um assunto complexo e multi-disciplinar. Em nosso contexto avaliaremos que alternativas existem para tratar especificamente o trabalho remoto no qual um agente externo precisa acessar recursos da rede corporativa de uma empresa de forma segura.

Este problema não é novo e na verdade existia antes mesmo do advento da Internet comercial. As opções que existiam eram:

· Conexão discada;

· Conexão dedicada ponto-a-ponto.

Na conexão discada a empresa montava (ou contratava de operadoras de telefonia) uma estrutura de modems e linhas telefônicas similar à encontrada nas BBS (Bulletin Board System). O agente externo possuía um modem e discava para o número da empresa. Ao se conectar ele tinha acesso à rede da empresa.

Essa solução tinha algumas características limitantes, dentre elas a velocidade que era baixa e muito suscetível à qualidade das linhas telefônicas. A outra limitação era o custo que se tornava alto por conta da tarifação de consumo por minuto (ou pulso) e o fato de que se o agente estivesse em outro estado, ou país, o que se fazia era uma ligação interurbana ou internacional.

Na conexão dedicada ponto-a-ponto a empresa contratava um canal dedicado ponto-a-ponto entre seu endereço e o do agente externo. Eram colocados roteadores em ambos os lados e com isso a comunicação entre os computadores das redes ligadas podiam trocar informações.

Diferentemente da conexão discada, esta solução era conhecida por ter velocidades maiores e por ser dedicada tinha um custo normalmente fixo, independente do tempo ou dados trafegados.

Infelizmente ela compartilhava com a conexão discada uma característica negativa (custo elevado) e trazia uma desvantagem só sua: falta de mobilidade. Como a conexão era dedicada, ambos os pontos tinham que ser fixos, o que era perfeitamente aceitável para uma ligação entre matriz e filial, mas não realista para a força de trabalho móvel.

A verdadeira alternativa para o nosso ambiente veio com a adoção das características positivas de ambas as soluções com um novo ingrediente à época: a Internet.

A alternativa encontrada, batizada de VPN (Virtual Private Network) ou rede privativa virtual, consiste em se criar um canal que permita que as informações saiam de um ponto remoto e cheguem na rede corporativa como se estivessem em um canal ponto-a-ponto.

Como o canal é criado sobre a Internet e não sobre uma conexão ponto-a-ponto, ele é chamado de virtual por na prática usar o canal público para estabelecer esta comunicação, como demonstrado na Figura 1.

Figura 1. Uma VPN típica.

Veremos a seguir algumas tecnologias para estabelecimento de VPN antes de iniciarmos a configuração de nosso ambiente.

Tecnologias de VPN

Ao longo dos anos várias tecnologias foram apresentadas para tratar da criação de redes privativas virtuais. Dentre as existentes, destacamos três delas:

PPTP

A primeira das tecnologias que destacamos, PPTP (Point-to-Point Tunneling Protocol), foi criada por um consórcio de várias empresas, entre elas a Microsoft, Ascend (comprada pela Lucent) e 3Com. A sua especificação foi definida na RFC 2637 de 1999, e por ter a Microsoft como um participante do consórcio que criou o protocolo, este foi suportado pelos sistemas operacionais desta, o que ajudou a popularizar o acesso à criação de VPNs.

Entretanto, as escolhas técnicas adotadas para os métodos de autenticação e criptografia usados pelo protocolo foram amplamente criticados por suas vulnerabilidades intrínsecas.

Hoje, apesar de já existir suporte a esse protocolo em outras plataformas, tais como Cisco, Linux e Mac OS, o uso do PPTP tem se reduzido e não é recomendável frente às demais opções disponíveis.

IPSEC

A segunda opção, IPSEC (IP Security), consiste – na verdade – de se trazer uma funcionalidade existente na versão 6 do IP (Internet Protocol) e aplicá-la à versão 4, que é a atualmente em uso.

O IP na versão 4 não foi criado com a preocupação de segurança. Por esta razão, nas especificações deste não vemos questões como autenticação ou privacidade dos dados sendo trocados.

Quando da criação da nova versão, verificou-se que o ambiente na qual a nova versão seria utilizada não seria possível abandonar essas premissas. Desta maneira incorporaram-se itens como criptografia diretamente no protocolo.

No entanto, com a demora na adoção do IPv6, decidiu-se que pelo menos as capacidades de segurança deste deveriam ser disponibilizadas para a versão atual, mesmo que sob a forma de uma funcionalidade opcional.

No caso do IPSEC, o processo de criação da VPN acontece na camada 2 do TCP/IP. Na Figura 2 vemos um modo de trabalho do IPSEC no qual quando há a criação do túnel, o cabeçalho do pacote a ser transmitido é alterado de forma a esconder a real origem e destino do pacote antes de ser transmitido.

Figura 2. Encapsulamento do cabeçalho e dados originais dentro do túnel.

Todo o conteúdo original (destaque em amarelo) é criptografado de maneira a proteger a integridade deste enquanto ele trafega pelo canal público.

Do ponto de vista de segurança, o IPSEC apresenta uma solução muito mais segura e flexível do que o PPTP. Entretanto, a maneira como ele funciona, alterando-se o cabeçalho do IP, apresenta problemas com firewalls e sistemas que realizam o NAT (Network Address Translation) do endereço IP.

Estes sistemas, comuns em pontos de acesso como hotéis e hotspots, acabam por dificultar o uso do IPSEC no ambiente em geral.

OpenVPN

Nossa terceira opção, OpenVPN, é uma implementação da tecnologia chamada de SSL VPN. Essa tecnologia, conhecida também como user space VPN, utiliza um protocolo que atua na camada de aplicação chamado de SSL (Secure Socket Layer) e já conhecido por ser usado para prover a criptografia para acesso a sites.

Quando você acessa um site seguro (reconhecido pelo uso de https no endereço) a informação que sai de seu computador é criptografada utilizando um par de certificados digitais e chaves de maneira a impedir que os dados transmitidos, mesmo que capturados, possam ser utilizados por outro ponto que não o destinatário.

O OpenVPN, assim como outras implementações do SSL VPN, usa a mesma tecnologia para criar um canal seguro entre o remetente e o destinatário. Por atuar na camada de aplicação, daí a denominação de user space VPN, o OpenVPN requer pouca modificação da estrutura de rede e trabalha bem com os firewalls e roteadores dos pontos de acesso existentes.

Outra característica interessante do OpenVPN é a interoperabilidade entre os sistemas operacionais. É possível ter um servidor Linux e acessá-lo a partir de uma máquina com Mac OS ou Windows sem problemas.

Cenário de uso

Neste artigo veremos dois cenários de uso para a VPN que são facilmente encontrados em nosso dia-a-dia.

Rede a rede

No cenário de rede a rede temos, como o próprio nome sugere, duas redes que serão interligadas pela VPN – conforme apresenta a Figura 3.

Figura 3. VPN rede a rede.

Nessa situação a VPN é estabelecida entre os dois servidores de ambos os lados. Os membros da rede local 1 desconhecem que exista a VPN e, sem alteração nenhuma em suas configurações, podem acessar as máquinas da rede 2.

Como funciona esse processo?

Suponha o ambiente abaixo:

· Rede 1: 192.162.0.0/24, servidor VPN com dois IPs, um da rede local (192.168.0.1) e outro da Internet (200.241.128.1);

· Rede 2: 192.162.1.0/24, servidor VPN com dois IPs, um da rede local (192.168.1.1) e outro da Internet (200.243.37.1).

Digamos que uma máquina (A) da rede 1, IP 192.168.0.2, deseja conversar com a máquina (B) da rede 2, de IP 192.168.1.2.

Deste modo, a máquina (A) irá enviar o pacote para seu gateway, 192.168.0.1. Ao receber este pacote o gateway identificará que o destino pertence à rede 2, conforme a Figura 4.

Figura 4. Tráfego original da estação e o gateway.

Ele irá então criar um novo pacote contendo como endereço de origem seu IP público, 200.241.128.1, e como endereço de destino o IP público do servidor de VPN da rede 2, 200.243.37.1. O servidor de VPN encapsulará todo o pacote original, o criptografará e o transmitirá como dados do novo pacote através da internet, conforme a Figura 5.

Figura 5. Transmissão entre os servidores de VPN.

Ao chegar ao servidor de VPN da rede 2 o processo é revertido de maneira que a máquina (B) irá receber o pacote original de (A) achando que tem comunicação direta com este. A Figura 6 ilustra esta etapa final.

Figura 6. Transmissão entre o servidor de VPN e o destino final.

Desta maneira as máquinas (A) e (B) poderão trafegar os dados através da Internet sem que o conteúdo seja exposto, por estar criptografado, e sem necessitar de configurações especiais nelas, apenas nos servidores de VPN.

Host a rede

No cenário de host a rede temos o ambiente mais comum existente no trabalho remoto, no qual você tem uma estação (host) que acessa a rede corporativa – observe a Figura 7.

Figura 7. VPN host a rede.

De forma similar ao que vimos no cenário rede a rede, os dados são encapsulados e criptografados antes de serem transmitidos.

O que acontece de diferente em relação ao cenário apresentado anteriormente é que neste será necessário instalar na máquina do usuário o software para o estabelecimento da VPN. Com isso ela deve ser configurada para estabelecer a VPN, não acontecendo da forma transparente como na configuração rede a rede.

O ambiente de teste

O cenário mais comum em um ambiente de VPN é aquele no qual temos uma estação remota acessando os recursos da rede interna. Neste artigo iremos realizar uma configuração de forma a habilitar este tipo de acesso. Para referência, utilizaremos os seguintes parâmetros:

1) Servidor

Sistema operacional Linux (distribuição CentOS 5.6);

Duas placas de rede (uma para a Internet e outra para a rede local);

Endereço de rede local 192.168.0.1/24;

Endereço da internet 200.243.68.1.

b) Cliente

Sistema operacional Windows 7;

Conexão à Internet.

Nesse ambiente iremos ilustrar como o Cliente poderá acessar remotamente os recursos da rede local ligada ao servidor. Assim será possível fazer com que o Cliente se comunique com qualquer IP da rede local do servidor como se estivesse ligado diretamente a ela.

Instalando o servidor

A instalação do software OpenVPN para o servidor pode ser feita de várias maneiras, dependendo da distribuição Linux que você utilize. Em nosso caso, utilizaremos o CentOS 5 e a instalação será feita pelo gerenciador de pacotes yum.

Deste modo, o primeiro passo é, como root, habilitar o repositório rpmforge, que disponibiliza versões binárias (já compiladas) do OpenVPN.

Importante: você necessitará fazer o download do pacote de acordo com a arquitetura utilizada (32bits ou 64bits). Levando em consideração esta questão, digite:

· Para 32 bits: wget http://packages.sw.be/rpmforge-release/rpmforge-release-0.5.2-2.el5.rf.i386.rpm;

· Para 64 bits: wget http://packages.sw.be/rpmforge-release/rpmforge-release-0.5.2-2.el5.rf.x86_64.rpm.

Em seguida você irá importar a chave GPGusada pelo rpmforge para assinar seus pacotes, conforme o comando:

rpm --import http://apt.sw.be/RPM-GPG-KEY.dag.txt

Agora você irá instalar o pacote que foi obtido (mude de acordo com a arquitetura usada), digitando:

rpm -Uvh rpmforge-release-0.5.2-2.el5.rf.i386.rpm

A partir deste momento seu servidor está configurado para acessar e instalar os pacotes providos pelo repositório rpmforge.

A instalação do OpenVPN é realizada utilizando-se o gerenciador de pacotes do CentOS, yum, que baixará todas as dependências:

yum install -y openvpn

Feito isso, você pode conferir se a instalação ocorreu com sucesso através do comando rpm -qi openvpn, que deve mostrar o resultado da Listagem 1.

Listagem 1. OpenVPN instalado.

  Name        : openvpn   Relocations: (not relocatable)
  Version     : 2.1.4     Vendor: Dag Apt Repository, http://dag.wieers.com/apt/
  Release     : 1.el5.rf    Build Date: Thu 02 Dec 2010 01:24:13 PM AMT
  Install Date: Mon 07 Mar 2011 02:57:40 PM AMT      
  Build Host: lisse.hasselt.wieers.com
  Group       : Applications/Internet     Source RPM: openvpn-2.1.4-1.el5.rf.src.rpm
  Size        : 984420                           License: GPL
  Signature   : DSA/SHA1, Thu 02 Dec 2010 01:40:13 PM AMT, Key ID a20e52146b8d79e6
  Packager    : Dag Wieers <dag@wieers.com>
  URL         : http://openvpn.net/
  Summary     : Robust and highly flexible VPN daemon

A próxima etapa consistirá em configurar o servidor OpenVPN para operar segundo a modalidade que desejarmos. As configurações do servidor ficam em /etc/openvpn.

Configurando servidor

Em nossa configuração (host a rede) utilizaremos a modalidade de autenticação baseada em certificados digitais. Ela é uma maneira mais forte por se basear no conceito de autenticação de dois fatores (two-factor authentication): uma senha e o certificado.

Desta maneira não adianta saber a senha sem ter o certificado correspondente ou ter o certificado e não saber a sua senha.

Criando o Certificate Authority

Assim, o primeiro passo será criar nosso cartório digital, ou Certificate Authority (CA). Esse cartório será responsável por criar os certificados para os usuários da VPN.

O processo de criação de certificados é facilitado pela instalação do pacote OpenVPN, uma vez que com este pacote são instalados também pequenos programas, sob a forma de scripts, para auxiliar nessa atividade. Para criar os certificados para o seu servidor e Cliente basta seguir os passos abaixo:

1) Copie o script de criação

O OpenVPN instala os scripts de criação no diretório /usr/share/doc/openvpn-2.1.4/easy-rsa. Para facilitar o processo vamos copiá-lo para o diretório do root:

cp -avr /usr/share/doc/openvpn-2.1.4/easy-rsa /root

2) Edite o arquivo vars existente nesse diretório

Esse arquivo contém diretivas de como você irá operar seu cartório digital. As configurações que devemos alterar estão no final do arquivo:

export KEY_COUNTRY="US"
  export KEY_PROVINCE="CA"
  export KEY_CITY="SanFrancisco"
  export KEY_ORG="Fort-Funston"
  export KEY_EMAIL="me@myhost.mydomain"

Altere-as de acordo com a sua realidade, sendo o KEY_COUNTRY a sigla para o país, KEY_PROVINCE o estado, KEY_CITY a cidade, KEY_ORG o nome de sua empresa (ou organização) e KEY_EMAIL o e-mail do responsável pela empresa.

3) Carregue as configurações

Na linha de comando, execute o comando:

. vars

Isso irá carregar em memória as opções definidas no arquivo vars.

4) Crie o certificado para o seu CA

Execute o comando:

./build-ca 

O processo irá criar a chave e certificado para o CA, conforme a Listagem 2.

Listagem 2. Criação do certificado do 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) [KG]:
  State or Province Name (full name) [NA]:
  Locality Name (eg, city) [BISHKEK]:
  Organization Name (eg, company) [OpenVPN-TEST]:
  Organizational Unit Name (eg, section) []:
  Common Name (eg, your name or your server's hostname) []:OpenVPN-CA
  Email Address [me@myhost.mydomain]: 

Em seguida é necessário criar o arquivo contendo os parâmetros para o servidor de VPN, executando o comando:

./build-dh

O processo é automático e acontecerá como na Listagem 3.

Listagem 3. Criando o arquivo com os parâmetros Diff-Hellfman.

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

Ele irá criar um arquivo chamado dh1024.pem, que será usado pelo seu servidor e clientes na criação das chaves efêmeras necessárias para a criptografia do tráfego enviado e recebido[2].

Criando o certificado para o servidor de VPN

Na comunicação criptografada que existe entre os dois pontos (cliente de um lado e servidor do outro) há a necessidade de que ambos os lados possuam certificados digitais. E para criar este certificado você deve usar o comando:

./build-key-server server

A execução do mesmo resultará em dois arquivos, server.key e server.crt. Estes serão usados apenas pelo seu servidor de VPN e não deverão ser compartilhados com ninguém.

Criando o arquivo de configuração do servidor

Após a definição do certificado do servidor, é necessário realizar a configuração do OpenVPN que utilizará os arquivos criados anteriormente. Para isso, devemos criar o arquivo de configuração chamado server.conf que ficará localizado no diretório /etc/openvpn.

Na Listagem 4 é possível ver o arquivo completo.

Listagem 4. Configuração do servidor.

local 200.243.68.1
  port 1194
  proto udp
  dev tun
   
  ca /etc/openvpn/ca.crt
  cert /etc/openvpn/server.crt
  key /etc/openvpn/server.key
  dh /etc/openvpn/dh1024.pem
   
  server 10.0.0.0 255.255.255.0
  comp-lzo
   
  keepalive 10 120
   
  max-clients 3
   
  status /var/log/openvpn-status.log
   
  log-append  /var/log/openvpn.log
   
  verb 3
   
  push "route 192.168.0.0 255.255.255.0"

Como podemos notar, existem várias diretivas no arquivo de configuração. O funcionamento das principais será visto a seguir:

1) local 200.243.68.1

A diretiva indica qual dos IPs do servidor será usado para escutar conexões (bind). Informe sempre o IP configurado na placa de rede externa, ou seja, aquela na qual a conexão com a Internet do seu servidor está ligada.

2) port 1194

Indica qual a porta na qual o servidor de VPN aguardará as conexões. A porta padrão do OpenVPN é a 1194, mas você pode escolher outra de sua conveniência.

3) proto udp

O OpenVPN suporta tanto TCP quanto UDP como protocolos de transmissão.

4) ca /etc/openvpn/ca.crt

Indica o nome e o local no qual o certificado do CA está localizado. Em nosso caso, criamos em passos anteriores este arquivo.

5) cert /etc/openvpn/server.crt

Indica o nome e o local no qual o certificado do servidor está localizado. Este foi criado quando executamos o comando build-key-server.

6) key /etc/openvpn/server.key

Indica o nome e o local no qual a chave do servidor está localizada. Esta foi criada quando executamos o build-key-server.

7) dh /etc/openvpn/dh1024.pem

Indica o nome e o local no qual o arquivo com os parâmetros do servidor está localizado. Este foi criado através do comando build-dh.

8) server 10.0.0.0 255.255.255.0

Quando um cliente se conectar ao servidor ele irá criar uma interface virtual. Para esta interface o servidor irá alocar um IP da faixa indicada por esta diretiva. Em nosso exemplo serão IPs da faixa 10.0.0.0.

9) max-clients 3

Indica o número máximo de conexões simultâneas (clientes) que podem se conectar. É importante que o número indicado não seja superior ao número de IPs definidos na diretiva server.

10) push "route 192.168.0.0 255.255.255.0"

Este indica que quando um cliente se conectar ele irá receber um comando para criar uma rota para a rede 192.168.0.0/24. Isso faz com que o servidor possa mandar comandos para o cliente de maneira que a configuração do cliente seja simples.

É possível ter várias linhas dessas push no mesmo arquivo, uma para cada configuração que você deseja que o Cliente receba. É possível, por exemplo, colocar novas rotas ou indicar o endereço IP do servidor Wins (recurso utilizado na resolução de nomes para redes Microsoft).

Instalando o cliente

Uma das vantagens do OpenVPN é a sua natureza de código aberto que facilita que ele seja portado para diversas plataformas. Além de ser possível obtê-lo sob a forma de código fonte, você o encontra já compilado para Windows, Mac OS X e diversas distribuições do Linux. Na Figura 8 vemos a ferramenta instalada em um sistema operacional Windows.

Figura 8. Ferramenta gráfica para controle da VPN em ambiente Windows.

Em um ambiente Windows a instalação do OpenVPN é extremamente simples. Para isso, você deve realizar o download da última versão em http://openvpn.net/index.php/open-source/downloads.html e seguir o processo de Install, Next, Next.

Além da instalação dos arquivos que darão suporte ao software, o instalador para Windows vem com uma ferramenta gráfica que fica disponível na barra de tarefas e lhe permite iniciar e encerrar conexões com OpenVPN de maneira simplificada.

Configurando o cliente

Como parte do processo de estabelecimento da VPN, o cliente e o servidor trocam certificados antes de iniciar a transmissão dos dados criptografados. Deste modo, é preciso criar um certificado para o cliente e sua respectiva configuração. Para isso, execute os comandos descritos a seguir:

1) Criar a chave e certificado para o cliente

No servidor, execute o comando build-key-pass:

sh build-key-pass cliente

Substitua o cliente pelo nome (ou e-mail) do usuário para o qual você estará gerando a chave.

Em seguida o script irá criar a chave e pedir que você coloque uma senha, conforme a Listagem 5. Nesse momento, preferencialmente, o usuário da chave deverá estar presente para definir a sua senha.

Listagem 5. Criando a chave do cliente.

Generating a 1024 bit RSA private key
  ....................++++++
  ........++++++
  writing new private key to 'cliente.key'
  Enter PEM pass phrase:
  Verifying - Enter PEM pass phrase: 

Feito isso, o script irá solicitar algumas informações específicas do cliente (tais como o e-mail) para incorporar no certificado a ser gerado. Na Listagem 6 vemos que o script já vem preenchido com alguns dados padrão e na prática só precisamos alterar dois valores: Common Name e Email Address.

Listagem 6. Especificando os parâmetros do certificado do cliente.

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) [EE]:
  Locality Name (eg, city) [CIDADE]:
  Organization Name (eg, company) [SUA EMPRESA]:
  Organizational Unit Name (eg, section) []:
  Common Name (eg, your name or your server's hostname) []:email.suaempresa.com.br
  Email Address [adm@suaempresa.com.br]: cliente@suaempresa.com.br
   
  Please enter the following 'extra' attributes
  to be sent with your certificate request
  A challenge password []:
  An optional company name []:

O Common Name deverá ser, apenas por questões de padronização, igual ao e-mail do cliente sem o @. Logo, se o e-mail dele for joao@suaempresa.com.br, o Common Name será joao.suaempresa.com.br.

Na sequência, o próprio software irá assinar o certificado com a chave do CA que foi gerada logo no começo do processo. Na Listagem 7 o script repete os dados entrados e solicita a sua confirmação.

Listagem 7. Assinando o certificado do cliente.

Using configuration from /root/easy-rsa/openssl.cnf
  Check that the request matches the signature
  Signature ok
  The Subject's Distinguished Name is as follows
  countryName           :PRINTABLE:'BR'
  stateOrProvinceName   :PRINTABLE:'EE'
  localityName          :PRINTABLE:'CIDADE'
  organizationName      :PRINTABLE:'SUA EMPRESA'
  commonName            :PRINTABLE:'cliente.suaempresa.com.br'
  emailAddress          :IA5STRING:'cliente@suaempresa.com.br'
  Certificate is to be certified until Jun 13 01:50:04 2012 GMT (365 days)
  Sign the certificate? [y/n]:y
   
  1 out of 1 certificate requests certified, commit? [y/n]y
  Write out database with 1 new entries
  Data Base Updated

No final desse processo o script terá criado dois arquivos chamados de cliente.key e cliente.crt, ambos no diretório keys do servidor.

2) Copiar os arquivos para a máquina do cliente

Nas etapas anteriores foram criados vários arquivos que serão usados pelo cliente. Como estes foram gerados no servidor, será necessário copiar os arquivos ca.crt, cliente.key, cliente.crt e dh1024.pem do diretório keys do servidor para a máquina do cliente.

Você deverá colocá-los no diretório do OpenVPN. Dependendo da versão do Windows instalado, ele poderá mudar, mas o local padrão é C:\Program Files\OpenVPN\config.

3) Criar o arquivo de configuração

A etapa final do processo consiste em criar o arquivo de configuração para a sua VPN. Para tanto, basta usar o bloco de notas e criar um arquivo em C:\Program Files\OpenVPN\config\empresa.ovpn.

O nome em si não é importante, desde que a extensão .ovpn seja mantida. O programa que controla a VPN lê todos os arquivos .ovpn do diretório acima e os exibirá como opção para conexão.

Em nosso caso, criaremos o arquivo conforme a Listagem 8.

Listagem 8. Arquivo de configuração do cliente.

client
   
  dev tun
  proto udp
  remote 200.243.68.1 1194
  resolv-retry infinite
  nobind
   
  ca “C:\\Program Files\\OpenVPN\\config\\ca.crt”
  cert “C:\\Program Files\\OpenVPN\\config\\cliente.crt”
  key “C:\\Program Files\\OpenVPN\\config\\cliente.key”
   
  cipher BF-CBC
  verb 3
   
  comp-lzo

O arquivo do cliente é mais simples que o do servidor, repetindo-o em alguns pontos, como as diretivas proto e dev.

A primeira diferença entre os arquivos de configuração do cliente e do servidor é que estamos configurando o OpenVPN para atuar em modo cliente (client).

Logo em seguida é informado onde o servidor estará localizado e qual a porta que devemos conectar (remote 200.243.68.1 1194). Note que você usará o IP (ou nome, caso exista) público do servidor e a mesma porta definida nele.

Em seguida precisamos informar onde o software poderá encontrar os arquivos contendo o certificado do CA (ca.crt), o certificado do cliente (cliente.crt) e sua chave correspondente (cliente.key). Diferentemente do ambiente Linux, você deverá usar aspas duplas e barras duplas.

Agora é só salvar o arquivo e iniciar a conexão escolhendo a opção Connect da barra de tarefas. Com isso, uma janela semelhante à Figura 9 aparecerá e o cliente deverá informar a mesma senha usada na criação de sua chave.

Uma vez conectado à VPN você poderá, por exemplo, acessar os servidores da rede local da mesma maneira que faria se estivesse conectado diretamente a ela.

Figura 9. Informando a senha do certificado para iniciar a VPN.

Conclusão

Ao longo deste artigo vimos como é possível criar um ambiente seguro para permitir a comunicação entre pontos remotos e sua rede corporativa usando um ambiente GNU-Linux e software livre.

Os conceitos vistos aqui podem ser utilizados tanto para a comunicação entre pontos remotos (host-rede), como no caso de consultores atuando remotamente, ou ainda redes remotas (rede-rede), como na ligação entre a matriz e suas filiais.

Existem outras formas de configuração de sua VPN que podem se adequar à realidade de sua rede ou necessidade de segurança. O OpenVPN tem suporte, por exemplo, a dispositivos de autenticação (e-token) similares aos usados em autenticação bancária ou ainda a associar configurações de IP e firewall específicas a um certificado. Esperamos que este artigo sirva de ponto de partida para a sua configuração.

Links

OpenVPN
http://openvpn.net

Iptables
http://www.frozentux.net/documents/iptables-tutorial/