VPN Site-to-MultiSite Centralizada com OpenVPN

Acredito que em algum momento, todos que já trabalharam em setores de infra-estrutura de empresas com duas unidades (clássico exemplo da matriz/filial) leram a respeito de como criar um túnel seguro de comunicação entre elas. A internet está cheia de ótimos tutoriais a respeito. Primeiro, instalamos softwares de VPN em ambas as pontas e então, utilizamos alguma espécie de chave criptográfica. Deixamos muito bem declarados em seus arquivos de configuração ambas as redes e com esmero tratamos as rotas. Pronto! Dois sites se comunicando…
Porém, quando o ambiente começa a se tornar maior e mais distribuído, é hora de pensar em um modelo mais abrangente e plugável.

OpenVPN é uma solução de VPN sobre SSL livre, e cheia de recursos. Com base neste produto, desdobraremos este artigo.

Inicialmente, precisamos pensar em um escopo de rede adequado, organizado, e escalável. Dessa forma, conseguiremos prover conectividade em qualquer ponto de nossa rede, e não nos preocuparemos com o crescimento dos sites.

Imaginemos um ambiente com 3 sites.

Poderíamos abranger esse modelo com o primeiro Range reservado 192.168.0.0/16 , possibilitando o uso de 65.536 Ips. Todavia , em nosso exemplo, utilizaremos o 172.16.0.0/12.

Este range abrange de 172.16.0.0 até 172.31.255.255.

Neste exemplo, designaremos 4 ranges /24 para cada unidade, totalizando 1024 Ips por site. Cada site pode subdividir estes ranges de acordo com sua vontade, tendo em vista, apenas o cuidado para que suas regras internas não acabem restrigindo a conectividade dos pontos, se não for esta a vontade do local Admin.

Neste caso, teríamos o seguinte cenário:

Cenário Proposto - Estudo de Caso

Agora que já aplicamos um escopo a nossa rede, é hora de pensar na conexão entre os pontos.
Os firewalls de cada ponta, se comunicam via internet. Neste caso, precisamos estabelecer um tunel virtual e transparente para os usuários do circuito. Qualquer pacote correto que cruzar este túnel, será possívelmente comprimido, depois, criptografado, e então encapsulado, para ser transportado via internet, como qualquer outro. Na outra ponta, ele será aberto, decriptografado, descomprimido, e então entregue ao destino. Esse é o funcionamento básico da VPN.

Trajeto dos Pacotes dentro da VPN

De acordo com este modelo, basta desviarmos os pacotes para um tunel virtual, e eles serão capturados pelo OpenVPN e assim, encapsulados e entregues. De fato, é assim que funciona, porém, ainda precisamos configurar o OpenVPN para que ele possa identificar para qual firewall destinar qual pacote. Não podemos esquecer, que agora, estamos lidando com mais de uma rede, ou seja, precisamos fazer com que o OpenVPN detecte atras de qual firewall, cada rede está. Isto será feito, pela marcação de configurações de acordo com o certificado SSL de cada cliente. Pode parecer meio confuso agora, mas assim que gerarmos os certificados, verificaremos que é simples e objetivo.

Antes de mais nada, é necessário instalar o OpenVPN. Nele existe um helper, que nos ajudará a criar as Certificados SSL e as Chaves do Servidor ( Concentrador ) e de cada cliente. Na verdade, é um conjunto de scripts, chamado “easy-rsa”. Estas chaves serão assíncronas, ou seja: Teremos uma chave pública, e uma privada para realizar a conexão. A chave pública é usada para se “autenticar” na privada, e então, gerar uma nova chave (assíncronamente) para aquela conexão. Com base nesta nova chave, é que os dados serão criptografados.
Neste artigo, não abordarei a instalação do OpenVPN. No Windows, a instalação é NNF ( Next, Next, Finish ). Em ambientes Unix, utilize seu gerenciador de pacotes, ou baixe os sources no site oficial e os compile. OpenVPN funciona muito bem nos principais BSD Flavors, e é empacotado em praticamente qualquer distribuição Linux. Apenas como dica, habilitem o suporte a LZO. É uma biblioteca de compressão muito leve e eficaz. Dependendo do conteúdo do Datagrama, ele pode ser muito reduzido com esse algorítimo, gerando um aumento perceptível de performance, e consequentemente economia de banda.
É interessante ter o iproute2 instalado em seu servidor. Ele te dará maior flexibilidade ao lidar com modelos de roteamento mais complexos, e se estiver presente, também será usado pelo OpenVPN para marcar as rotas de desvio. Caso não, o OpenVPN tentará usar o nettools padrão do sistema.

Depois de instalar o OpenVPN, precisamos localizar os scripts do “easy-rsa”. No Linux, usualmente, estão no diretório de documentaçãoes das aplicações do usuário, em /usr/share , dentro de openvpn/

O Primeiro passo para gerar os certificados, é configurar o arquivo de variáveis do easy-rsa. Edite o arquivo “vars” da maneira que lhe convir. Note a seguinte variável: KEY_SIZE
Você deve configurar nela o tamanho da chave RSA utilizada para criptografar os dados. 1024 é bastante seguro, porém, você tem a liberdade de gerar com qualquer valor. Se você é paranóico (notas do comentário do arquivo), pode alterar para 2048. Obviamente, este aumento incide e maior complexidade na criptografia, ou seja, mais consumo de banda e CPU. Porém, nada tão alarmante.

Após configurar o arquivo, o execute, ou apenas carregue o conteúdo de suas variáveis.

chmod +x vars && ./vars
ou:
source vars

Logo depois, limpe quaisquer configurações anteriores:
./clean-all

Se você não alterou o diretório onde as chaves serão geradas, elas ficarão em ./keys

Supondo esta localidade, vamos começar a gerá-las.
Inicialmente, vamos gerar o certificado e a chave privada.
./pkitool –initca

Agora, a chave do servidor:
./build-key-server concentrator

Confirme os dados, e a assinatura do certificado pelo Script. Atente-se a este parâmetro: commonName. Este parâmetro, é identificador. O utilizaremos mais a frente.
PS: “concentrator” é o nome que escolhi para o servidor, devido a ele concentrar as conexões, entre outras informações. Escolha o nome que lhe parecer melhor.

Agora, é só gerar as chaves dos clientes, ou seja, dos outros firewalls que participarão da VPN.

./build-key client1
./build-key client2

O processo é o mesmo que gerar a chave do servidor. Basta confirmar os dados, e se atentar ao parametro commonName.

Por último, vamos gerar os parâmetros Diffie-Hellman, que serão utilizados pelo servidor ao abrir as conexões TLS.
./
build-dh

Agora, vamos configurar o Servidor.
Apenas por convenção, manteremos a configuração dos arquivos em /etc/openvpn. Dentro deste diretório, teremos um diretório keys, com as chaves e certificados, e um diretório com o nome de client-configs, onde ficarão os arquivos de configuração de clientes. Serão estes arquivos que instruirão o servidor sobre os destinos de pacotes de cada rede conectada ao sistema.
Inicialmente, crie um arquivo com o nome de server.conf com o seguinte conteúdo:

# Inicio do Arquivo de Configuracao do Servidor
# IP onde o OpenVPN ira abrir seu listenner ( aceitar conexoes, usualmente o IP externo do firewall )
local xxx.xxx.xxx.xxx
port 1194
dev tun

# Certificados e chaves do servidor
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/concentrator.crt
key /etc/openvpn/keys/concentrator.key
dh /etc/openvpn/keys/dh1024.pem

# Range de Ips utilizado para designição dos tuneis virtuais em cada maquina. Utilize um range não conflitante com o restante de sua rede.
server 10.255.254.0 255.255.255.0
# Este parametro habilita a conversa entre clientes da do servidor, ou seja, redes x redes.
client-to-client
# Especifica onde ficarao os arquivos de configuracoes de cada cliente, de acordo com seu commonName ( Paramentro do certificado SSL )
client-config-dir /etc/openvpn/client-configs

# Testando e instruindo testes nos clientes. O sitema deve refazer as conexoes em caso de falhas
ping 10
ping-restart 120
push “ping 10”
push “ping-restart 60”

