VPN Site-to-MultiSite Descentralizada com Tinc

Em outro Post, fiz um pequeno artigo, mostrando uma das formas de se construir uma VPN Site-To-MultiSite, usando um centralizador. O Centralizador nada mais é do que um Daemon, responsável por encaminhar pacotes entre os firewalls, e distribuir informações de rotas/e outras miscelâncias afim de automatizar certas tarefas nos firewalls clientes. De fato, é um modelo muito interessante de se trabalhar, e cai bem em vários ambientes. Mas como toda solução, tem seus contras também. Inicialmente, infra-estrutura. Como o tráfego de dados, tem sempre que passar pelo nó central, a infra-estrutura de comunicação pode ficar cara. Caso não haja investimentos, ela pode ser lenta e instável, as vezes até inviabilizando a solução. Existe o problema do nó principal ficar off-line também. Desta forma, todos os outros nós perdem a comunicação (com o nó principal, e também com todos os outros).
Afim de não perder a conectividade total coberta pelo modelo centralizador, e evitar tais problemas de sobrecarga e super dependência, apresento este artigo utilizando o Tinc (http://www.tinc-vpn.org/), que é um Sistema de VPN Livre, com suporte a SSL, e roteamento automático de redes, onde os Firewalls sempre tentarão uma conexão direta entre os pontos, caso seja possível.
Dessa maneira, teremos um modelo de VPN praticamente “peer-to-peer“, e pouca dependencia de centralizadores (para tráfego de fato nenhuma, mais a frente explicarei melhor).

Vamos verificar esta solução…

Sobre a instalação: Neste artigo, não abordarei nenhum procedimento específico de instalação. Utilize o gerenciador de pacotes de sua distribuição, ou compile os códigos fontes, que podem ser obtidos no site oficial. Caso você opte por instalar via sources, tome o cuidado de instalar a libz, a liblzo2 e a LibSSL em seu sistema antes. Mesmo que você não pretenda utilizar criptografia ou compressão, elas são necessárias para a compilação (Notas do Readme).

Com o Tinc instalado, vamos começar a configuração. Neste artigo, atenderemos a seguinte topologia de rede:

Em geral, os pacotes e/ou processos de instalação das distribuições deixam o diretório de configuração do Tinc em /etc/tinc. Vamos tomar esse diretório como base neste artigo. Você pode criar divisões dentro do diretório de configuração, onde serão hospedados todos os arquivos de configuração, de determinada rede. Poderíamos ter daemons de VPN nos interligando a redes de distintas empresas (Não estou falando de sites, e sim, de conjuntos de sites, por empresa por exemplo). No nosso caso, criaremos apenas uma “rede” para o Tinc, que irá abranger nossos 3 sites.

O Tinc pode trabalhar com interfaces TUN ou TAP. Interfaces TAP são utilizadas para trabalhar como bridge, e TUN, como uma interface de tunelamento mais simples. Utilizaremos interfaces TUN neste artigo. A maioria das distribuições Linux, compilam o modulo tun (modprobe tun para carregá-lo) em seu kernel, ou o deixam como built-in. Se você mesmo compilou seu kernel, não se esqueça de conferir o suporte a interfaces TUN/TAP

No Firewall da rede A, vamos realizar alguns procedimentos.
Entre no diretório /etc/tinc e crie um diretório com o nome de “vpn”.
Dentro deste diretório, crie um arquivo com o nome de tinc.conf, com o seguinte conteúdo:

Name = NetworkA
Interface = tun0

Agora, crie um diretório com o nome de “hosts ” . Neste diretório, ficarão armazenadas todas as chaves públicas dos Firewalls participantes da VPN, inclusive a sua. Agora, vamos gerar a chave publica e privada deste servidor.

# tincd -n vpn –generate-keys

Confirme o nome do arquivo da chave privada e da pública apenas pressionando enter, confirmando os arquivos nos locais automaticamente indicados.
Caso você tenha a vontade/necessidade de alterar estes locais, você pode fazê-lo, porém, você vai precisar indicar estes arquivos nos arquivos de configuração. É recomendado manter assim, pois dessa forma, fica mais fácil e padronizada a instalação de novos nós a rede.

Please enter a file to save private RSA key to [/etc/tinc/vpn/rsa_key.priv]:
Please enter a file to save public RSA key to [/etc/tinc/vpn/hosts/NetworkA]:

Dentro do diretório hosts, agora existe um arquivo com o nome de NetworkA. Abra-o com o editor de textos. Você vai visualizar a chave pública. Acima dela, acrescente as seguintes linhas:

Subnet = 172.16.0.0/22

Address = 200.187.176.48

Compression = 10

# Esta rede local
Subnet = 172.16.0.0/22
# O IP Externo deste Servidor
Address = xxx.xxx.xxx.xxx
# Nivel de compressao ( 8 – Zlib, 9 – Best Zlib, 10 – LZO, 11 – BestLZO )
Compression = 10

Desta forma, seu arquivo deve ficar assim:

Subnet = 172.16.0.0/22
Address = xxx.xxx.xxx.xxx
Compression = 10

—–BEGIN RSA PUBLIC KEY—–
…..
—–END RSA PUBLIC KEY—–

No Firewall da Rede B, vamos praticamente repitir o processo:

Crie um diretorio “/etc/tinc/vpn” e dentro de vpn, crie um diretorio “hosts”.
Crie um arquivo com o nome de tinc.conf com o seguinte conteúdo:

Name = NetworkB
Interface = tun0
ConnectTo = NetworkA
ConnectTo = NetworkC

Gere as chaves:
tincd -n vpn –generate-keys

Edite o arquivo hosts/NetworkB

Adicione antes da chave:

Subnet = 172.16.4.0/22
Address = xxx.xxx.xxx.xxx
Compression = 10

Na Rede C, faça a mesma coisa, apenas alterando o arquivo tinc.conf para:
Name = NetworkC
Interface = tun0
ConnectTo = NetworkA
ConnectTo = NetworkB

E o adicionando a hosts/NetworkC

Subnet = 172.16.8.0/22
Address = xxx.xxx.xxx.xxx
Compression = 10

Os arquivos de configuração de cada rede já estão prontos. Agora, precisamos criar os arquivos de cofiguração do Tinc que serão invocados quando o daemon for inicializado, ou interrompido. Nestes arquivos, teremos que configurar as rotas de cada rede, para o túnel designado. Isso pode ficar entediante dependendo da quantidade de pontos da rede, justo que quando uma rede for incluída, teremos que fazer essas configurações em todas as outras ( Não temos mais um centralizador para informar rotas ).

Para ajudar neste trabalho, criei um pequeno script bash, que fará a leitura dos arquivos dentro do diretório hosts, já que lá, estão todas as informações que precisamos para configurar as rotas. De qualquer forma, sempre que incluirmos uma nova rede, precisaremos colocar seu arquivo de chave publica com suas informações de rede em todos os pontos mesmo.

O Arquivo que é invocado pelo Tinc em sua inicialização é o tinc-up.
Crie um arquivo com este nome no diretório onde você criou o tinc.conf, com o seguinte conteúdo:

#!/bin/bash
## Wrapper para o script tinc-inits

# Subindo a interface estabelecida no tunel. A variavel INTERFACE e implicita
ifconfig $INTERFACE 10.255.254.1 netmask 255.255.255.0 up

# Chamando script para configurar as rotas “dinamicamente”
/etc/tinc/vpn/tinc-routes start $INTERFACE
############

Observação Importante: Observe que a variavel INTERFACE não foi configurada em nenhum local do script. Ela é criada implicitamente pelo daemon, quando ele invoca o arquivo. Outra observação importante é o IP atribuído na interface. Considere este IP como o da NetworkA. Na NetworkB, coloque 10.255.254.2, e assim por diante sequencialmente. Se um firewall tentar falar com outro, a comunicação será por esses IPS, a menos que você influencie via NAT, logo, estes IPS não são meramente para desvio. Eles podem ser usada na comunicação entre os firewalls ( um com destino diretamente ao outro ).

Agora, crie um arquivo com o nome de tinc-down (invocado no encerramento do daemon), no mesmo diretório, com o seguinte conteúdo:

#!/bin/bash
## Wrapper para o script tinc-inits

# Chamando script para configurar as rotas “dinamicamente”
/etc/tinc/vpn/tinc-routes stop $INTERFACE

# Subindo a interface estabelecida no tunel. A variavel INTERFACE e implicita
ifconfig $INTERFACE down
########

Agora, vamos criar o script que é invocado no final de tinc-up e tinc-down. Crie um arquivo com o nome de tinc-routes, no mesmo diretório, com o seguinte conteúdo:

#!/bin/bash
###############
# Arquivo tinc-up. Invocado depois que o daemon do tinc subir para esta network
# Este arquivo tenta automatizar a tarefa de preparacao das rotas de outras networks
# Sem configuracoes especificas, ou necessidade de alteracao nas adicoes de novos nodes a
# rede. Por: Eduardo Frazao — edufrazao@gmail.com
###############

# Diretorio de configuracao base.
# Esta e a unica configuracao que precisa ser realizada neste arquivo
# Configure de acordo com a localizacao dos arquivos de configuracao da rede
BASE_CONFIG_DIR=”/etc/tinc/vpn”

## Antes de Inicializar o script, detectando acao solcitada

case $1 in

start)
ACTION=”start”
;;
stop)
ACTION=”stop”
;;
*)
echo “Parametros necessarios: Start ou Stop”
exit 1
esac

