Três placas de rede

cleyton.bruno
(usa Fedora)

Enviado em 14/09/2007 - 18:48h

Olá amigos.

Coloquei meu server três placas de rede. Sendo:
eth0 - 192.168.0.201 - Modem
eth1 - 192.168.0.202 - Rede1
eth2 - 192.168.1.203 - Rede2

Tenho o squid rodando normalmente na eth1, só que na eth2 o squid bloqueia todas as páginas. Alguém pode me dar uma luz?

Estou roteando dando o echo 1 no ip_forward e com as seguintes regras:
iptables -t POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j DNAT --to-destination 192.168.0.201:8080
iptables -t nat -A PREROUTING -i eth2 -p tcp --dport 80 -j DNAT --to-destination 192.168.0.201:8080

Já tentei fazer por rota e dá o mesmo problema. No meu squid.conf tem:


acl all src 192.168.0.0/24
acl all2 src 192.168.1.0/24
acl localhost src 127.0.0.1/255.255.255.255
acl rede_externa src 0.0.0.0/0.0.0.0
acl internet port 80
acl internet port 443
acl apache_port port 2222
acl mail port 25
acl mail port 110
acl blocked_sites url_regex -i "/etc/squid/sites_bloqueados.lst"
acl unblocked_sites url_regex -i "/etc/squid/sites_liberados.l st"
http_access allow localhost
http_access allow apache_port
http_access deny blocked_sites !unblocked_sites
http_access allow all
http_access allow all2
http_access allow internet
http_access allow mail

Estou quase desistindo...

adircastro
(usa Debian)

Enviado em 15/09/2007 - 09:54h

Olá,

Cara, tô com um problema similar ao seu, no meu caso tenho dois links e somente uma rede. Também no meu caso, quando mudo de provedor, o proxy bloqueia tudo. A solução que encontrei, foi indicar no navegador o uso do proxy. Só que no meu caso, a sala de bate papo da uol "bichou", e aqui sendo um cyber, onde as pessoas costumam frequentar essa sala, não tem como manter essa configuração. Foi a única maneira que encontrei de fazer com que a rede receba link dos dois provedores.

Quando o link principal cai, o reserva assume com cerca de 3 a 8 pacotes perdidos, no máximo. Mas aí vem o inconveniente da sala de bate papo.

Estou usando uma solução temporária de um colega aqui do forum. Ele usa ifdown ethx e ifup ethx. No meu caso, estou só derrubando a eth do link principal, então o reserva assume, quando o reserva cai ou tá com problemas de lentidão, uso ifup ethx e volta para o link principal.

Sei que é artesanal, mas estamos tentando otimizar isso, de forma que as rotas alternem automática.

Também já tentei várias formas, mas todas em vão... vou continuar procurando automatizar essa mudança de link.

Uma pergunta: quando você muda de rede o destino fica inacessível e a rota anterior se mantém?

cleyton.bruno
(usa Fedora)

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

Então... Não sei mto bem pq eu não posso nem sonhar em derrubar uma e levantar outra. As duas tem que funcionar ao mesmo tempo.

elgio
(usa OpenSuSE)

Enviado em 17/09/2007 - 09:34h

eth0 - 192.168.0.201 - Modem
eth1 - 192.168.0.202 - Rede1
eth2 - 192.168.1.203 - Rede2

Veja, eth0 e eth1 remetem para a mesma rede!!
Tenta trocar a eth1 para 192.168.2.201 pois as placas não podem conflitar (supondo que estás usando EM TODAS ELAS máscara 255.255.255.0. Se estiver usando 255.255.0.0 ai AS TRES estão em conflito.

cleyton.bruno
(usa Fedora)

Enviado em 17/09/2007 - 10:16h

Problema resolvido!
Nem cheguei a testar isto de mudar para 192.168.2 mas mais tarde vou fazer para que fique tudo REALMENTE certo. Mas o problema que eu tinha foi resolvido. É que eu tinha configurado
acl all src 192.168.0.0/24
acl all2 src 192.168.1.0/24

Não sei pq mas o squid usa esse all para um monte de outras coisas então vc não pode mudar. Aí mudei para
acl all src 0.0.0.0/0.0.0.0
acl interna1 src 192.168.0.0/24
acl interna2 src 192.168.1.0/24

Eu tinha mudado esse all pq não podemos deixar o proxy aberto para qualquer um usar, senão alguém pode querer invadir o site do itaú, por exemplo, e usar nosso servidor como proxy para parecer que a invasão partiu de nós. Mas descobri no google um outro modo de proteger. Ao invés de
http_port 3128
posso usar
http_port 192.168.0.201:3128

No problem! :D

Obrigado amigos pela ajuda

adircastro
(usa Debian)

Enviado em 17/09/2007 - 11:50h

cleyton,

Ao que parece, o teu modem tem o IP: 192.168.0.201, é a conexão entrante, certo?

E você coloca ele no proxy: http_port 192.168.0.201:3128, como isso funciona então?

Não seria o IP local para usar no proxy?

Desculpe-me se estou errado e confuso, mas é que sou iniciante nesse mundo.

Você poderia me dizer como tá o teu iptables? É que talvez o que você fez aí me ajude aqui, nesse meu problema.

Grato.

juno
(usa Linux Mint)

Enviado em 17/09/2007 - 12:01h

Cara,

Qual é a mascara que você está usando na sua rede ?

Falou =)

