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:

ou:

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:

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:

Depois de criar os dois scripts, transforme-os em executáveis usando o comando “chmod +x”, como em:

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:

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:

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:

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:

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:

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

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:

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

:. Leia mais sobre servidores Linux