A resposta do Jack está muito clara. Parabéns. Mas voltando ao seu problema, trabalho a mais de 10 anos nesse ramo aonde a culpa é sempre sua e muitas vezes não conseguimos uma desculpa "racional"..rsrsrs
Por experiência, no uso cotidiano nunca encontrei um site ou serviço que houvesse problemas com proxy, exceto o conectividade social e aplicações de pequenas/médias empresas, pelos menos nunca me deparei com problema de acesso a algo público como banco por exemplo. Acho que o problema que sofreu deveria estar na máquina ou alguma acl, pois por padrão os proxys que administro indiferente de ser squid com pf/bsd ou Linux, eu mando todos pelo proxy, até diretor e presidente a única exceção é uma regra que utilizo para conectividade social aonde eu libero o range de ips da caixa e quem utiliza não tem o IE com proxy configurado, esses usuários eu deixo IE sem proxy e instalo Firefox para ela navegar (geralmente setor de RH). Agora o pessoal do financeiro que são usuários maciços de banco, passam por proxy sem problema algum. O item do no_cache utilizei somente em alguns clientes que possuíam um portal desenvolvido por eles ou uma intranet...algo do gênero, inclusive peguei um caso bizarro que a intranet deles quando havia cache só ficava logado o último usuário, se uma nova pessoa efetuar logon no sistema, todos já logados passavam a ter o mesmo login do último. Escrevendo o texto me lembrei de outra exceção, havia uma aplicação do bradesco empresas e realmente dava problemas, mas acho que ela nem existe mais. -----Mensagem original----- De: [email protected] [mailto:[email protected]] Em nome de Rodrigo Soares Enviada em: quinta-feira, 28 de fevereiro de 2013 15:32 Para: Lista em Português sobre pfSense Assunto: Re: [Pfsense-pt] RES: RES: RES: RES: Java x Proxy Com o devido respeito "Karaleo". Fico enriquecido com tal conhecimento e com certeza sanou as dúvidas. Agradeço pela explicação. Em 28 de fevereiro de 2013 15:15, Jack <[email protected]> escreveu: > Buenas! > > >-----Original Message----- > >From: Rodrigo Soares > > > >Quando incluo um domínio ou IP, em Services --> SQUID -- Cache Mgtm, > >no campo Do not cache Isso automaticamente implica em ter que liberar > >o acesso no firewall, já que não vai passar pelo squid? > > > >Pergunto isso, pois você mesmo me sugeriu duas opções: primeira > >descrita na pergunta e a segunda não fazer proxy para tais domínios. > >Seria uma ou outra? tanto uma quanto a outra tem a mesma finalidade? > > > > Bem, como diria o meu xará, o "estripador", vamos por partes... :) > > Existem basicamente 2 formas de você trabalhar com Proxy (Squid): > > 1) Proxy transparente > > 2) Proxy Autenticado > > No Proxy autenticado você deve configurar no cliente (manualmente ou > automaticamente - existem vários métodos para se fazer isso) que tipo > de conexão passará por dentro do Proxy. Por default, o Squid não trata > (nem cachê, nem ACLs) de conexões HTTPS - Somente HTTP. > > Mas no seu caso, por exemplo, onde o browser estava configurado para > encaminhar ao Squid conexões HTTPS e, o serviço no pfSense estava > configurado para rodar de forma "não transparente", o cachê acontece > (ou ao menos tentar acontecer). Em outras palavras, ele vai tentar > armazenar localmente os últimos dados transmitidos em conexões HTTPS. > Isso, em vários CGIs e aplicações web é um problema - Já que, por > questões de segurança, estas aplicações não admitem cópias locais em > cachê (querem que os clientes/browsers sempre busquem conteúdo da > fonte - gerando novas conexões). > > Quando você utiliza Squid e SquidGuard, por exemplo, a sequencia de > checagens e processamento da conexão é basicamente: > > 1) O Squid pega a conexão e tenta aplicar as configurações das ACLs > (Proxy Server -> ACLs) e opções de cachê (Proxy Server -> Local > Cache); > > 2) Se existir alguma exceção na seção "Do not cache", ele tenta seguir > (não executando cachê); > > 3) Se houver alguma configuração em "White Lists" ou "Black Lists" que > satisfaça aquela URL (quando de conexões HTTP), ele as aplica; > > 4) Depois das checagens acima, se configurado, ele chama o SquidGuard > ou Dansguardian, por exemplo. Ambos são uma espécie de "acessório" > para o Squid e são invocados automaticamente pelo serviço normalmente > apenas para aplicar ACLs (não se metem com o cachê em si). Novamente > aqui estamos falando apenas de conexões HTTP. Nós, na ConexTI, estamos > desenvolvendo (na prática já está > pronto) e implementando sob consultoria um *Filtro de Navegação SSL* > para o pfSense. Neste caso, você consegue aplicar as ACLs do > SquidGuard ou DansGuardian em conexões HTTPS também e, portanto, *não > precisa mais bloquear por default conexões saíntes TCP/443* para > aumentar o nível de segurança. ;-) > > A questão é que normalmente você acessa o site do banco via HTTP, > então todas as regras acima para HTTP são executadas. Só depois, > durante o login é que você inicia uma seção HTTPS. Por isso, > normalmente, quando você cadastra o site do banco ou suas redes em "Do > not cache", há boas chances de resolver um problema como o seu. No > entanto, alguns sistemas na web, conseguem "perceber" que a conexão > não veio diretamente do cliente (mesmo sem fazer cachê, ela foi > encaminha para o Squid) e podem dropá-la. Nestes casos, o ideal num > Proxy autenticado, é você criar a exceção diretamente no cliente (no > browser - também é possível se automatizar isso, pra não precisar > fazer manualmente em cada PC). Aí a conexão se quer será enviada para > qualquer análise do Squid. > > Liberar a porta TCP/443 nas regras de firewall costuma ser uma tática > mais comum no uso de Proxy transparente - Onde o HTTPS nunca é enviado > ao Squid por default. Como a conexão não passa pelo Squid, não há > chance de cachê, então liberando a conexão no firewall os problemas se > resolvem. Isso também vale para os casos em que você marca manualmente > no browser para que ele não use o Squid quando de conexões HTTPS (em > todas elas). > > Em suma, Proxy e Cache são coisas diferentes. Alguns sites não admitem > nenhum dos dois entre cliente e servidor!~ > > Bem, sei que ficou meio longa e generalista a resposta... Mas espero > ter conseguido responder sua pergunta. :) > > > Abraços! > > Jack > http://www.jack.eti.br > http://www.conexti.com.br > > > _______________________________________________ > Pfsense-pt mailing list > [email protected] > http://lists.pfsense.org/mailman/listinfo/pfsense-pt > -- Att. *Rodrigo Soares* (61) 9223-0014 Analista de Informática EMAIL: [email protected] MSN: [email protected] Twitter.com/RodrigosoaresTI Facebook.com.br/RodrigosoaresTI _______________________________________________ Pfsense-pt mailing list [email protected] http://lists.pfsense.org/mailman/listinfo/pfsense-pt _______________________________________________ Pfsense-pt mailing list [email protected] http://lists.pfsense.org/mailman/listinfo/pfsense-pt