adircastro
(usa Debian)

Enviado em 17/09/2007 - 12:31h

Veja aí minhas configurações:

# The primary network interface
allow-hotplug eth0
iface eth0 inet static
address 192.168.100.100
netmask 255.255.255.0
broadcast 192.168.100.255
network 192.168.100.0
# dns-* options are implemented by the resolvconf package, if installed
#
# Internet
auto eth1
iface eth1 inet static
address 10.10.0.186
netmask 255.255.255.252
broadcast 10.10.0.255
network 10.10.0.184
gateway 10.10.0.185

# Internet
auto eth2
iface eth2 inet static
address 172.16.130.218
netmask 255.255.255.252
broadcast 172.16.130.255
network 172.16.130.184
gateway 172.16.130.217

Quero colocar o IP 172.16.130.218 e 10.10.0.186 entrando ao mesmo tempo e usando o IP local: 192.168.100.100. Outro dia consegui fazer assim e deu certo, mas aí mexendo, mexendo, perdi as configurações.

Tava pensando em algo semelhante ao que o cleyton implementou no proxy dele, só que criando acl pra rede "entrante". Será que tem fundamento?

adircastro
(usa Debian)

Enviado em 17/09/2007 - 12:35h

juno,

Quando saio da rede 172.16.130.218 a rede 10.10.0.186 não entra, ele fica dando ping no IP anterior, mas a mensagem é de Host de destino inacessível.

Outro dia consegui, não lembro mais como, fazer a troca entre provedores, sendo que o IP default para ambas as redes externas, apontava para o IP 192.168.100.100, que é o gateway da minha rede.

Funcionava muito bem, mas aí "malinei" e perdi o rumo da coisa.

adircastro
(usa Debian)

Enviado em 17/09/2007 - 12:45h

juno,

Creio que o nome do meu problema é: "redirecionamento de rota default" na conexão entrante.

Quando troco de provedor o link reserva navega quase normal, não fosse o problema na sala de bate papo da uol que "bicha".

Acho que isso acontece, porque o link reserva ao entrar, o ping não fica normal, ele fica procurando o IP do link anterior: 172.16.130.218, que responde informando, que o host é de destino inacessível, embora esteja navegando.

Então, para mudar a rota para o link reserva, uso uma dica de um colega do forum, que usa o ifdown ethx e ifup ethx.

Queria que a rota default mudadesse de 172.16.130.218, para 10.10.0.186 imediatamente à queda do link principal.

cleyton.bruno
(usa Fedora)

Enviado em 17/09/2007 - 13:08h

Então, quando eu coloquei a acl all para a rede deu prob. Parece que o squid só consegue trab com a acl all para 0.0.0.0/0.0.0.0. Então eu coloquei que a http_port é 192.168.0.201:8080 para dizer que o pc com o squid é o 192.168.0.201 na porta 8080. Senão o meu ip externo ex: 200.201.202.203 poderia ser acessado na 8080.

Meu firewall está com as regras aí em cima que eu postei. Qual é o problema que vc está tendo?

adircastro
(usa Debian)

Enviado em 17/09/2007 - 17:37h

cleyton,

Minha rede está configurada assim:
eth0: 192.168.100.100 = rede local
eth1: 10.10.0.186 = link reserva
eth2: 172.16.130.218 = link principal

Quando tô no link principal o proxy funciona como transparente e os pings a partir das estações acontece normalmente.

Quando cai o principal e entra o link reserva, o ping muda para: Resposta de 172.16.130.218: Host de destino inacessível, e só navega se for indicado o uso do proxy no navegador: 192.168.100.100:8080. A sala de bate papo fica "bagunçada" usando assim dessa forma.

Quando o link principal volta, tenho que desabilitar o proxy, senão o problema da sala de bate papo também acontecerá nesse link.

Quero que quando o link reserva entre, ele use sua própria rota, e não a do link principal.

Resta saber se com uma acl sobre o link principal e reserva, isso seja resolvido. Só que aí vem outra questão: que acl usar?