LEIAM e postem alguma coisa...

FireBird,

Fiz tudo que você sugeriu, e fiquei foi sem navegar... só tinha ping pra fora... risos.

Então apaguei tudo e refiz as configurações anteriores. Que tá navegando muito bem no link principal, mas que no secundário acaba causando essa m... Nesse momento, o que seria os pings normais, ele exibe apenas a seguinte mensagem:
Resposta de 172.16.130.218: Host de destino inacessível. Ou seja, com esse link na rede, o windows não pinga pra fora. O ping acontece normal, quando faço do servidor. É isso que tá me tirando o sossego, pois é isso que causa o problema na sala. Veja que ele tá indicando o IP 172.16.130.218, que é o do link principal, sendo que nesse momento estou usando o secundário.

Outra coisa: eu não tenho problemas de bloqueio de IP na uol. O problema é que quando estou usando o link secundário, não tem como teclar na sala. Mas se eu coloco esse link num brazilFW que tenho aqui, a sala rola sem problema.

Isso tá acontecendo nesse servidor Debian, onde tenho esses dois links.

Outra coisa: não posso abrir mão do squid... é pelo cache. Com duas conexões dessas que tenho, não tem como ficar sem cache.

Vou pra casa agora... cansei de tanto ler, copiar, colar e testar... risos.

Mas se você tiver algo pra mim, pode postar... amanhã cedo eu leio e faço.

Até amanhã.

FireBird,

Veja o servidor fazendo ping pra uol:
server:~# ping uol.com.br
PING uol.com.br (200.221.2.45) 56(84) bytes of data.
64 bytes from home.uol.com.br (200.221.2.45): icmp_seq=1 ttl=54 time=90.3 ms
64 bytes from home.uol.com.br (200.221.2.45): icmp_seq=2 ttl=54 time=93.4 ms
64 bytes from home.uol.com.br (200.221.2.45): icmp_seq=3 ttl=54 time=103 ms

--- uol.com.br ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 3790ms
rtt min/avg/max/mdev = 90.391/95.706/103.299/5.510 ms

Como pode ver, normal. Só que das estações, que rodam windows não acontece o ping quando estou usando o link secundário.

O ping só acontece a partir das estações, quando uso o link principal.

Boa noite... agora vou mesmo.

Até amanhã.

nao rapah... isso era so teste mesmo...tem alguma coisa nesse seu firewall que bloqueia o ping depois que vc sobe ele... entende? tipo... qdo vc ficou sem navegar nem nada(logicamente por causa do squd fora do ar) vc conseguiu pingar... e, depois que vc ativa começa a bixar... entao tem algo nesse firewall seu bloqueando...

o host inacessivel deve ser porque vc deve de ta fora da rede ou com o gateway errado...da uma olhada nisso ai...
sicneraemente? acho que vc deveria refazer esse serviço pq vc parece nao saber onde estao as regras que talvez impeçam vc de fazer certos acessos... as vezes em determinado link seu ai, etnha um bloqueio ou coisa parecida... da uma olhada

Olá FireBird,

Acredito que seja com o proxy. Já fiz e refiz ele, mas não alterou em nada. Em todo caso, vou passar pra você meu iptables e squid, para que você faça uma análise do cruzamento dos dois:

server:/etc/init.d# cat iptables
#!/bin/sh
iptables -F
iptables -t nat -F
iptables -t mangle -F
modprobe iptable_nat
#
# Proxy transparente (aponta no squid) na interface ethx - rede local
#
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080
#
# Compartilhando a internet na interface ethx - rede externa
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth2 -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward
--------------------------------------
Já olhei esse squid e não vejo nada de anormal nele. Como você pode ver, comentei a linha que proibe sites. Atualmente estou fazendo o bloqueio é pelo iptables.

server:/etc/init.d# cat /etc/squid/squid.conf
http_port 8080 transparent
cache_mem 64 MB
maximum_object_size_in_memory 128 KB
maximum_object_size 4096 KB
minimum_object_size 0 KB
cache_swap_low 90
cache_swap_high 95
cache_dir ufs /var/spool/squid 768 16 256
cache_access_log /var/log/squid/access.log
cache_log /var/log/squid/cache.log
cache_store_log /var/log/squid/store.log
pid_filename /var/run/squid.pid
error_directory /usr/share/squid/errors/Portuguese
emulate_httpd_log on
visible_hostname srv-cyber
cache_mgr gerenciacyber@ig.com.br
#
# ACLS RECOMENDADAS
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl to_localhost dst 127.0.0.0/8
acl SSL_ports port 443 # https
acl SSL_ports port 563 # snews
acl SSL_ports port 873 # rsync
acl Safe_ports port 80 # http
acl Safe_ports port 21 # FTP
acl Safe_ports port 443 563 # https, snews
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl Safe_ports port 631 # cups
acl Safe_ports port 873 # rsync
acl Safe_ports port 901 # SWAT
acl purge method PURGE
acl CONNECT method CONNECT
#
# ACLS PERSONALIZADAS
# Define a rede interna
acl redelocal src 192.168.100.0/255.255.255.0
#
# DEFINE SITES BLOQUEADOS NA REDE
#acl proibidos dstdomain "/etc/squid/proibidos"
#
# HTTP_ACCESS RECOMENDADAS
http_access allow manager localhost
http_access deny manager
http_access allow purge localhost
http_access deny purge
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
#
# LIBERACAO DE DOWNLOADAS ATE 5 MB
#reply_body_max_size 524880 allow all
#
#PERMITE ACESSO DA REDE INTERNA
http_access allow redelocal
#
# NEGA TUDO QUE NAO FOI LIBERADO OU NEGADO
http_access deny all

