POSTROUTING [RESOLVIDO]

1. POSTROUTING [RESOLVIDO]

Perfil removido
removido

(usa Nenhuma)

Enviado em 04/09/2010 - 20:55h

Galera tenho uma dúvida, sou novo aqui...


preciso redirecionar todo o trafego da rede para o servidor, por exemplo qualquer um que tentar a acessar a net será redirecionado para o servidor, a regra é essa

#iptables -t nat -A PREROUTING -s 10.125.123.0/24 -p tcp --dport 80 -j DNAT --to 10.125.123.1:80

Assim quem tentar navegar na rede será redirecionado e não vai fazer NAT.

Porém, se eu precisar liberar um ip como

#iptables -t nat -I POSTROUTING -s 10.125.123.50 -j MASQUERADE

ele(ip 10.125.123.50) continua sendo redirecionado para o servidor!
Qual comando falta aí pra rolar com ips que quero liberar?!

Help me!



  


2. MELHOR RESPOSTA

Guilherme Domingues de Oliveira
korvoman

(usa Debian)

Enviado em 09/09/2010 - 15:13h

Parabéns pelo seu esforço.

Como sugestão, publique o seu projeto sob um o formato de artigo aqui no vol. Expondo o projeto e os procedimentos para a instalação. Isto será de grande auxilio para a comunidade.

Abraço


3. Re: POSTROUTING [RESOLVIDO]

Guilherme Domingues de Oliveira
korvoman

(usa Debian)

Enviado em 04/09/2010 - 21:39h

boa pedida seria squid para este controle...

Toda regra de maior abrangencia no inicio de seu firewall é aplicável para todas as seguintes. por esta razao esta ocorrendo esta "falha". Sendo ainda uma tabela PREROUTING.

Não sei qual a sua necessidade de forma completa, ou estrutura. mas te proponho desta forma:

(Configura a politica de repasse como DROP)
iptables -P FORWARD DROP

(libera ip para todos os aplicativos de rede)
iptables -A FORWARD -s ip_liberado -j ACCEPT

(libera ip para acesso a msn)
iptables -A FORWARD -p tcp --dport 1863 -s ip_msn_liberado -j ACCEPT

(Deixa mascarar rede interna por completo para aplicativos ou ips que permitiram fazer "repasse"(FORWARD) de pacotes )
iptables -t nat -A POSTROUTING -s rede_interna -j MASQUERADE


Conheça a foca linux a respeito da teoria do iptables.

http://focalinux.cipsga.org.br/guia/avancado/ch-fw-iptables.htm


4. Re: POSTROUTING [RESOLVIDO]

Perfil removido
removido

(usa Nenhuma)

Enviado em 04/09/2010 - 23:20h

Vou te falar como é o lance aqui....

No meu trampo aqui nós temos uma massa meio pesada que usa a rede sem fio, fornecedores, clientes hospedes principalmente.

Daí a regra seria para todo mundo ter que passar pela autenticação de forma prática, então criei uma autenticação que executa os comandos que eu precisar(caso haja sucesso na autenticação), fiz em php....

Esse é o proposito, usar um redirecionamento pra levar todos pra pág de autnticação, após isso, o ip deve fluir totalmente.

Brigadão, valeu a dica... vou sacar o site lá que vc apontou!

Abraços!




5. Re: POSTROUTING [RESOLVIDO]

Guilherme Domingues de Oliveira
korvoman

(usa Debian)

Enviado em 05/09/2010 - 08:52h

Há esta opção já pronta. em que seria o captive portal. nao tive oportunidade de testar ainda :
http://en.wikipedia.org/wiki/Captive_portal


6. Re: POSTROUTING [RESOLVIDO]

kleber galucio
klebrr

(usa Linux Mint)

Enviado em 05/09/2010 - 10:53h

obs: as maquinas clientes tem gateway definido? tipo
cliente1
ip 10.125.123.80
mask 255.255.255.0
gw: 10.125.123.1 <---- supõe-se que seja o ip do servidor squid????

o squid está escutando na porta 80? o padrão é 3128.
---
se for assim a config correta do servidor seria abaixo
placa interna: digamos ETH0
IP: 10.125.128.1
mask: 255.255.255.0
sem gateway

placa externa (internet) ETH1
ip: 10.5.2.3 geralmente não uso o memso ip da rede interna
mask:255.255.255.0
gw: 10.5.2.1 <- ip do roteador para internet...

ai sim aplica-se a regra do firewall:
#iptables -t nat -A PREROUTING -i eth0 -s 10.125.123.0/24 -p tcp --dport 80 -j DNAT --to 10.125.123.1:80

#iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

* verificar se o squid esta na porta 80
netstat -ptln |grep squid

* squid versão até 2.7 não autentica utilizando redirecionamento, tem que colocar proxy manual nos navegadores dos clientes.


7. Re: POSTROUTING [RESOLVIDO]

