Versão Imprimível
galera, tenho um servidor com conectiva 10 que faz NAT na minha rede, só que os clientes conectados nesse NAT nao conseguem conectar em VPN, da erro 619 no Windows.
nao é problema no cliente pq com NAT em FreeBSD todos fazem a conexao normal.
eu acho que ta faltando carregar algum modulo do kernel para ele fazer forward do protocolo 47 (GRE) ou alguma coisa do tipo...
no firewall nao tem nenhuma regra, só as de mascaramento mesmo.
alguem tem uma dica aí?
falou
8)
Caro,
Neste caso recomendo que vc use o Debian, que vem com suporte ao GRE nativo.
Sem Mais,
como estao as regras do iptables?
tenho que usar o conectiva 10 por uma questão de padronização.
as regras do iptables são:
iptables -t nat -A POSTROUTING -p TCP -j MASQUERADE --to-ports 1024-31000
iptables -t nat -A POSTROUTING -j MASQUERADE
falou
8)
1) As estaçoes ATRAS do NAT querem acessar um servidor VPN FORA, ou é estação FORA querendo acessar um servidor DENTRO da tua rede??Citação:
Postado originalmente por Patrick
2) Tu só tá nateando? e o FORWARD?
3) Não precisa dessa primeira linha para o NAT, pois a segunda é mais abrangente.
Como você mesmo disse, se não tem nenhuma regra, apenas as de mascaramento, você vai precisar de FORWARD para liberar a passagem de trafego.
As estaçoes ATRAS do NAT querem acessar um servidor VPN FORA...
mas a politica do forward é ACCEPT, vai passar qualquer coisa que o cliente tentar (pelo menos deveria...).
ou nao é bem assim da forma que eu to pensando?
obs.: esta sem regras apenas para testes, depois eu vou colocar as regras com DROP.
falou
8)
Vai ver o kernel do coconectiva não tem suporte ao protocolo GRE. Se tá do jeito que tá, e /proc/sys/net/ipv4/ip_forward tá '1', acho que o jeito vai ser recompilar o kernel habilitando as opções do protocolo GRE.
tenta:
iptables -t nat -I POSTROUTING -p GRE -j MASQUERADE
tem suporte sim, só que ta como modulo.Citação:
Postado originalmente por Avenger
nao sei qual é o nome do modulo a ser carregado, eu tentei "ip_gre" e "ppp_generic" mas nao deu certo...
nao tenho certeza, mas acho que sao esses modulos:
<M> IP: tunneling
<M> IP: GRE tunnels over IP
alguem sabe como carrega-los?
DropALL, na segunda eu vou tentar adicionar essa regra, mas nao acho que seja isso, pois já tem uma regra de mascaramento para todos os protocolos, (iptables -t nat -A POSTROUTING -j MASQUERADE) mas de qualquer forma tentarei...
falou
8)
dando:
lsmod
Aparece o ip_gre ??
se não, tenta:
modprobe ip_gre
:P
aparece sim... :good:Citação:
Postado originalmente por DropALL
DropALL, como eu imaginava a regra que voce disse nao deu certo...
olhem o que aparece no conntrack para o servidor de VPN
[root@teste root]# cat /proc/net/ip_conntrack | grep 200.x.x.11
unknown 47 72 src=200.x.x.11 dst=200.x.x.12 [UNREPLIED] src=200.x.x.12 dst=200.x.x.11 use=1
o ip com final 12 é a minha maquina de teste com conectiva 10, o com final 11 é o servidor de VPN...
como eu tava dizendo a minha suspeita é que o kernel nao ta com suporte a forward do GRE, acho que tem que ativar algum modulo, mas nao sei qual...
falou
8)
usa o pptpproxy para fazer o tunel, por padrão no conectiva não funciona o tunelamento da vpn.
Baixa aqui: http://drginfo.no-ip.com/aplic-lin.h...roxy/pptpproxy
e baixa a biblioteca que ele vai rclamar: http://drginfo.no-ip.com/aplic-lin.h...443cl.i386.rpm
Depois roda o pptpproxy com as opcões como:
pptpproxy -p ip-do-servidor:1723,ip-do-velox-ou-ip-valido:1723 -l /var/log/ppptpproxy.log
Espero que te ajude.
drginfo, conheço esse pptpproxy, mas queria resolver sem ter que usa-lo...
quer dizer entao que para resolver isso só recompilando o kernel no conectiva?
falou
8)
Cara pelo pouco que já vi de VPN, o conectiva é o mais fraco, falta suporte de um montão de coisas, muita gente usa slackware ou debian. No teu caso vai ser melhor usar o pptpproxy, pois acho que nem compilando o kernel vai funcionar.
o grande problema do pptpproxy é que eu nao sei quem vai usar VPN na rede, sao clientes que eu nao tenho o controle.
vou tentar recompilar aqui, se mesmo assim nao der certo vou tentar com slackware pra ver...
valeu pela ajuda e opnião de todos! :good:
ainda estou aberto para qualquer tipo de sujestão.
falou
8)
Engraçado que como até LRP (bhering) faz esse tipo de coisa e o conectiva nao faça, heim. Mas não parece ser 'tunel' que você queira, mas apenas fazer um forward do pacote... Tenta ao inves de usar -p GRE, fazer -p <numero_do_protocolo> mas, de acordo com o man do iptables se vc fizer '-p 0' (ou omitir o -p) ele vai bater para todos os protocolos. Então certifique-se de, ao invés de ter uma regra de masquerade só prá tcp e udp, que vc tenha uma regra de masquerade sem especificar o protocolo. É de certa forma estranho o iptables ter que saber qual é o protocolo (se ele já está sob tcp). Daqui simplesmente um 'dito -p 0' já faz mascaramento e forward tanto do protocolo gre (parece que 47) quanto do tunel ipv6 (41) sem problemas.
Outra coisa, se você olhar as opções do kernel (aquelas que mostrou com um <M> nelas), e ir na opção <HELP>, talvez no finalzinho da descrição do ítem tenha o nome do módulo .o correspondente.
Avenger, realmente a regra de mascaramento que eu to usando sao para todos os protocolos, tentei tb colocar uma regra -p 47 (que seria o GRE) mas tb nao deu certo.
vou dar uma olhada no help do kernel para ver se acho alguma coisa.
alguem sabe qual é o diretorio onde ficam os modulos do kernel que podem ser carregados?
falou
8)
Código :
O $(uname -r) preenche automagicamente com a versão corrente do kernel caso você tenha várias versões instaladas. :)
se for freeswan não funciona com nat.