Um guia para os iniciantes no mundo do
FreeBSD
Implantando VPNs com FreeBSD
- Acesso Remoto
Se você está com pressa e
não quer blablabla
clique aqui.
Rapidinho:
Não culpem o Edson por
esta área, ok ? Esta é de
minha autoria
(Capriotti).
Peço que possíveis dúvidas sejam
endereçadas à lista de discussão do FreeBSD
(FUG Brasil), conforme instruções nas
páginas anteriores
. É mais saudável porque eu não
sou um poço de sabedoria, e, compartilhando o problema,
freqüentemente compartilha-se a solução também.
A presente estratégia pode muito
bem ser utilizada para a conexão de redes inteiras,
tendo o mesmo resultado final que a conexão feita pelo
IPSec (as redes se falam e existe criptografia).
Porém ela é a preferida
para a conexão de estações remotas por ser
100% compatível com os clientes Microsoft.
Outro possível uso deste método
é a conexão de uma rede inteira onde o servidor
do outro lado (ISP ou matriz) não use o IPSec, mas sim o
estratagema mais simples de VPN.
O IPSec é muito mais seguro que o PPTP. Veja o
artigo da ZDNet
a respeito.
Para os mais afoitos: a fragilidade atual da implementação
do PPTP é ele ser baseado em pares username-senha,
que pode fragilizar o sistema devido a falha humana. Porém,
pelo que andei lendo, a implementação do PPTP com MPD
é bem mais confiável, com recursos que excedem a segurança
do padrão Microsoft.
O que eu preciso ?
Conhecimento médio/avançado de FreeBSD.
FreeBSD 4.4 #20 (build 20) ou superior; Esta é a minha plataforma,
onde tudo foi testado.
O port mpd-netgraph, também conhecido como
MPD.
Até a data deste artigo, a
versão corrente é a 3.6.
Pegue o arquivo via FTP em
ftp://ftp.freebsd.org/pub/FreeBSD/branches/4.0-stable/packages/All/mpd-3.6.tgz
ou utilize o comando
pkg_add ftp://ftp.freebsd.org/pub/FreeBSD/branches/4.0-stable/packages/All/mpd-3.6.tgz
Como o MPD funciona
O MPD é na verdade um programa
muito mais completo e complexo do que simplesmente um
daemon para VPN; Ele é
um daemon PPP
com suporte a multi-link, podendo ser utilizado como client e server
ao mesmo tempo. Potencialmente você poderia fazer a conexão
entre servidores com ele, ao mesmo tempo que serve de gateway para
seus usuários remotos, com o mesmo programa.
Funciona com modems, links tradicionais,
DSL, etc.
Mas nosso escopo é apenas
permitir o acesso de clientes - tipicamente utilizando acesso
de banda larga - ao um determinado servidor, para coloca-los em
contato com uma rede interna.
Para o estudo do caso vamos criar
a seguinte situação (antes de se efetuar a conexão
VPN):
Dados importantes
Servidor
IP Externo: 64.136.12.132
IP Interno: 192.168.1.10
Mascara de
rede interna: 255.255.255.0
Rede interna da compania ACME Computing
- ou Tabajara Comunicações, conforme o gosto.
192.168.1.x
Estação remota
IP Externo:
200.206.14.13
O MPD fica escutando o IP
externo (e não a interface), na porta 1723 (PPTP), esperando
por conexões. No momento que a primeira conexão VPN
é requisitada pelo cliente 200.206.14.13, uma interface virtual
é ativada- com o nome de ng0
, geralmente - com um endereço IP da rede interna.
Este conexão é o túnel do "Tunneling
Protocol"; A negociação de IPs, compactação
e criptografia vem logo a seguir.
Depois de bem-sucedida a negociação,
o servidor passa a ter dois endereços IPs internos, em
duas interfaces internas.
onde 192.168.1.10 continua sendo a interface interna
física, real, e 192,168.1.11 (IP à nossa escolha)
é a interface virtual ng0 (netgraph), que será
responsável pela comunicação entre o servidor
e a estação.
Cada nova conexão VPN (ou PPTP, para ser mais tecnicamente
fiel) requisitada cria uma nova interface ngX. Portanto,
um novo túnel.
Após a conexão, a
estação de trabalho deverá ter a seguinte
"aparência":
Em se tratando de Windows,
essa informação pode ser vista digitando-se o seguinte
comando em uma janela de DOS PROMPT:
ipconfig
O resultado deverá ser
algo como:
Para os mais atentos: a máscara
de subrede do adaptador VPN é 255.255.255.255
Muito estranho, mas funciona
perfeitamente. Parece que há alguma "encrenca" pois o
PPP, por RFC, não tem como passar a máscara de
subrede para a estação. Porém, no lado do
servidor fica tudo claro e a comunicação não
é prejudicada.
Da mesma maneira, o Windows,
em geral, parece ficar muito feliz e satisfeito em ter o IP de
gateway idêntico ao seu próprio IP (192.168.1.110
neste caso). Novamente, simplesmente
funciona .
Chega um determinado momento
em nossas carreiras onde nós deixamos de questionar as
inconsistências da Microsoft. Passamos apenas a lamenta-las
e conviver pacificamente com elas...
Arquivos de configuração
Após instalar
o MPD
vamos ao que interessa:
a configuração do servidor.
Crie o arquivo mpd.sh no seu
/usr/local/etc/rc.d
para fazer com que seu MPD
esteja sempre rodando no momento do boot. Segue o conteúdo
do arquivo:
#! /bin/sh
pidf=/var/run/mpd.pid
case "$1" in
start|"") mpd -b;;
stop) if [ -r $pidf ]; then
kill -TERM `cat $pidf`
fi;;
*) echo "usage: $0 [start|stop]"
1>&2; exit 1;;
esac
echo -n ' MPD'
O MPD funciona basicamente com
três arquivos de configuração:
/usr/local/etc/mpd/mpd.conf
/usr/local/etc/mpd/mpd.links
/usr/local/etc/mpd/mpd.secret
Existe um
/usr/local/etc/mpd/mpd.script
que é opcional.
Para aqueles habituados com
o bom PPP Userland - ou simplesmente PPP - a organização
destes arquivos não vai ser nenhuma novidade; O MPD foi
baseado no PPP original.
mpd.conf
Tem a seguinte estrutura:
#
default:
load pptp0
pptp0:
new
-i ng0 pptp0 pptp0
set
bundle disable multilink
set
ipcp ranges 192.168.1.11/32 192.168.1.0/24
# Define o endereço do servidor (interface
#
virtual ng0)
# como sendo 192.168.1.11 e os IP
#
disponíveis para os clientes como
# estando
no intervalo 192.168.1.1 até
#
192.168.1.254 (definido pela máscara
#
de rede)
set
iface enable proxy-arp
# Permite
que todos os usuários de
#
netbios-over-TCPIP enxerguem-se
#
no "ambiente de rede" - não testei
set
iface route 192.168.1.11/24
# Definir o IP que
irá fazer a "ponte" para
#
os pacotes entre estação de trabalho e
#
o servidor - Gateway
#
Definir aqui também a máscara de rede a
#
ser usada pelas estações
set
ipcp dns IP_DE_SEU_SERVIDOR_DE_DNS
# Qualquer
DNS - use sempre o de resposta
#
mais rápida
set
ipcp nbns IP_DO_SERVIDOR_WINS_OU_SAMBA
# comente esta linha caso não
tenha esse
# serviço
set
link deny pap chap
# não aceita senhas não criptografadas
set
link enable chap
# Habilitar as duas próximas linhas
para Clientes NT
# set link
enable no-orig-auth
# set link keep-alive 10
75
set
ipcp enable vjcomp
# Habilita compressão Van Jacobson
# Suporte à criptografia MPPE com ng_mppc(8)...
set
bundle enable compression
set
ccp yes mppc
set
ccp yes mpp-e40
# aceita criptografia com chave de 40 bit
set ccp
yes mpp-e128
# Aceita criptografia de 128 bits
set ccp
yes mpp-stateless
Este exemplo permite que apenas UMA
conexão VPN seja feita com o servidor;
Este link
mostra um arquivo de configuração
sem os comentários, para até 7 conexões
simultâneas.
Apenas algumas linhas mudam:
O rótulo
pptpX
E a linha
new -i ngX pptpX pptpX
Onde X vai ser substituído
pelo número da conexão.
Na prática, cada usuário
simultâneo da VPN deverá ter um bloco como o acima.
Novamente, veja o arquivo de configuração-exemplo
.
mpd.links
Esse arquivo, como o anterior,
precisa ter um bloco de definições para cada usuário
VPN que se pretende ter. Porém suas linhas são sempre
as mesmas, modificando apenas o rótulo.
pptp0:
set link type pptp
set pptp self 64.136.12.132
# IP Externo que responderá pela VPN
# - porta PPTP ou 1723
set pptp enable incoming
set pptp disable originate
Novamente, crie um rótulo
(label) pptpX para
cada possível conexão VPN.
Aqui
está o exemplo do
mpd.links
mpd.secret
Este arquivo contém
o nome dos usuários, e suas respectivas senhas, porém,
pode ter uma funcionalidade a mais. Veja a estrutura dele:
aleixo
senha1 192.168.1.112
nichols
senha2 192.168.1.113
mana
senha3 192.168.1.111
carlos
senha4 192.168.1.110
marcel
senha5 192.168.1.114
leonardo
senha6 192.168.1.115
paul
senha7 192.168.1.116
A primeira e segunda colunas são
óbvias, mas a terceira é muito interessante;
Ela define qual o endereço IP
interno cada usuário terá.
Isto é um recurso
muito útil para quem quer controlar exatamente o que seus
usuários estão fazendo, e também para verificar
possíveis falhas de segurança (um usuário
que tenha dado sua senha para outra pessoa, etc).
Dois outros casos:
ernesto senha9
Neste caso, não é especificado
nenhum endereço em particular. Qualquer endereço disponibilizado
pela configuração em mpd.conf será aceito.
francisco
Já aqui o usuário
francisco pode inclusive definir o sue próprio IP, na hora
da conexão. IPs válidos serão de
192.168.1.128 a 192.168.1.255.
Note que os usuários
cadastrados neste arquivo NÃO NECESSARIAMENTE estão
cadastrados como usuários de seu servidor. Portanto, não
necessariamente tenham direito a acesso ftp, área "home",
ou direito a shell, ou mesmo acesso ao Samba. E isso, em termos de
segurança é muito bom.
Calro que cria um problema a mais, pois
exige que o usuário tenha um par a mais de username e
senha para poder autenticar seu acesso à serviços
de rede, fora a própria VPN.
Há maneiras de se fazer com que
o próprio sistema autentique os usuários, quando
estes estiverem na base de dados do servidor - passwd - mas
este caso não foi abordado aqui.
Lembre de fazer este
arquivo como SOMENTE
PARA LEITURA PELO ROOT !
mpd.script
Particularmente não cheguei
a utilizar este arquivo, mesmo porque ele não é
necessário para o funcionamento da VPN, mas pode ser útil
para aqueles que quiserem executar comandos para cada conexão
específica. Usado para chat commands
de modems.
NATd e gateway
A comunicação entre
os computadores da VPN não requer o NAT, pois ela vai estar
usando a "mesma" interface ngX.
Porém, certifique-se de que
você tem o
gateway_enable = "yes"
no seu arquivo /etc/rc.conf
Firewall
Se você usa um filtro
de pacotes como o IPFW, provavelmente vai precisar atualizar suas
regras de filtragem para deixar passar o tráfego da VPN.
Normalmente as seguintes
regras são o suficiente:
${fwcmd}
add allow tcp from any to SEU_IP_EXTERNO 1723
${fwcmd} add allow tcp from SEU_IP_EXTERNO
1723 to any
${fwcmd} add allow gre from SEU_IP_EXTERNO
to any
${fwcmd} add allow gre from any to SEU_IP_EXTERNO
porém, suas regras
de firewall - assim como as minhas - podem impedir o tráfego
de redes 192.168.x.y.
Neste caso é possível que as seguintes regras
resolvam o problema:
ipfw add 300 allow ip from any to 192.168.1.0/24
via INTERFACE_INTERNA
ipfw add 400 allow ip from 192.168.1.0/24 to any via
INTERFACE_INTERNA
Mas, cuidado !!!!! Antes
de adicionar qualquer regra em seu firewall, verifique se elas não
abrirão brechas ou invalidarão outras regras de filtragem
!
Por exemplo: o tráfego de endereços 192.168.x.y,
10.z.y.z e 172.x.y.z é terminantemente proibido em interfaces
externas, por serem IPs de classes reservadas (só para redes
internas). Todo filtro de pacotes que se preza tem regras de filtragem
para barrar esse tipo de pacotes vindo da rede externa, ou indo para
a rede externa. O /etc/rc.firewall tem exemplos muito
bons a esse respeito.
Mais segurança
Administradores de rede,
ATENÇÃO !
Os clientes logados em sua nova VPN têm
que ter regras de firewal válidas.
Explico: em meu caso particular, minha rede
interna é 10.249.60.x, mas os clientes de VPN recebem
um IP da classe 192.168.1.x. Com isso sei exatamente de onde vem
determinado tráfego, de maneira rápida. Sem
nenhuma regra especial, os usuários em 192.168.1.x podem
acessar/pingar/etc livremente as estações em 10.249.60.x.
O fato de estarem em uma rede "separada" torna muito
mais fácil criar um conjunto de regras de firewall para limitar/administrar
as atividades apenas desse grupo seleto de usuários.
Por outro lado, se você esquecer de
definir regras específicas, muito provavelmente estará
deixando o tráfego deles sem nenhuma filtragem, o que pode
ser particularmente perigoso.
Eu sempre sigo a seguinte regra:
segurança nunca é demais.
Pontos não muito favoráveis e
BUGS
1) Se for utilizada a política
de IPs fixos para cada usuário, e duas conexões
forem feitas com o mesmo username e password, o resultado será
DUAS CONEXÕES COM O MESMO IP.
2) Enquanto as conexões
VPN estiverem ativas, qualquer navegação que seu
usuário faça (HTTP, FTP, POP, SMTP, portscans, etc)
estarão utilizando seu link como default gateway, a menos
que seja alterado no lado do CLIENTE.
3) Existe um possível
conflito entre o FreeBSD 4.4-Stable de Agosto-Setembro de 2001 e o PPPoE
do PPP Userland com o MPD; Vi um caso onde, quando um usuário
desconectava da VPN, toda a rede interna - física - perdia acesso
ao servidor, embora netstat -in mostrasse a interface
interna ativa. Um simples cvsup com recompilação
do sistema resolveu o caso.
4) Estamos mantendo os olhos abertos para configurações
com o FreeBSD 4.5; Existe pelo menos um caso onde, mesmo estando presente
no ps ax e ouvindo a porta PPTP, o MPD não responde
aos chamados dos clientes. Invocando o processo manualmente, com o
mpd -b na linha de comando, faz tudo funcionar. Se você
teve um caso parecido,
reporte para a lista
.
Debug de conexões
Lembre que para iniciar o programa manualmente deve-se utilizar
/usr/local/etc/rc.d/mpd.sh start
e para finalizar prefira estas duas manieras:
/usr/local/etc/rc.d/mpd.sh stop
ou
executar o mpd -k que força o modo interativo, e então
digitar o comando quit.
Ao executar o comando
mpd -k
você mata o daemon do
MPD e passa automaticamente a executa-lo no console. A vantagem
é que você pode ver as mensagens de cada cliente ao
se conectar.
Alternativamente pode-se inicializar
o MPD com o comando
mpd -c
NUMERO_DE_PORTA
O daemon
inicializará em background
, mas ao se executar telnet
NUMERO_DE_PORTA você
terá acesso ao MPD como se o estivesse executando em modo
iterativo (podendo executar comandos manualmente).
Porém essa é
uma estratégia arriscada - buraco
de segurança !!! - por deixar uma
porta de comunicação aberta no seu sistema. Potencialmente
qualquer um pode dar um telnet em qualquer porta do seu servidor,
especialmente se ele for público.
Configuração
dos clientes
Atenção ! Clientes
mais antigos de rede Dial-Up podem não ter a criptografia
de 128 bits. Atualizar o cliente, caso necessário.
Para saber o nível de criptografia
sendo utilizado no lado do servidor, verificar as mensagens de
conexão utilizando o comando
mpd -k .
Em geral, a configuração
default dos clientes
Microsoft funciona, mas aqui vai como eu deixei os clientes, apenas
como base de comparação:
Windows 98
Windows 2000
Créditos e agradecimentos
O MPD é um programa desenvolvido por
Archie Cobbs
, que tem um pequeno resumo no
servidor do FreeBSD
.
Estive em contato muito freqüente com ele, e este se mostrou
extremamente aberto ao diálogo. Isso não significa alterações
imediatas ao programa, mas significa um suporte fenomenal. Deixo a ele
meu agradecimento.
E agradeço também às almas corajosas que, baseados
em minha experiência, acreditaram nas minhas instruções
e implantaram este sistema.
Com suas perguntas, dúvidas e questionamentos eu atualizei o
tutorial, fazendo-o mais abrangente e fiel.
É assim que a comunidade cresce, minha gente.
[]s
Capriotti
Se você possui alguma critica , duvida ou sugestão
,entre em contato pelo e-mail:
edson.brandi@uol.com.br