ACESSAR domínio pelo mesmo link de origem

rubens_web
(usa Debian)

Enviado em 07/03/2012 - 14:30h

Mas o estranho que tem algum jeito de resolveir isso sem precisar config. o BIND, pois eu tinha conseguido fazer funcionar com as regras abaixo, não sei o que aconteceu q parou.

Será que manipulando pelo firewall eu não consiga resolver isso novamente?


#ROTA ACESSO SISTEMA BKP (APACHE)
#------------------------------------------------------------------------------------------------------------------
iptables -t nat -A PREROUTING -i $ifaceExt -p tcp -m multiport --dports 21,80 -j DNAT --to-destination 192.168.1.61
iptables -t nat -A POSTROUTING -o $ifaceExt -j MASQUERADE
iptables -t nat -A POSTROUTING -d 192.168.1.61/32 -j SNAT --to-source 192.168.1.50
#------------------------------------------------------------------------------------------------------------------

rubens_web
(usa Debian)

Enviado em 07/03/2012 - 14:46h

Pelo firewall tem que ser possível ROTEAR isso, pois eu já consegui fazer funcionar sem mexer no BIND (não gostaria de configurar o BIND neste servidor).

Outro detalhe apenas para dar uma LUZ.
Quando eu coloco o endereço (portalbkp.dominio.com.br) aqui na rede interna aparece aquele erro de bloqueio do SQUID. No meu squid já tem uma ACL para liberar o dominio (.dominio.com.br).

Ajuda ai galera!

rubens_web
(usa Debian)

Enviado em 07/03/2012 - 15:17h

Help...

andrecanhadas
(usa Debian)

Enviado em 07/03/2012 - 15:22h

Quanto ao squid se tiver redirecionamento da porta 80 para o squid pode tentar a regra:


Ou ainda:


Quanto ao redirecionamento:
Talvez se direcionar a rede local:

andrecanhadas
(usa Debian)

Enviado em 07/03/2012 - 15:25h

Veja este link:(Melhor Resposta)
http://www.vivaolinux.com.br/topico/Squid-Iptables/Redirecionar-portas-entre-servidores.

removido
(usa Nenhuma)

Enviado em 07/03/2012 - 16:16h

Se o problema é só o acesso pela rede interna, faz o seguinte:

**** estou supondo que a interface interna é $ifaceInt

iptables -t nat -A PREROUTING -i $ifaceInt -p tcp -m multiport --dports 21,80 -j DNAT --to-destination 192.168.1.61
iptables -t nat -A POSTROUTING -o $ifaceInt -d 192.168.1.61/32 -m multiport --dports 21,80 -j SNAT --to-source 192.168.1.50

Fazendo assim as requisições para LINK-B será redirecionado para LINK-A, e as respsotas voltaram para LIN-B devolvendo para quem requisitou a comunicação.

rubens_web
(usa Debian)

Enviado em 07/03/2012 - 16:17h

Fiz vários testes aqui com estes tutoriais, mas não consegui resolver.
O que eu faço?

rubens_web
(usa Debian)

Enviado em 07/03/2012 - 16:18h

Vou tentar este... já posto resultados!

removido
(usa Nenhuma)

Enviado em 07/03/2012 - 16:26h

Corrigindo uma coisa:

Fazendo assim as requisições para LINK-B será redirecionado para LINK-A, e as respsotas voltaram para LIN-B devolvendo para quem requisitou a comunicação.

Não é assim, é assim: Fazendo assim as requisições para LINK-B será redirecionado para LINK-A, e as respostas voltaram para quem requisitou.

rubens_web
(usa Debian)

Enviado em 07/03/2012 - 17:18h

Na teoria seria isso mesmo, mas na prática não funcionou! será que tem outra regra minha que está bloqueando estes IPTABLES ?

Pois estas regras está bem no final do script!

removido
(usa Nenhuma)

Enviado em 07/03/2012 - 17:26h

Coloca a regra no inicio então.

removido
(usa Nenhuma)

Enviado em 07/03/2012 - 17:31h

A propósito para este tópico http://www.vivaolinux.com.br/topico/Squid-Iptables/Ultra-Surf-como-bloquear-esta-praga

Já tentou resolver usando a dica desse link abaixo:

http://www.vivaolinux.com.br/artigo/Como-bloquear-o-Ultrasurf-solucao-definitiva-(iptables-+-Fail2ba...