# Verificando se a interface foi informada
if [ “$2” = “” ]; then
echo “Interface do Tunel Nao informada”
exit 1
else
INTERFACE=$2
fi;

# Minha Rede
MY_NAME=$(grep Name $BASE_CONFIG_DIR/tinc.conf | cut -d “=” -f 2)
# IP na Interface do tunel
TUN_IP=$(/sbin/ifconfig $INTERFACE | grep “inet addr” | cut -d “:” -f 2 | cut -d ” ” -f 1)

# Configurando rotas para os arquivos clientes, exceto o local
for nets in $(grep Subnet $BASE_CONFIG_DIR/hosts/* | grep -v $MY_NAME | cut -d “=” -f 2);
do
if [ “$ACTION” = start ]; then
ip route add from any to $nets via $TUN_IP dev $INTERFACE
else
ip route delete from any to $nets
fi;
done;
###################

Agora, torne os scripts executáveis:
# chmod +x tinc-up tinc-down tinc-routes

Pronto. Desta forma, finalizamos os arquivos de configuração. Observe que montei estes scripts apenas com a intenção de facilitar a manutenção das rotas, e o crescimento da rede. Não sou muito bom com scripts bash. Entenda que basicamente, o sistema invoca tinc-up e tinc-down, e você pode trabalhar esses arquivos da forma que achar mais conveniente para refinar as configurações de rede necessárias a seu ambiente. O Tinc também pode invocar scripts por clientes (quando se conectam), verifique man tinc.conf para mais detalhes.

Pronto. Antes de continuar, apenas uma nota sobre o parâmetro ConnectTo do arquivo tinc.conf: Este parâmetro, indica em quais redes os daemons devem ser conectar inicialmente. Mesmo que o trafego dos dados seja descentralizado, os daemons fazem conexões iniciais em hosts preestabelecidos. Assim que conseguem realizar uma conexão, eles passam a poder receber conexões de outros daemons da rede. Todavia, como vocês devem ter notado, é possível passar mais de um host para a conexão incial. E pode ser qualquer host da Rede. Isso não fará com que o trafego da rede acabe passando por este host indicado. Isso só aconteceria, se fosse impossível que a rede que está tentendo se comunicar, pudesse falar com seu destino, e por acaso, o host estabelecido em ConnectTo conseguisse. Sempre que possível, o Tinc tentará estabelecer uma conexão direta com o firewall de destino. Dessa forma, você pode eleger alguns hosts na rede, para serem configurados no ConnectTo dos outros clientes, e assim, manter uma redundancia desses valores. A NetworkA, é a única que não precisa deste parâmetro. É como se fosse um pseudo-server da rede, apenas aceitando conexões.

Finanlizando a configuração do Tinc: Agora, já temos todas as chaves prontas, e as configurações são apenas as realizadas acima. Claro que existem mais parâmetros que podem ser configurados (man tinc.conf). Isso depende de cada necessidade, porém, para nosso modelo já basta. O que precisamos fazer agora, é copiar as chaves publicas de todos os hosts uns para os outros. Ou seja, copiar hosts/NetworkA, para dentro do diretorio hosts do servidor de Network B e C. E vice-versa em todos.

Depois de feito isso, o Tinc já terá o conhecimento de onde fica cada rede, e a chave pública para se conectar a cada uma delas.

Usando este modelo descentralizado, teremos uma VPN como neste diagrama:

Feito isto, finalizamos as configurações. Considere as questões de firewall, para permitir as conexões dos daemons entre si, e também as passasges dos pacotes de uma rede para outra. Por padrão, o Tinc utiliza a porta 655 em TCP para estabelecer suas conexões (handshake TLS), e a porta 655 em UDP para transmitir os dados, ou seja, libere os dois protocolos para esta porta.

——————–

Espero que este artigo te ajude de alguma maneira. Quem quiser, pode postar comentários, ou entrar em contato por email!

Um abraço,

Eduardo Frazão / edufrazao – at – gmail.com

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:

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.

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:

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