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 na Web para o cache local. Você pode fazer download de um URL, de vários URLs até um número especificado de links ou de um site inteiro na Web. Pode também especificar downloads em lote para proxies HTTP de reencaminhamento ou inversos. No entanto, o proxy inverso não fará download de links que sejam 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 em HTML podem ter indicadores de applets Java embutidos neles, sem que você tenha conhecimento.
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 ativar o bloqueio do Java e filtrar as páginas em HTML recebidas para qualquer applet embutido. 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 direta ou inversa do proxy estiver ativada, o servidor proxy tentará primeiro autenticar o usuário através de um 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ó é bem-sucedido quando a máquina do cliente está executando o software Novell Client 32 e logou 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 ativado 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 devem permitir que os pacotes designados para a porta 3024 sejam transmitidos.
Para obter informações sobre o uso do logon único com o Gateway IP da Novell, consulte o Capítulo 4, "Visão Geral e Planejamento do Gateway IP da Novell e do NAT (Network Address Translation)".
A autenticação com o SSL também elimina a necessidade de uma senha adicional de proxy. Para os clientes que estão executando o Novell Client 32, o protocolo SSL é usado quando o logon único falha ou não está ativado. 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 não-codificado.
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 usar o protocolo SSL e o Gateway IP da Novell, consulte o Capítulo 4, "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 conhecimento da utilização de topologias de cache inteligentes uns dos outros. O armazenamento hierárquico no cache proxy melhora a performance, recuperando o acesso inicial e os dados do cache negativo do servidor proxy próximo otimizado, sem precisar recuperar esses dados a partir do 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: CERN em cascata de primeira geração e armazenamento hierárquico no cache 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 em 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 peers e pais está no fulfillment dos objetos URL que não são armazenados no cache na 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 a partir 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 a partir do pai mais otimizado (aquele que responder primeiro com a rota do cache preferencial).
Observe a seguir algumas diretrizes básicas para a topologia da vizinhança ICP:
O protocolo ICP (Internet Cache Protocol) é um formato de mensagens baseado em UDP, usado para comunicações entre caches proxy. Ele é usado em uma rede em malha de caches para localizar os objetos Web armazenados nos caches vizinhos. Os caches trocam consultas e respostas ICP para selecionar o melhor local a partir 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 deverá ser enviado para um pai ou para o servidor de origem. Para calcular o tempo de ida e volta, o proxy envia uma consulta ICMP (Internet Control Message Protocol) para o servidor de origem e os caches pai. 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 do host. 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 .de
Neighbor host2 parent http_port=8080 icp_port=3130 .edu .mil
Neighbor 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 está configurado no servidor ICP e é usado para verificar se os proxies podem 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.