Em 17/12/07, Edmundo Valle Neto <edmundo.valle@terra.com.br> escreveu:
Márcio Pedroso escreveu:
>
>
> Em 17/12/07, *Edmundo Valle Neto* <edmundo.valle@terra.com.br
> <mailto:
edmundo.valle@terra.com.br>> escreveu:
>
> Márcio Pedroso escreveu:
> > eu consegui resolver o problema, mas nao consegui entende-lo
> > o problema é que quando o roteador estava ligado ao hub ao inves do
> > modem, ele bloqueava,
>
> Pelo que eu entendi o roteador estava ligado ao hub em uma
> interface e
> continuava ligado ao hub na outra interface. Como você sabe que
> era por
> causa do hub? Você testou sem hub em lado nenhum?
>
>
> na verdade ele estava retornando o sinal pra um cabo cross, ou seja
> uma ponto-a-ponto..
Não entendi.
modem>switch>roteador>cliente.. conexao entre o roteador e o cliente ponto a ponto. (pra teste, nao podia eu, monopolizar a rede.)
>
> Se fosse um hub não deveria ter feito diferença nenhuma. Hubs
> funcionam
> como repetidores somente. Você tem certeza que o hub é hub e não é um
> switch? Faz MUITA diferença, switches processam os pacotes para
> saberem
> por qual porta devem ser enviados e SE devem ser enviados, alguns
> verificam os pacotes por erros também, depende de qual é o método de
> repassagem de pacotes que eles dão suporte.
>
>
> verifiquei e o que eu achei que era hub é um switch... é um dlink
> des-1008D, entao esse é o problema...
Não. Eu disse que existe muita diferença entre o comportamento deles,
não disse que com certeza faz diferença onde você coloca um switch.
Se você tem uma rede bem configurada e com um cabeamento bem feito, em
teoria nenhum dos dois faria diferença nenhuma em lugar nenhum.
Se você tiver algum problema na configuração da rede ou no cabeamento um
hub não faria diferença nenhuma mas um switch com suporte a
"store-and-forward" faria.
Resumindo, se você tiver algum problema em OUTRO lugar, o seu switch
PODE se comportar de maneira estranha.
Assim como pode se comportar de maneira estranha se você começar a
trocar ele de lugar e trocar os cabos sem desligar nada, existem caches
utilizados tanto no switch como nos protocolos no seu roteador e
cliente. Mas eles expiram bem rápido.
entao vou me ater na premissa que foi a liberaçao na acl. apesar de, como ja relatado, ele funcionava quando estava recebendo o sinal atraves do switch.
eu tenho por politica propria, ficar invertendo a posiçao dos cabos no switch, ate pra saber quem é quem nele...
talves, mais adiante eu descubra o que eu fiz de errado, no mais.. nada a declarar..
um abraçao forte pro pessoal da lista, sempre bom debater com voces...
>
> > ai descobri que tinha uma regra no squid que liberava o acesso pra
> > rede interna
> > acl rede src 192.168.1.0/24 <
http://192.168.1.0/24>
> <http://192.168.1.0/24 <http://192.168.1.0/24>>
> > http_access alow rede
> > mas isso estava antes das regras de bloqueio.. entao deveria
> funcinar
> > os bloqueios igual, independente do meio da conexao... correto??
>
> Antes das regras de bloqueio? E onde está o marcador que você se
> refere
> que define onde começam e onde terminam as regras de bloqueio?
>
>
>
> vou mostrar...
>
> acl all src 0.0.0.0/0.0.0.0 <http://0.0.0.0/0.0.0.0>
> always_direct allow all
> acl manager proto cache_object
> acl localhost src 127.0.0.1/255.255.255.255
> <http://127.0.0.1/255.255.255.255
>
Eu perguntei isso porque não existe nenhum, o arquivo de configuração do
squid não tem sessões, o agrupamento serve somente para organizar a
configuração. Seja onde você colocar a regra, fica feio, se comporta de
maneira diferente, mas funciona.
>
> eu estava adicionando a rede interna aqui..
>
> Muito pelo contrário, a primeira regra http_access que seu squid tem
> noção já libera tudo para a rede interna, ou seja, seu squid está
> configurado para não bloquear nada nunca.
>
> Como você sabe que ele bloqueou os acessos? Você recebeu como
> resposta
> no browser uma página de bloqueio? Você viu a tentativa de acesso nos
> logs? Você aumentou o nível de debug para indicar quais regras bateram
> com a requisição? Como é que você sabe que ele pelo menos recebeu as
> tentativas de acesso?
>
>
> sim... recebia resposta do squid... vi nos logs e tal..ummm
> aumentar o nivel de debug, isso é interessante...
> olha, eu tentava acessar e acessava, pra mim isso é o suficiente.. e
> quando bloqueava ele mostrava o aviso do squid...
debug_options ALL,1 33,2
Isso habilita além do debug level 1 para todas as sessões, um debug
level 2 para a sessão 33 (Client-Side Routines).
>
> (...)
>
>
> Você está pedido uma explicação para uma situação baseada em uma
> soma de
> suposições que você fez. Depois de ter visto você colocar o
> endereçamento IP errado eu duvido que alguém considere qualquer
> afirmação que você dê que tenha acontencido, sem você colar junto as
> linhas dos logs ou do shell que provam isso. Só o endereçamento
> errado
> já provoca erros de certa forma imprevisíveis.
>
>
>
>
> Qualquer palpite aqui é chute.
>
>
> é que eu trabalho com isso a pouco tempo, estou aprendendo na marra, a
> unica ajuda que tenho em determinados momentos é a lista, e nem sempre
> é facil se expressar por email... mas to melhorando, pelo menos isso...
> as minhas afirmaçoes sao baseadas no que eu constatei, simples assim,
> postei pra ver se mais alguem tinha passado por isso, e isso depois de
> uma boa pesquisada no "pai google". essa minha afirmaçao, tambem era
> pra entender o que aconteceu, eu poderia simplesmente ter aceitado que
> estava bom e nao ter dado bola pra isso, fazendo uma "receita de bolo"
> e seguindo.. mas...
> vou postar os logs, na proxima vez(sempre vai ter uma), sei que isso
> facilita muito, mas como nesse caso, eu nao sabia que dava de aumentar
> o nivel de debug do log, entao eu olhava os log e nao via nada.. mas
> agora vou melhorar..heheheheh
>
> Atenciosamente.
>
> Edmundo Valle Neto
>
>
> bahh valeu. ja coompreendi o meu erro e ainda tive uma dicas extras...
> melhor que isso é impossivel.
> sempre bom contar com a lista
Atenciosamente.
Edmundo Valle Neto
--
To UNSUBSCRIBE, email to debian-user-portuguese-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmaster@lists.debian.org