# Entregando rota aos clientes ( Deve conter a previsao de todas as redes, mesmo que o servidor as entregue para quem ja as conhece ( como por exemplo, informar a rede da propria lan do cliente ).
push “route 172.16.0.0 255.255.252.0”
push “route 172.16.4.0 255.255.252.0”
push “route
172.16.8.0 255.255.252.0

# Instruindo rotas ao server (Nao inclua a propria Lan dele nesta seção)
route 172.16.4.0 255.255.252.0
route
172.16.8.0 255.255.252.0

# Corrigindo alguns problemas conhecidos de MTU
mssfix 1400
fragment 1400

# Declarando persistencia de chaves e tuneis
persist-tun
persist-key

# Desviando logs para respectivos arquivos
log /var/log/openvpn-server.log
status /var/log/openvpn-server.status 10
# Verbosidade do Log
verb 3

# Habilitando compressao lzo
comp-lzo

# Fim do arquivo de configuração do Servidor

Atente-se aos parâmetros das chaves SSL. Copie somente os arquivos necessários (que foram gerados no diretório keys do easy-rsa) para o diretório keys, no diretório de configuração da VPN.
Para inicializar o daemon no servidor, digite:

openvpn –config /etc/openvpn/server.conf –daemon

Agora, você pode monitorar os logs para acompanhar as conexões dos clientes:

tail -f /var/log/openvpn-server.log

Agora, vamos falar sobre os arquivos de configuração dos clientes dentro do servidor:
Como dito anteriormente, existe um diretório com o nome de client-configs, onde armazenaremos informações sobre as redes dos clientes. Na verdade, no nosso cenário, este arquivo terá apenas uma linha, que dirá em qual rede este cliente está. O arquivo PRECISA ter o nome de seu commonName de seu certificado SSL. Ou seja, se você confimou o nome de seus clientes como client1 e client2, você terá os arquivos com estes nomes dentro de client-configs.

O Conteúdo, como dito anteriormente, será apenas uma linha:

# Arquivo client1
iroute 172.16.4.0 255.255.252.0

# Arquivo client2
iroute 172.16.8.0 255.255.252.0

Assim que o cliente se conectar ao servidor, armazenará seu IP. De acordo com a autenticação pelo certificado, reconhecerá o arquivo de configuração dentro de client-configs, e aprenderá que aquela rede pertence a este cliente. Dessa forma, o sistema distrbuirá somente as rotas necessárias ao cliente ( evitando passar informações sobre sua própria rede ). O parâmetro iroute fará com que o OpenVPN associe a rede interna do firewall a ele, e assim, solicitações de cominicação com aquela rede já terão o destino reconhecido. O mesmo acontecerá com os demais clientes.
Observação:  O diretório client-configs existe somente dentro do servidor(concentrador). Não é necessário ter este diretório e arquivos nos firewalls que vão se conectar a ele.

Aos Firewalls clientes, só resta se conectar ao servidor. O arquivo de configuração deles é ainda mais simples. Confira abaixo, e não esqueça de copiar os arquivos das chaves SSL relacionadas a cada firewall cliente nos diretórios onde aponta o arquivo de configuração.

### Arquivo de configuracao do cliente
dev tun
# IP do servidor da VPN
remote xxx.xxx.xxx.xxx 1194
tls-client
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/clientN.crt
key /etc/openvpn/keys/clientN.key
pull
nobind
mssfix 1400
fragment 1400
verb 3
comp-lzo

###########

Pronto. A configuração principal já está feita. Na maioria dos casos, ela inclusive deve bastar. Se o servidor onde está o OpenVPN não for o default Gateway de sua rede, apenas tome o cuidado de incluir rotas estáticas nas estações que se beneficiarão da VPN, desviando os destinos das outras LANS para este servidor, ou até mesmo, desviando as rotas diretamente pelo Gateway padrão (recomendado).

Para startar os daemons nos clientes:

openvpn –config /etc/openvpn/client.conf –daemon

Agora, basta acompanhar a conexão no servidor, e fazer os testes nos clientes.

Observe no diagrama abaixo, como ficaria a topologia de nossa vpn neste modelo:

