Esta seção contém as seguintes subseções, que descrevem recursos adicionais suportados pelos Serviços de Proxy:
Você pode programar downloads de arquivos HTML de um site Web para o cache local. Você pode baixar um URL, de vários URLs até um número especificado de links ou de um site inteiro na Web. Você pode especificar o download de lote para proxies HTTP inversos e de reencaminhamento. Contudo, o proxy inverso não baixará de links externos a um site.
Programe um download antes de o dia de trabalho começar para otimizar a utilização dos recursos de rede. A utilização do download em lote mantém o cache dos objetos atualizado para os usuários.
Os documentos HTML podem ter indicadores de applets Java incorporados, sem que você saiba disso.
Um applet Java é um programa que pode ser incluído em uma página em HTML. Quando você usa um browser compatível com Java para ver uma página que contenha um applet Java, o código do applet é transferido para o seu sistema e executado pelo browser.
Depois de o download do applet ser feito, ele pode consumir recursos do sistema em excesso, interferir em outros applets, inspecionar e mudar arquivos de clientes e estabelecer conexões de clientes não autorizados. Com o BorderManager, você pode habilitar o bloqueio Java e filtrar as páginas HTML recebidas para qualquer applet incorporado. Todos os applets são removidos do documento antes de esse documento entrar no sistema.
A autenticação do proxy para um servidor proxy pode ser feita de duas maneiras:
Se a autenticação reversa ou reencaminhamenot estiver habilitada e, além disso, o logon único e o SSL forem habilitados, o servidor proxy tentará primeiro autenticar o usuário através do logon único. Se essa tentativa falhar, o servidor proxy estabelecerá uma conexão SSL com o cliente e autenticará o usuário com um nome de usuário e uma senha do NDS.
Quando você usa o Novell Client 32, o logon único torna desnecessária a autenticação adicional do proxy depois de você logar no NDS.
Quando o cliente gera um pedido do browser, o servidor proxy verifica se o cliente está autenticado. Se ele não estiver autenticado, o servidor proxy solicitará que o cliente inicie uma autenticação de background para esse servidor. Todas as trocas de protocolo ocorrem no background, mas o usuário não precisa digitar um nome de usuário nem uma senha adicionais.
O logon único só tem êxito quando a máquina do cliente está executando o software Novell Client 32 e está logada no NDS. A máquina do cliente também precisa estar executando o DWNTRUST.EXE e o CLNTRUST.EXE. Esses arquivos estão localizados no diretório SYS:PUBLIC no servidor.
O logon único ocorre na porta 3024 no servidor. Se o logon único tiver sido habilitado no mesmo servidor BorderManager para o Gateway IP da Novell e o recurso Serviços de Proxy, será necessária somente uma autenticação de background para que um usuário utilize os dois serviços. Isso ocorre devido à porta compartilhada no servidor. Para que o logon único funcione, os firewalls de filtragem de pacotes no caminho de roteamento entre um cliente de gateway ou proxy e um servidor BorderManager precisam permitir que os pacotes designados para a porta 3024 sejam transmitidos.
Para obter informações sobre como utilizar o login único com o Gateway IP da Novell, consulte o "Visão geral e planejamento do gateway IP da Novell e do NAT (Network Address Translation)".
A autenticação SSL também elimina a necessidade de uma senha de proxy adicional. Para os clientes que estão executando o Novell Client 32, a autenticação usando o SSL é usado quando o logon único falha ou não está habilitado. Para os clientes não-Novell, o SSL é o principal método para que não haja a necessidade de enviar um nome de usuário e uma senha do NDS em texto sem criptografia.
O SSL garante comunicações privadas e seguras entre o browser e o servidor proxy, usando um sistema de criptografia por chaves pública-privada. Quando o cliente faz um pedido do browser, o servidor proxy responde solicitando que seja feita a autenticação usando um applet Java ou um formulário em HTML. Em resposta, o browser cria uma conexão SSL e envia o nome de usuário e a senha do NDS, criptografados através do SSL, para o servidor proxy. Esse servidor autentica o usuário com o NDS.
Para usar a autenticação SSL, gere um certificado para o servidor proxy, que é usado para configurar canais criptografados. O SSL do proxy exige o serviço SAS (Secure Authentication Service). Use o módulo snap-in Serviços PKI (Public Key Infrastructure) da Novell para o Administrador do NetWare a fim de mudar e criar certificados, objetos de material-chave e IDs-chave. Consulte a ajuda online do PKI para obter maiores informações.
Para obter informações sobre como utilizar o SSL e o Gateway IP da Novell, consulte o "Visão geral e planejamento do gateway IP da Novell e do NAT (Network Address Translation)".
O armazenamento hierárquico ICP no cache inclui os seguintes elementos:
Os servidores proxy mantêm conhecimentos uns sobre os outros através da utilização de topologias inteligentes de cache. O cache proxy hierárquico melhora a performance ao recuperar os dados do cache negativo e do primeiro acesso no servidor proxy mais próximo, sempre precisar recuperar esses dados no servidor Web de origem.
Você pode configurar o roteamento hierárquico no cache para melhorar a performance das perdas do cache local. São fornecidos dois sistemas de roteamento no cache: o sistema CERN em cascata de primeira geração e o cache hierárquico ICP (Internet Cache Protocol) de segunda geração.
O sistema CERN em cascata proporciona um reencaminhamento HTTP padrão através das cadeias de proxies. O sistema de cache hierárquico ICP proporciona um roteamento do cache avançado através de uma topologia de cache projetada. O protocolo ICP fornece o máximo de performance, escalabilidade e tolerância a falhas para o armazenamento no cache na Web na intranet e na Internet.
As hierarquias ICP são construídas nas vizinhanças dos serviços de cache proxy. Essas vizinhanças são formadas de pais e peers. Normalmente, o serviço de cache proxy local possui cinco vizinhos. Você pode definir vários pais para melhorar a performance e a tolerância a falhas. O protocolo ICP determina de forma dinâmica o fulfillment otimizado do cache na vizinhança. Ele também detecta automaticamente os vizinhos desativados e os recupera.
A diferença entre os peers e os pais consiste no fulfillment de objetos de URLs que não são armazenados no cache da vizinhança. Somente os pais podem ser solicitados para obter um URL para a vizinhança. A estratégia básica de fulfillment ICP é obter um objeto armazenado no cache da vizinhança do vizinho mais otimizado (aquele que responder primeiro com um acerto de cache) e obter objetos URL perdidos para a vizinhança e seu cache local do pai mais otimizado (aquele que responder primeiro com a rota do cache preferencial).
Observe a seguir algumas diretrizes básicas para a topologia de vizinhança ICP:
O protocolo ICP (Internet Cache Protocol) é um formato de mensagens baseado em UDP, usado para comunicações entre caches proxy. O ICP é usado em uma malha de caches para localizar objetos Web nos caches da vizinhança. Os caches trocam consultas e respostas ICP para selecionar o melhor local de onde um objeto será recuperado. Quando esse local é determinado, o objeto é recuperado usando o proxy HTTP.
Quando uma consulta é recebida, primeiro o cache verifica o cache local, depois envia consultas ICP para seus vizinhos. Os vizinhos retornam consultas ICP indicando um acerto ou erro. Dependendo das respostas, o proxy acessa o vizinho pai para recuperar o objeto do servidor de origem. Por padrão, o BorderManager não está configurado para enviar consultas através de uma hierarquia da Web.
Os vizinhos podem ser configurados como grupos multicast. Um grupo multicast é uma lista de endereços em que o servidor ICP recebe consultas IP multicast. Um pedido de informações pode ser enviado para um grupo multicast.
O servidor ICP está configurado com uma lista de grupos multicast ou endereços que participarão dos pedidos ICP. O cliente ICP está configurado com a lista de respondentes, uma lista de todos os vizinhos aceitáveis (uma lista unicast) que pode responder a uma consulta multicast. Isso permite que o cliente ICP verifique se as respostas são de um vizinho válido. O cliente controla os respondentes e os vizinhos multicast.
A configuração de grupos multicast reduz o congestionamento de tráfego e o tempo de configuração. Com grupos multicast, você não precisa configurar cada vizinho separadamente e os vizinhos não enviam vários pacotes.
Se ocorrer um erro de cache, o proxy usará o tempo de ida e volta para determinar se o pedido precisará ser enviado para um pai ou para o servidor de origem. Para calcular o tempo de ida e volta da origem, o proxy envia uma consulta ICMP (Internet Control Message Protocol) ao servidor de origem e aos caches pais. O proxy usa a rota que retorna o menor tempo de ida e volta.
O roteamento de domínios ICP é usado para regular o tráfego ICP com base nos domínios de hosts. A distribuição geográfica dos caches vizinhos poderia determinar que alguns domínios podem ser melhor servidos por um cache do que por outros. Ao configurar clientes ICP, você pode associar cada vizinho a uma lista de domínios de rotas que ele servirá. Isso aumenta o tempo de resposta, melhora a eficiência e reduz o tráfego da rede.
Por exemplo, a configuração a seguir está sendo usada:
Neighbor host1 parent http_port=8080 icp_port=3130 .com .net .au .deNeighbor host2 parent http_port=8080 icp_port=3130 .edu .milNeighbor host3 parent http_port=8080 icp_port=3130
Nesse exemplo, as consultas dos domínios raiz .com, .net, .au e .de são reencaminhadas para o host1 ou host3. As consultas de .edu e .mil são reencaminhadas para o host2 ou host3. As consultas de todos os outros domínios são reencaminhadas para o host3. As consultas ICP não serão enviadas para um vizinho se ele não servir ao domínio de host URL solicitado.
A configuração padrão é nula, ou seja, todos os vizinhos recebem todas as consultas. Você pode configurar os vizinhos para processarem consultas para um ou mais domínios na lista de domínios.
O controle de acesso ICP é configurado no servidor ICP e é usado para verificar se os proxies estão autorizados a enviar um pedido. Você pode configurar uma lista de clientes permitidos (ou clientes que podem enviar o pedido ICP). O controle de acesso ICP é separado do controle de acesso do BorderManager.