Upload
tranminh
View
230
Download
0
Embed Size (px)
Citation preview
Configuração da VPN em FreeBSD
S.S. – Doc’s Página 1 de 14
S.S Doc’s
Sérgio Sousa Documentação
Redes Informáticas
Um guia para os iniciantes no mundo do FreeBSD Implantando VPNs com FreeBSD - Acesso Remoto
Configuração de VPN em FreeBSD
Configuração da VPN em FreeBSD
S.S. – Doc’s Página 2 de 14
Configuração da VPN em FreeBSD
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
Configuração da VPN em FreeBSD
S.S. – Doc’s Página 3 de 14
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
Configuração da VPN em FreeBSD
S.S. – Doc’s Página 4 de 14
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":
Configuração da VPN em FreeBSD
S.S. – Doc’s Página 5 de 14
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.
Configuração da VPN em FreeBSD
S.S. – Doc’s Página 6 de 14
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
Configuração da VPN em FreeBSD
S.S. – Doc’s Página 7 de 14
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
Configuração da VPN em FreeBSD
S.S. – Doc’s Página 8 de 14
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
Configuração da VPN em FreeBSD
S.S. – Doc’s Página 9 de 14
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 senha10 192.168.1.128/25
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.
Configuração da VPN em FreeBSD
S.S. – Doc’s Página 10 de 14
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.
Configuração da VPN em FreeBSD
S.S. – Doc’s Página 11 de 14
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
Configuração da VPN em FreeBSD
S.S. – Doc’s Página 12 de 14
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
Configuração da VPN em FreeBSD
S.S. – Doc’s Página 13 de 14
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
Configuração da VPN em FreeBSD
S.S. – Doc’s Página 14 de 14
Windows 2000