Prezados, boa tarde! Após conectar o tal cabo de rede, a instabilidade continuou a ser presenciada, de modo que o problema não era apenas esse. Até porque a outra interface da internet estava devidamente conectada.
Hoje, após todo este tempo, finalmente pude solucionar o problema. O que me intrigava mais era a intermitência do acesso externo. Ora conseguia, ora não. Desta forma, vou postar aqui a solução, na esperança que possa auxiliar outras pessoas, ou ao menos auxiliar a não cometerem os mesmos erros :-) Após exaurir todas as possibilidades quanto a conectividade, configuração do firewall, etc. comecei a desconfiar que havia algum conflito de rotas. Hoje, então, fiz vários testes. No primeiro deles, deixei um ping rodando em minha casa (sem obter respostas) e, ao chegar aqui, pude ver que a resposta estava sendo enviada. Utilizei, para tal, o comando tcpdump, analizando todo o tráfego em todas as interfaces de rede. Se os pacotes externos não estavam sendo dropados, pois pude ver sua resposta, então utilizei o tcpdump novamente, desta vez isolando cada uma das três interfaces de rede. Para isto, executei o comando simultaneamente, jogando a saida em três arquivos diferentes. Para minha surpresa, foi possível verificar que, de fato, no arquivo de log da eth0 (internet), só havia o registro dos pacotes de entrada. Ao observar o log da eth2 (intranet), pude encontrar as respostas dos pacotes da internet. Aí a coisa ficou clara: havia algum problem nas tabela de rotas: [EMAIL PROTECTED]:/etc/shorewall$ sudo route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.0.0 * 255.255.255.0 U 0 0 0 eth2 200.181.65.0 * 255.255.255.0 U 0 0 0 eth1 200.181.65.0 * 255.255.255.0 U 0 0 0 eth0 default 192.168.0.1 0.0.0.0 UG 100 0 0 eth2 default 200.181.65.169 0.0.0.0 UG 100 0 0 eth0 default 200.181.65.169 0.0.0.0 UG 100 0 0 eth1 De fato, havia 3 rotas default e, para piorar, a primeira delas era a da intranet. Esta tabela era a tabela default, obtida imediatamente após a instalação de um novo servidor. Então reconfigurei as rotas de maneira mais enxuta, eliminando também, por enquanto, a interface da internet redundante (eth1), até decidir o que fazer com ela. Ficou assim: [EMAIL PROTECTED]:~$ sudo route [sudo] password for filipe: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.0.0 * 255.255.255.0 U 0 0 0 eth2 200.181.65.0 * 255.255.255.0 U 0 0 0 eth0 default 200.181.65.169 0.0.0.0 UG 0 0 0 eth0 Com isto, uma pessoa localizada em outro site conseguiu acessar os endereços e obter as respostas de seus pacotes. Quando chegar em casa faço mais testes, mas já considero o problema solucionado. É isso aí! No final das contas o problema não tinha nada a ver com apache ou shorewall, mas sim com a tabela de rotas. Espero que este relato sirva para alguém! Abraços, Filipe Fedalto wrote: --------------------------------------------------------------------------- Esta lista é patrocinada pela Conectiva S.A. Visite http://www.conectiva.com.br Arquivo: http://bazar2.conectiva.com.br/mailman/listinfo/linux-br Regras de utilização da lista: http://linux-br.conectiva.com.br FAQ: http://www.zago.eti.br/menu.html