Perfil removido
removido

(usa Nenhuma)

Enviado em 05/09/2010 - 12:01h

Mas não uso squid pra clientes, apenas para rede adm. Autenticação que eu crei foi no braço mesmo, em banco postgre, onde para hóspede o user é numero do apartamento.

No proxy aqui roda tudo redondinho, mas nessa parada ainda não ta de boa, vou sacar o site do ultimo post do korvoman(ja vi que é interessante, merece agradecimentos especiais). Acredito que exitem outras formas para esse objetivo, mas o interessante é deixar uma coisa organizada e com uma boa visão no olhar dos clientes, e tenho certeza que é possível!

Abraços, valeu a dica galera!
Brigadão!


8. Testando ; )

Perfil removido
removido

(usa Nenhuma)

Enviado em 06/09/2010 - 22:43h

Galera me tirem uma dúvida....

Não tive sucesso na instalação dos pacotes prontos para Captive Portal(devido a outras aplicações que rodam em meu servidor), porém fiz uma tentativa com sucesso, não tenho certeza se isso cai bem na visão de performance do iptables, mas vou explicar aqui... me desculpem a ignorancia

como tinha dito antes, se usar toda a rede em PREROUTING assim:

#iptables -t nat -A PREROUTING -s 10.125.123.0/24 -p tcp....

toda a rede fica em PREROUTING mesmo que depois faça um POSTROUTING num ip pra liberar, então tentei assim....


criei um script(psql) que da um select no postgre e inseri os dados em um arquivo que por sua vez é executado logo em seguida o qual executa os comandos do iptables pra mim, esse comando coloca ip por ip da rede /24 em modo PREROUTING, quando o usuario autentica com sucesso um php poe o campo da tabela com ip dele em POSTROUTING o script que executa a cada um minuto com o select exporta=>executa e rola normal perfeitamente, criei também um script que depois de um tempo 4h(tempo de vida da credencial liberada) atualiza o campo novamente para PREROUTING no ip liberado anteriormente, claro que para fazer isso ip por ip tb desenvolvi o script pra me auxiliar a inserir rapidinho e não preciso mais fazer outra vez, tendo em vista que ficou automatizado... a dúvida é seguinte...

será que o fato de estar no iptables ip por ip, como assim:

#iptables -t nat -A PREROUTING -s 10.125.123.10 -p tcp -j DNAT --to 10.125.123.1:80

#iptables -t nat -A PREROUTING -s 10.125.123.11 -p tcp --dport 80 -j DNAT --to 10.125.123.1:80

#iptables -t nat -A PREROUTING -s 10.125.123.12 -p tcp --dport 80 -j DNAT --to 10.125.123.1:80

segue até o 254

#iptables -t nat -A PREROUTING -s 10.125.123.254 -p tcp --dport 80 -j DNAT --to 10.125.123.1:80

e não assim(pois pra mim deu gato preto):

iptables -t nat -A PREROUTING -s 10.125.123.0/24 -p tcp --dport 80 DNAT --to 10.125.123.1:80

pode causar problemas de performance no iptables, ou ser uma medida burra e sem critério nenhum!? ou isso é teóricamente a mesma coisa de usar 10.125.123/24?

mais uma vez desculpem a ignorancia, mas fórum é para tirar dúvidas com galera mais experiente mesmo ;) ainda sou um criança nessa coisa infinita!

Abraços!!!







9. Re: POSTROUTING [RESOLVIDO]

Guilherme Domingues de Oliveira
korvoman

(usa Debian)

Enviado em 06/09/2010 - 23:00h

Para cada ip liberado, poderia colocar a regra de exceção:

iptables -t nat -I PREROUTING ! -s ip -p tcp --dport 80 -j DNAT --to 10.125.123.1:80
e a regra para POSTROUTING

E sendo a ultima regra definitiva.
iptables -t nat -A PREROUTING -s 10.125.123.0/24 -p tcp --dport 80 -j DNAT --to 10.125.123.1:80

Teste e nos retorne






10. Enfim, deu certo!

Perfil removido
removido

(usa Nenhuma)

Enviado em 09/09/2010 - 15:00h

Galera resolvi aqui!

Usei multiplas ferramentas para tal, como:
Postgres(autenticação, inclusão e exclusão dos comandos)
PHP5 (para manipular string no banco)
Apache2(claro, preciso de um servidor Web para manter vivo o portal hehehe)


Agora funciona assim
Criei tabelas no database para autenticação(simples comparação entre valor da variavel e valor do campo 'senha')
Inseri o comando iptables -t nat -A PREROUTING -s rede_local_clientes/24 -p tcp --dport 80 -j DNAT --to ip_servidor:80 e outro, iptables -A FORWARD -s rede_local_clientes/24 -j DROP no banco no campo PREROUTING e FORWARD_DROP, respectivamente, no php se houver sucesso na autenticação, altera alguns outros campos da tabelas com o valores que descrevo a seguir:

campo POSTROUTING
iptables -t nat -I POSTROUTING -s ip_do_cliente -j MASQUERADE --> para liberar o nat ao ip_do_cliente

campo FORWARD
iptables -I FORWARD -s ip_do_cliente -j ACCEPT --> para liberar o repasse antes que a politica que tornei padrão para a rede_local_clientes 'DROPasse' os pacotes.

campo ALLOW_PREROUTING
iptables -t nat -I PREROUTING -s ip_do_cliente -j ACCEPT --> para permitir roteamento de pacotes vindo do ip_do_cliente para não ser redirecionado pela regra PREROUTING da rede toda como falei acima.

Essas regras sempre usando o -I para adicionar ao início, sempre antes das demais regras.

Uma vez isso inserido no banco, uma ferramenta num script faz um select e exporta esses valores para um arquivo exatamente nessa mesma ordem acima, ou seja sempre le os campos na ordem POSTROUTING > FORWWARD > ALLOW_PREROUTING> e por ultimo o campo PREROUTING > FORWARD_DROP.

Essa ferramente se chama psql, que me salvou nessa jornada de tentativas, ele fica dentro de

/usr/bin/psql e faz toda a magia acontecer

os comando ficaram assim:

/usr/bin/psql -h 127.0.0.1 -U postgres -d database -t -c "select POSTROUTING from nat_hosp.liberacao where POSTROUTING is not null" > /var/www/portal/firewall.sh

/usr/bin/psql -h 127.0.0.1 -U postgres -d database -t -c "select FORWARD from nat_hosp.liberacao where FORWARD is not null" >> /var/www/portal/firewall.sh

E assim até o fim dos campos primordiais para o funcionamento correto
e dentro do mesmo script setei para sempre tornar o arquivo firewall.sh como executal e depois executa-lo, assim ficou o script(resumido é claro), ele é executado a cada 1 min.

#################################
/usr/bin/psql -h 127.0.0.1 -U postgres -d database -t -c "select POSTROUTING from nat_hosp.liberacao where POSTROUTING is not null" > /var/www/portal/firewall.sh

/usr/bin/psql -h 127.0.0.1 -U postgres -d database -t -c "select FORWARD from nat_hosp.liberacao where FORWARD is not null" >> /var/www/portal/firewall.sh

chmod +x /var/www/portal/firewall.sh
/var/www/portal/./firewall.sh
#################################

ainda existe um script que zera a tabela de liberação com os ips liberados sempre a meia noite, assim ele sempre tem que se autenticar uma vez por dia todo dia ou, se seu ip mudar, tem que se autenticar novamente, mas essa condição é rara pois configurei o dhcp para apenas mudar o ip a cada 7 dias.

Ou seja exporta>executa... exporta>executa... exporta>executa... a cada minuto do dia e zera ao final do dia, numa incansável tarefa do crontab -e

alterei o arquivo /etc/apache2/sites-enabled/default

este arquivo se refere ao diretorio padrão do apache2

em documentroot
alterei, inves de /var/www
ficou assim

/var/www/portal

Entre outras coisitas que posso falar depois.....
....
Então agora, quando nossos clientes entram em nossa rede, quando tentam navegar são direcionados para a pág que está em "/var/www/portal/index.php" e são obrigados a autenticar-se, se sucesso, o php colhe o ip do cliente executa os insert com os comando citados acima e assim que o script ler>exportar>executar o cliente estará liberado para navegação.
Daí, alguem vai me questionar;
-Mas se ele só roda o script a cada minuto, não é instantanea a liberação...

respota,

-Não, realmente não é instantanea a liberação mas é muito azar se ele executar isso no segundo 00m:01s do minuto corrente do cron pois ele vai ter que esperar um looongo período de 1 minuto para se ver livre do meu portal, então veja que se ele fizer isso no segundo 00m:45s só o tempo dele ler as informações sobre o acesso(aparece na pág de sucesso na autenticação), ja leva esse tempo e quando ele reiniciar o navegador.... funfa... a magia acontece e ele está navegando.

Não conheço muito da área(Linux) ainda, fui lendo, lendo, lendo até que deu certo, mas acho que isso daria um bom artigo pra quem deseja fazer um captive portal customizado, caso tenham interesse, me mandem um e-mail que tiro umas horas do meu fds e post aqui detalhe por detalhe de como fazer e espero receber também idéias para melhorar isso aí!

Agradecimentos a todos que ajudaram e em especial o korvoman que me deu uma boa luz sobre a chain POSTROUTING. Hail Hail Linux!


11. Re: POSTROUTING [RESOLVIDO]

Perfil removido
removido

(usa Nenhuma)

Enviado em 09/09/2010 - 17:26h

Blz muito obrigado!

Esse FDS vou arranjar um tempo acredito que não de tempo mas, com certeza preparo boa parte do texto para postar.

Abraços!






Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts