blank blank

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:

m1e3fcab0

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
persist­key
persist­tun
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
persist­key
persist­tun
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.

:. Leia mais sobre servidores Linux

Sobre o Autor

Redes Sociais:

Deixe seu comentário