route -n

ve se pra tua rede local nao ta apontando esse gw antigo, ou duplicado o default gw.


[]´s

Olá matrix,

Veja aí as rotas com o route -n e logo abaixo com o ip route
-----------------------------------------------
Destino Roteador MáscaraGen. Opções Métrica Ref Uso Iface
10.10.0.184 0.0.0.0 255.255.255.252 U 0 0 0 eth1
172.16.130.216 0.0.0.0 255.255.255.252 U 0 0 0 eth2
192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 172.16.130.217 0.0.0.0 UG 0 0 0 eth2
0.0.0.0 10.10.0.185 0.0.0.0 UG 0 0 0 eth1
-----------------------------------------------
10.10.0.184/30 dev eth1 proto kernel scope link src 10.10.0.186
172.16.130.216/30 dev eth2 proto kernel scope link src 172.16.130.218
192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.100
default via 172.16.130.217 dev eth2
default via 10.10.0.185 dev eth1

Pessoal,

Eu imagino que o problema esteja sendo com o proxy. Quando estou usando o link na eth2 com o IP 172.16.130.218 faço ping direto das estações e a sala não tem problema nenhum. Já quando mudo para o link da eth1 com o IP 10.10.0.186, os pings cessam e dão lugar seguinte mensagem:
-------------------------------------------
Disparando contra globo.com [201.7.176.59] com 0 bytes de dados:
Resposta de 172.16.130.218: Host de destino inacessível.
Resposta de 172.16.130.218: Host de destino inacessível.
...
Vejam que o IP que ele usa pra fazer o ping é o da eth2.

De alguma maneira, o IP não direciona para o IP 10.10.0.186, que é o que está presente no momento dessas mensagens do ping.

Navego, acesso o msn... só na sala de bate papo "bicha" e nos e-mails. Também tenho que indicar no navegador o uso do proxy. E fazendo isso, até o link da eth2 que usa o proxy transparente, também "bicha" a sala de bate papo. Ou seja, o proxy é transparente quando uso o link pela eth2, e deixa de ser transparente quando uso o link pela eth1.

0.0.0.0 172.16.130.217 0.0.0.0 UG 0 0 0 eth2
0.0.0.0 10.10.0.185 0.0.0.0 UG 0 0 0 eth1

route -del default gw 172.16.130.217

acho q eh esse o comando.
vc ta com 2 default gw.

fazendo o comando acima ele vai deixar só oque ta funcionando.
[]´s

Matrix,

O link primário é o gw 172.16.130.217. O ideal seria que ele sumisse quando o secundário, de gw 10.10.0.185 entrasse.

Estou usando os dois links no meu servidor, pois aqui a conexão é muito deficiente.

Se eu deletar a gw padrão 172.16.130.217, como irá ficar quando eu o estiver usando?

E apenas a título de curiosidade, onde insiro o comando route -del default gw 172.16.130.217?

Certa vez digitei na linha de comando esse comando, mas ao reiniciar o servidor, o GW voltava.

Mas creio que você tá no rumo certo ao apontar os dois gateways. Só não sei como isso irá ficar apenas com um GW, quando uso os dois links.

Matrix,

Acredito que o gw 10.10.0.185 fique sendo procurado, mas não encontrado. Quando uso comando traceroute ele me reporta o GW 10.10.0.185, embora o ping reporte outra mensagem:
Disparando contra globo.com [201.7.176.59] com 0 bytes de dados:
Resposta de 172.16.130.218: Host de destino inacessível.
...
E mesmo diante dessa mensagem a navegação acontece normalmente.

Acredito que o problema da sala de bate papo seja causado exatamente por isso: o GW usado para pingar da estação continua sendo o primeiro gateway: 172.16.130.217.

DETALHE: de dentro do servidor o ping acontece normalmente.

Então o problema pode ser no proyx. Será que estou no rumo?

Será que tem como fazer com que esse ping da estação saia pelo GW 10.10.0.185?

o fato e subir novamente o gw deve ser algum script que esteja fazendo ou no rc.local, o comando que eu passei deve ser digitado no console mesmo, ele ta resolvendo o dns normalmente, mais por algum motivo a rede 192.168.100.0/24 ainda ta tentando sair pelo link que ta com o cabo desconectado.
eu não entendo de dual link ainda, não tive a oportunidade de passar pelo problema, infelizmente não vou poder lhe ajudar quanto a redundancia, mais vou arriscar aqui 2 comandos para resolver o problema.

#route del default gw 172.16.130.217
#route add 192.168.100.0/24 gw 10.10.0.185

desculpe se a sintax estiver incorreta, porem com essas duas informações acredito que você tenha intendido oque passou pela minha cabeça. ehehe, espero que de certo.

[]´s

m4tri_x,

E se eu disser que não estou usando nenhum script para fazer redundância?

Na verdade, a única coisa que fiz foi isso, no iptables:
--------------------------------------------
# Compartilhando a internet na interface ethx - rede externa
#iptables -t nat -A POSTROUTING -s 192.168.100.0 -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth2 -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward
echo "1" > /proc/sys/net/ipv4/ip_dynaddr

Esses scripts pra redundância, pelo menos uns 8 que copiei na internet, nenhum foi tão eficiente quanto a essa maneira que tô fazendo... os outros levavam cerca de 3 minutos pra restabelecer a navegação... e alguns, na página da uol, levava quase 10 minutos.

Sinceramente falando, e sem querer diminuir ninguém, esse negócio de redundância, é mal explicado.