Diagrama da VPN em Produção

Observe nesse Screencast, a VPN em funcionamento:


Algumas considerações:

Consideração A: É possível realizar qualquer filtro na comunicação entre as redes em qualquer um dos firewalls. Após os pacotes passarem pelos túneis (usualmente interfaces TUN ou TAP, dependendo de sua escolha), eles já estarão decriptografados e prontos para entrega. Desta forma, qualquer regra de firewall, pode manipulálos. Exemplo de uma regra usando iptables, o  firewall linux:

iptables -t filter -A FORWARD -s 172.16.0.56 -d 172.16.4.23 -j DROP

Esta regra impedirá que o IP 172.16.0.56 ( Rede A ) envie pacotes ao IP 172.16.4.23 da rede B. Se essa regra for colocada no Firewall da rede A ( Concentrador, e responsável por esta rede ), ele nem sairá pela VPN. Se for colocada no Firewall da rede B, ele trafegará na VPN, mas o firewall não permitirá a entrega.
Dessa forma, é possível fazer um controle fino e eficaz da comunicação.

Consideração B: Não se esqueça de liberar a conexão na porta 1194 do Servidor, via UDP, para os IPS dos Firewalls de cada ponta. Se você optar por alterar essa porta no OpenVPN, não se esqueça de alterar também em seu Firewall. Também tome cuidado com políticas de encaminhamento restritivas(recomendado inclusive), para não bloquear o trafego entre as redes por completo, e pensar que é um problema de configuração dos daemons da VPN.

Consideração C: Não se esqueça de configurar o OpenVPN para ser inicializado automaticamente no boot do servidor. Utilize os mecanismos default de sua Distribuição para isto, ou algum script manual, configurado no Run-level que você achar mais apropriado.

Consideração D: Evite fazer NAT dos IPS das redes internas. Dessa forma, você não conseguirá identificar de qual máquina de cada rede vem os pacotes.

Consideração E: Como observado no diagrama final, a comunicação entre os sites, passará pelo concentrador, portanto, este ponto deve ter uma infra-estrutura (principalmente de comunicação) capaz de suportar esta demanda.

—————-

Espero que este pequeno artigo possa ajudá-lo em seus projetos de VPN. Sinta-se livre para usar as informações, e/ou citar este blog em qualquer lugar. Apenas não se aproprie do artigo, postando-o em seu próprio blog. Sabemos como é chato quando isso acontece, por mais simples que ele seja.

No próximo artigo, mostrarei uma solução de VPN site-to-multisite descentralizada.

Eduardo Frazão
edufrazao – @ – gmail.com

Anúncios

10 Respostas to “VPN Site-to-MultiSite Centralizada com OpenVPN”

  1. Nina Says:

    Gostei mto:).Apesar de não ter entendido mto bem.

  2. Leonardo Says:

    Parabéns, pelo seu esforço..
    material muito bom

  3. Madella Says:

    Gostaria de parabeniza-lo pelo excelente artigo. Já analisei muitos pela net, otima clareza.

    Sucesso.

    Thiago Madella

  4. Luiz Paulo Says:

    Caro, parabéns, material de qualidade! Muito bom mesmo o artigo.

  5. rOmulO Says:

    Bacana..

  6. eduardo pedrosa Says:

    como o client1 chegaria ao clinet2

    • edufrazao Says:

      Boa tarde Eduardo. Neste caso, chega através do servidor central. Ele identifica a rota de destino de cada pacote, e encaminha para o servidor necessário. Na outra ponta, ele entrega para o destino final.

  7. emmy Says:

    great, please eduardo, can u do the video in english, and notify me true emmy4life23@yahoo.com

    • anderson gelmires Says:

      esse foi o único material que encontrei com mais de uma filial é simples e objetivo , mas um vídeo é bem melhor , porque nós usuários do linux vamos entender melhor porque vamos ver na prática como é cada passo descrito nesse tutorial.

  8. anderson gelmires Says:

    material muito bom, seria melhor se fosse uma vídeo aula do inicio ao fim , ficaria muito mais clara a explicação.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s


%d blogueiros gostam disto: