Re: tentando entender o squid
Em 18/12/07, Edmundo Valle Neto [EMAIL PROTECTED] escreveu: Márcio Pedroso escreveu: (...) modemswitchroteadorcliente.. conexao entre o roteador e o cliente ponto a ponto. (pra teste, nao podia eu, monopolizar a rede.) (...) 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... Switches sem autosense MDI/MDX (se não me engano o seu modelo é assim) tem uma porta correta de uplink para fazer cascateamento ou para ligar em outros dispositivos e/ou não precisar usar um cabo cross. (até HUBs tem isso) Normalmente você consegue utilizar um switch com qualquer tipo de cabo, mas você não pode colocar qualquer cabo em qualquer porta para ligar qualquer outro dispositivo. Você liga dois pontos finais com um cabo cross mas não usa esse cabo cross para ligar um desses pontos em uma porta normal do switch. (...) Atenciosamente. Edmundo Valle Neto eu nao estou usando cabo cross ligado ao switch, esse cabo estava ligado ao roteador que estava ligado diretamente ao outro micro, para eu nao monopoizar a rede enquanto eu fazia os testes... mas na hora que eu tinha uma brechas, eu colocava ele na rede como deveria ser usando cabos paralelos... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- linux user nº 432194 Eu sou livre e você?
Re: tentando entender o squid
Olá, primeiramente, está uma ZONA esse sua conf, coloque as acls que você juntas para melhorar a visualização e deixe os defaults separados. exatamente o contrario que vc falou amigo, vc vai negando sites, e no final vc da um allow pra rede interna, que ai o squid ira liberar tudo q nao foi negado previamente. por exemplo, se vc fizer: http_access deny QUALQUER_MAQUINA_DA_REDE_INTERNA http_access_ allow rede_interna a maquina da rede interna nao irá conseguir acessar, agora se vc inverter: http_access_ allow rede_interna http_access deny QUALQUER_MAQUINA_DA_REDE_INTERNA a maquina nao sera bloqueada, pois o squid ja liberou TODA rede. procure um tuto sobre amigo, utilize a lista só para problemas mesmo, use-a com bom senso.. ^^ qto ao rolo do hub e modem, nao muda nada a rede conectar direto no router ou no hub e depois router. Abraço, Lucas. Em 17/12/07, Edmundo Valle Neto[EMAIL PROTECTED] escreveu: Edmundo Valle Neto 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? 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. 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_access alow rede mas isso estava antes das regras de bloqueio.. entao deveria funcinar os bloqueios igual, independente do meio da conexao... correto?? Li de novo a mensagem. Alow tem dois ls, é allow. Na verdade seu proxy não libera nada, deveria é bloquear tudo sempre. Nem essa parte pode ser considerada. :) 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? 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? (...) 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. Atenciosamente. Edmundo Valle Neto Edmundo Valle Neto -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tentando entender o squid
Lucas Mocellin escreveu: (...) exatamente o contrario que vc falou amigo, vc vai negando sites, e no final vc da um allow pra rede interna, que ai o squid ira liberar tudo q nao foi negado previamente. por exemplo, se vc fizer: (...) O contrário do que eu falei? Eu não disse como deveria ser feito, eu disse o que deveria se esperar do que estava configurado. Acho que não ficou claro o que eu falei. A regra que libera toda a rede local liberaria a rede local antes de qualquer outra regra independentemente da sua posição estar um pouco mais acima do que deveria (no meio das configurações padrão), se não fosse o fato de ter um erro de sintaxe (no primeiro e-mail não tinha esse erro, agora tem, sabe-se lá porque). Portanto o comportamento esperado deveria ser que as regras abaixo (elas não constam no último e-mail mas constam no primeiro) deveriam bloquear o que elas se propõe a bloquear sempre e não ter um comportamento intermitente. Atenciosamente. Edmundo Valle Neto -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tentando entender o squid
Em 17/12/07, Edmundo Valle Neto [EMAIL PROTECTED] 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.. 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... 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_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 always_direct allow all acl manager proto cache_object acl localhost src 127.0.0.1/255.255.255.255 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... (...) 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- linux user nº 432194 Eu sou livre e você?
Re: tentando entender o squid
Em 17/12/07, Edmundo Valle Neto [EMAIL PROTECTED] escreveu: Edmundo Valle Neto 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? 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. 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_access alow rede mas isso estava antes das regras de bloqueio.. entao deveria funcinar os bloqueios igual, independente do meio da conexao... correto?? Li de novo a mensagem. Alow tem dois ls, é allow. Na verdade seu proxy não libera nada, deveria é bloquear tudo sempre. Nem essa parte pode ser considerada. :) é que eu escrevi sem copiar o texto, erro meu aqui heheheh :p 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? 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? (...) 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. Atenciosamente. Edmundo Valle Neto Edmundo Valle Neto -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- linux user nº 432194 Eu sou livre e você?
Re: tentando entender o squid
Em 17/12/07, Lucas Mocellin [EMAIL PROTECTED] escreveu: Olá, primeiramente, está uma ZONA esse sua conf, coloque as acls que você juntas para melhorar a visualização e deixe os defaults separados. exatamente o contrario que vc falou amigo, vc vai negando sites, e no final vc da um allow pra rede interna, que ai o squid ira liberar tudo q nao foi negado previamente. por exemplo, se vc fizer: http_access deny QUALQUER_MAQUINA_DA_REDE_INTERNA http_access_ allow rede_interna a maquina da rede interna nao irá conseguir acessar, agora se vc inverter: http_access_ allow rede_interna http_access deny QUALQUER_MAQUINA_DA_REDE_INTERNA a maquina nao sera bloqueada, pois o squid ja liberou TODA rede. procure um tuto sobre amigo, utilize a lista só para problemas mesmo, use-a com bom senso.. ^^ qto ao rolo do hub e modem, nao muda nada a rede conectar direto no router ou no hub e depois router. Abraço, bahh agora o bixo pega, cara, na maioria(pra dizer a verdade, todos) dos artigos que eu li, dizia assim + - o squid le as regras de cima para baixo, primeiro se o acesso e liberado, continua, se abaixo ele é bloqueado, ai para tudo.. como nos scripts de firewall primeiro tem que se por as liberaçoes, e depois os bloqueios porque se bloqueia, ele nem perde tempo olhando se esta liberado em sequida abraço Lucas. Em 17/12/07, Edmundo Valle Neto[EMAIL PROTECTED] escreveu: Edmundo Valle Neto 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? 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. 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_access alow rede mas isso estava antes das regras de bloqueio.. entao deveria funcinar os bloqueios igual, independente do meio da conexao... correto?? Li de novo a mensagem. Alow tem dois ls, é allow. Na verdade seu proxy não libera nada, deveria é bloquear tudo sempre. Nem essa parte pode ser considerada. :) 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? 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? (...) 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. Atenciosamente. Edmundo Valle Neto Edmundo Valle Neto -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- linux user nº 432194 Eu sou livre e você?
Re: tentando entender o squid
Márcio Pedroso escreveu: Em 17/12/07, *Edmundo Valle Neto* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 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. 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. 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
Re: tentando entender o squid
Márcio Pedroso escreveu: (...) Li de novo a mensagem. Alow tem dois ls, é allow. Na verdade seu proxy não libera nada, deveria é bloquear tudo sempre. Nem essa parte pode ser considerada. :) é que eu escrevi sem copiar o texto, erro meu aqui heheheh :p Então esquece o que foi dito daqui em diante. Seu squid tem uma regra que libera toda a rede interna de forma incondicional. O comportamento de bloquear ou não que você está dizendo continua sem fazer sentido com a configuração que você está descrevendo. (...) Atenciosamente. Edmundo Valle Neto -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tentando entender o squid
Em 17/12/07, Edmundo Valle Neto [EMAIL PROTECTED] escreveu: Márcio Pedroso escreveu: Em 17/12/07, *Edmundo Valle Neto* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 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. modemswitchroteadorcliente.. 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
Re: tentando entender o squid
Márcio Pedroso escreveu: (...) modemswitchroteadorcliente.. conexao entre o roteador e o cliente ponto a ponto. (pra teste, nao podia eu, monopolizar a rede.) (...) 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... Switches sem autosense MDI/MDX (se não me engano o seu modelo é assim) tem uma porta correta de uplink para fazer cascateamento ou para ligar em outros dispositivos e/ou não precisar usar um cabo cross. (até HUBs tem isso) Normalmente você consegue utilizar um switch com qualquer tipo de cabo, mas você não pode colocar qualquer cabo em qualquer porta para ligar qualquer outro dispositivo. Você liga dois pontos finais com um cabo cross mas não usa esse cabo cross para ligar um desses pontos em uma porta normal do switch. (...) Atenciosamente. Edmundo Valle Neto -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tentando entender o squid
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, ai descobri que tinha uma regra no squid que liberava o acesso pra rede interna acl rede src 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?? 2007/12/15, jefferson alexandre [EMAIL PROTECTED]: On Dec 14, 2007 3:32 PM, Márcio Pedroso [EMAIL PROTECTED] wrote: existe alguma diferença, pro squid, estar conectado diretamente ao modem ou ao hub Como assim? Qual é sua dúvida, exatamente? -- Linux User #328969 Linux System Administrator www.midstorm.org/~jalexandre/blog -- linux user nº 432194 Eu sou livre e você?
Re: tentando entender o squid
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? 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. 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_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? 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? (...) 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. Atenciosamente. Edmundo Valle Neto -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tentando entender o squid
Edmundo Valle Neto 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? 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. 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_access alow rede mas isso estava antes das regras de bloqueio.. entao deveria funcinar os bloqueios igual, independente do meio da conexao... correto?? Li de novo a mensagem. Alow tem dois ls, é allow. Na verdade seu proxy não libera nada, deveria é bloquear tudo sempre. Nem essa parte pode ser considerada. :) 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? 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? (...) 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. Atenciosamente. Edmundo Valle Neto Edmundo Valle Neto -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
tentando entender o squid
existe alguma diferença, pro squid, estar conectado diretamente ao modem ou ao hub #Porta do Proxy http_port 192.168.1.1:3128 transparent visible_hostname Controle_Unimar access_log /var/log/squid/access.log cache_log /var/log/squid/cache.log cache_log /var/log/squid/store.log cache_swap_log /var/log/squid/swap.log hierarchy_stoplist cgi-bin ? #Memória RAM usada pelo squid cache_mem 128 MB #cache_dir ufs /var/cache/squid 300 16 256 #Gerenciamento do cache rotate cache_swap_low 90 cache_swap_high 95 refresh_pattern ^ftp: 15 20% 2280 refresh_pattern ^gopher: 15 0% 2280 refresh_pattern . 15 20% 2280 #dns_nameserver 201.10.1.2 201.10.120.3 #Mensagens de erro do Squid em Português error_directory /usr/share/squid/errors/Portuguese #Arquivo máximo gravado no Cache maximum_object_size 512 KB #Diretório do cache cache_dir ufs /var/spool/squid 4096 16 256 #Diretório de logs cache_access_log /var/log/squid/access.log #Comportamento do log cache_log /var/log/squid/cache.log #IP's da rede local bloqueados #acl ip_negado src /etc/squid/ip_negado #http_access deny ip_negado #Bloqueio de downloads por extensão #acl download url_regex -i .com$ .pif$ .exe$ .avi$ .mp3$ .mpeg$ .mpg$ .rm$ .wma$ .wmv$ .asx$ .cab$ .src$ #Descrição das ACLs 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 rede_local src 192.168.1.0/255.255.255.0 http_access allow rede_local #acl SSL_ports port port 443 563 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 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 901 # swat acl Safe_ports port 1025-65535 # portas altas acl purge method PURGE #acesso liberado chefe acl liberado src /etc/squid/chefe http_access allow liberado #proibir url orkut acl proibir_orkut url_regex -i orkut http_access deny proibir_orkut !liberado #proibir por dominio acl proibidos dstdomain -i /etc/squid/proibidos http_access deny proibidos !liberado acl bloquear_googletalk url_regex -i /etc/squid/talk http_access deny bloquear_googletalk !liberado -- linux user nº 432194 Eu sou livre e você?
