Windows 7 e Windows Server 2008 R2

  • Artigo

BranchCache e DirectAccess: aprimorando a experiência da filial

Gary Olsen

Enquanto as massas unwashed finalmente tem seu espiada primeira no Windows Server 2008 R2 e Windows 7, escolhido aquelas tem trabalhado com o código do candidato (RC) versão desde maio e liberação para fabricação (RTM) versão desde agosto. Qualquer grupo estiver no, você provavelmente tem sido inundada com atenção. Talvez você foi convidado para uma visualização do Windows 7 “ casa festa ”, como eu, por exemplo. (Meu son-in-law hospedado um, mas somente porque ele queria software gratuito da Microsoft.) Mesmo se foram dispensados que atenção principal, você não pôde ter evitado cada vários relatórios de mídia Exaltando ou questionamento novos recursos desses produtos, tanto do qual são de uma nova árvore de código e constituem OSes novo.

BranchCache e DirectAccess, comprovadamente os jewels Coroa uma dessas liberações valem sua atenção. Com BranchCache, a Microsoft pretende dar ramificação funcionários as experiências mesmas trabalhar com arquivos como seus colegas no escritório corporativo. Com DirectAccess, a Microsoft visa usuários remotos conectando redes corporativas por meio de redes virtuais privadas (VPNs).

Como é normal com a Microsoft, somente obter boa coisas sobre novos produtos. Nesse caso, você pode implementar apenas BranchCache e Windows 7 clientes e servidores 2008 R2. Let’s dê uma olhada aprofundada cada um desses novos recursos.

BranchCache

BranchCache melhora a experiência de escritório filial pelo cache comumente usados arquivos localmente, nas estações de um Windows Server 2008 R2 servidor ou usuário trabalho, em vez de forçar os usuários para acessar arquivos via centralmente compartilhamentos de rede localizado. BranchCache é interessante, mas existem advertências.

IT pode implantar BranchCache no modo de cache distribuído ou no modo de Cache Hosted (consulte do Figura 1). IT configura o modo via diretiva de grupo, portanto, usando o modo hospedado em um escritório e modo distribuído no outro requer implementação duas diretivas e planejamento estruturas de unidade organizacional (OU) de acordo. A Microsoft recomenda a implantação de modo de cache distribuído em sites de 50 ou menos clientes, mas ele dependerá de velocidade e a largura de banda do link WAN, bem como outros fatores. Modo de cache distribuído exigirá discos rígidos maiores e talvez a memória e outros recursos, para em algum ponto que seja mais vantajoso usar o modo de Cache Hosted, especialmente se houver um servidor de R2 2008 existente no site. Além disso, o modo de cache distribuído só pode trabalhar em uma sub-rede local. Portanto, se houver várias sub-redes em um site, um cliente em cada sub-rede terá para cache de arquivo para outros usuários nessa sub-rede baixá-lo. No entanto, modo de Cache Hosted pode servir várias sub-redes no site, portanto, que seria outro motivo para escolha modo de cache hospedados.

Figura 1 da ramificação office podem usar BranchCache nos modos distribuídos ou hospedados.

No Distributed modo em cache, nenhum servidor de arquivo reside na filial. Em vez disso, através de diretiva, todas as máquinas de usuário são clientes BranchCache, isto é, todos eles têm a capacidade de cache de documentos que outras pessoas no site da filial podem baixar — se elas estiverem a versão atual.

Por exemplo, digamos let’s Caroline solicita um documento Reports.docx de um servidor de arquivo habilitado para BranchCache no site central. BranchCache envia metadados que descrevem o conteúdo do arquivo. Hashes nos metadados são usados para pesquisar o conteúdo na sub-rede local. Se não for encontrado, uma cópia é armazenada em cache na unidade local do seu computador. Posteriormente no dia, Tyler precisa modificar Reports.docx, portanto, ele contata o compartilhamento no servidor de arquivo escritório principal para obter uma cópia para editar. O servidor de arquivo retorna os metadados e, em seguida, o cliente procura conteúdo, que localiza no e downloads de Caroline computador. Isso é feito com segurança usando uma chave de criptografia derivada de hashes nos metadados. O próximo dia Abigail precisa modificar esse mesmo documento. O processo é o mesmo, mas ela irá abrir a cópia em cache no computador de Tyler. Novamente, as informações de versão são mantidas no servidor. Os clientes contatam o servidor para determinar se há uma cópia da versão mais recente no seu site.

Este é um dos três BranchCache cenários que entram no reproduzir como usuários trabalhar com vários documentos. Os dois são:

  • Um trabalho de escritório filial solicita que o servidor de arquivo do escritório principal para um documento que não está armazenada em cache em um computador local. O usuário recebe uma cópia, é armazenadas em cache localmente.
  • Um trabalho de escritório filial solicita que o servidor de arquivo para um documento em cache no site local, mas o computador é desligado. O cliente obtém uma nova cópia do servidor de arquivo e armazena em cache em seu PC. Solicitações futuras levam a isso a cópia mais recente em cache.

Em cada caso, os documentos também salvam para o servidor de arquivo do escritório principal. Dessa forma, se Caroline voltar e quiser acessar o documento mas computador de Abigail, que abriga a versão mais recente agora está desativada, ela receberá o documento do servidor do escritório principal.

Com o modo de Cache Hosted, IT configura um servidor de arquivo do Windows 2008 R2 na filial com BranchCache instalando recurso BranchCache e configurando uma diretiva de grupo para informar os clientes para usar o modo de cache hospedados. O procedimento descrito para o modo de cache distribuído funciona da mesma aqui, mas os arquivos são armazenados em cache em um servidor BranchCache configurado localmente em vez de computadores ’ usuários.

Observação: os metadados conteúdo mantidos pelo servidor de arquivos no site central o office é enviado para cada cliente quando um arquivo é solicitado a partir de um servidor ativado BranchCache. Isso é usado para determinar se qualquer cliente local ou servidor (dependendo de qual cache do modo usado) tem a cópia mais recente.

O servidor BranchCache habilitado no site da filial pode ser usado para outros propósitos, como um servidor Web ou o WSUS. Considerações especiais devem ser feitas nesses casos e está descrito na Guia de implantação do Microsoft BranchCache do Windows Server 2008 e Guia das Microsoft BranchCache primeiras a adotar.

Configuração de BranchCache

Para configurar BranchCache, você precisará compreender como os GPOs (GPOs) funcionam e como configurá-los na sua estrutura de OU para afetar os computadores em cada site. Lembre-se de que todos os servidores envolvidos no cenário BranchCache devem ser Windows Server 2008 R2 e todos os clientes Windows 7. Aqui é o processo:

Etapa 1. Instale o recurso de BranchCache via Gerenciador de servidores.

 

Etapa 2. Se você estiver usando BranchCache em um servidor de arquivos, você precisará instalar a função de serviços de arquivo, bem como BranchCache para arquivos remotos (consulte do Figura 2).

Figura 2 BranchCache A instalação requer Habilitando os serviços de arquivo e BranchCache para funções de arquivos remotos.

Etapa 3. Configure um GPO BranchCache. Vá para o computador | diretivas | modelos administrativos | rede | BranchCache. Você verá cinco configurações possíveis:

  • Ativar BranchCache. Isso tem que ser habilitado para todos os BranchCaching (consulte do Figura 3). Observe que habilitar BranchCache sem ativar configurações de diretiva de modo Distributes ou Hosted Cache faz com que o cliente Windows 7 local para arquivos de cache localmente. Isso é útil se vários usuários usam um computador.

     

Figura 3 in o GPMC, habilitar BranchCache para cache de escritório filial.

  • BranchCache conjunto distribuído de modo de cache. Isso se aplica a todos os clientes no GPO.
  • Define o modo de cache hospedados BranchCache. Especifique um servidor para hospedar o cache. Essas funções são mutuamente exclusivas. Somente um pode ser configurado para o site.
  • Configure BranchCache para arquivos de rede. Se não configurada ou desabilitada, isso define um limite de latência de 80ms. Se a solicitação de arquivo leva mais de 80ms, o arquivo irá para o cache. Habilitar essa configuração e altere o valor de latência como desejado.
  • Definir Porcentagem de espaço em disco usada para cache de computador cliente. Isso é definido por padrão em 5 % do disco do usuário. Você terá de brincar com isso obter a quantidade correta para atendendo cache versus dando o espaço do usuário necessário. Isso pode ser um problema se você tiver configurações de disco variam amplamente em tamanho, como alguns terão maior capacidade de cache que outros.

Set Disk Space

 

Etapa 4. Configure configuração “ LanMan Server ” na diretiva de BranchCache GPO. Na mesma área do GPO na etapa 3, vá para a configuração LanMan servidor e examinar as propriedades para a “ hash a publicação para BranchCache ”. São três opções:

  • Não permitir a publicação de hash em todas as pastas compartilhadas.
  • Permitir a publicação de hash para todas as pastas compartilhadas.
  • Permitir a publicação de hash somente para pastas compartilhadas no qual BranchCache é ativado.

Servidores que estejam executando a função de servidor de serviços de arquivos em servidores de 2008 R2, desejados para ser servidores conteúdo BranchCache, também devem executar BranchCache para função de serviços de arquivos de rede e publicação de hash deve ser ativada. BranchCache também é habilitada individualmente em compartilhamentos de arquivo. A publicação de hash pode ser habilitada individualmente em um servidor (como uma configuração de servidor fora do domínio) ou em grupos de servidores por meio da diretiva de grupo. Assim, BranchCache pode ser ativada em todas as pastas compartilhadas, algumas pastas compartilhadas ou totalmente desativada.

 

Etapa 5. Configure a configuração do GPO no Firewall do Windows para permitir entrada porta TCP 80 (aplicadas ao computador cliente).

Etapa 6. Depois de configurar tudo, e se existe o compartilhamento de arquivo com arquivos ’ usuários, vá ao Gerenciador do servidor | File Services | gerenciamento de armazenamento e compartilhamento. O painel central lista os compartilhamentos. Clique com o botão direito do mouse no compartilhamento, selecione propriedades e clique em Avançado. Na guia cache, habilitar BranchCache (consulte do Figura 4). Observação: Se a opção BranchCache não estiver disponível, o recurso BranchCache não foi instalado corretamente ou a diretiva é definida para desabilitar, como indicado anteriormente.

Figura 4 Ativar compartilhamento com BranchCache usando controles de gerenciamento de armazenamento e compartilhamento de arquivo .

Configuração de cliente de BranchCache

Por padrão, todos os clientes do Windows 7 estão ativados para BranchCache, significando que não há nada para habilitar o próprio cliente. No entanto, há etapas relacionadas ao cliente que são necessárias:

  • Definir as configurações do firewall. Enquanto isso foi observado anteriormente, há outros requisitos para o modo de cache hospedados. Consulte documentos BranchCache da Microsoft observado no final deste artigo.
  • Os clientes devem estar em uma OU que contém uma diretiva que permite BranchCache e define qual modo de cache a ser usado. Novamente, consulte os documentos no final deste artigo para obter mais detalhes.

BranchCache: O bom

Aqui está o que gosto sobre BranchCache:

  • Ele pode usar o sistema de transferência inteligente em segundo plano (BITS) para permitir transferências de arquivo em segundo plano se o usuário está conectado, mesmo se o aplicativo termina. Este é um ótimo recurso para escritórios de filiais conectados em links lentos. Uma reinicialização do sistema deve ser necessária, transferência de arquivo continua uma vez que for concluída. Para este trabalho, claro, aplicativos devem ser escritos para tirar proveito do BITS.
  • BranchCache é configurável por meio do utilitário de linha de comando Netsh e é bem documentado em Site de BranchCache no Windows Server R2 do TechNet.
  • Você pode monitorar o desempenho de BranchCache através de contadores para o cliente, servidor de arquivo e o host de cache. Não só são essas úteis para diagnóstico de desempenho quanto Posso dizer, assistindo esses contadores é a única maneira de ver se o cliente realmente está obtendo uma cópia em cache.
  • O ambiente BranchCache é controlável via diretiva de grupo.

BranchCache: O mau

BranchCache certamente têm seu lugar mas tome cuidado com essas desvantagens:

  • Porque o modo de cache distribuído essencialmente transforma cada estação de trabalho em um servidor de arquivos, máquinas cliente hospedagem muitos arquivos acessados com freqüência podem sofrer acertos de desempenho. Isso será necessário alguns testes para determinar o impacto real.
  • Em alguns casos, os clientes podem exigir espaço em disco adicional para permitir tamanhos de cache suficientes.
  • Clientes cache agora vai ser competindo com colegas para recursos de rede.
  • Atrasos podem cortar durante o processo inicial de cache ou quando um arquivo não está disponível no cache. Somente Windows 7 clientes e servidores Windows Server 2008 R2 podem participar, portanto, uma distribuição completa desse recurso pode levar algum tempo.

Se você pode justificar colocando um servidor de arquivos na filial, por que não usar compartilhamentos de arquivos distribuídos (DFS)? Em vez de mexam arquivos em cache ao redor, você pode usar o Distributed File System-DFS-R (replicação) para replicar os arquivos e manter um namespace com o DFS. Você pode encontrar vantagens cache os arquivos de rede e talvez BranchCache funcionará em compartilhamentos DFS. Ou, talvez você encontrará alguns limites de desempenho onde o cache é mais eficiente do que o DFS-r. Por outro lado, o impacto no servidor para BranchCache seria menor do que uma configuração de DFS completo. O ponto é que você terá que estudar a suas necessidades e examinar as opções disponíveis com BranchCache. Claro, cada ambiente é diferente e o que pode causar problemas em alguns ramificação escritórios não em outros. Não há uma um resposta direita para todas as situações.

DirectAccess

Com DirectAccess, a Microsoft aborda a experiência VPN ruim usuários tiveram desde o Windows 2000, mesmo com muitos aprimoramentos desde a implementação inicial. Um cliente configurado DirectAccess pode acessar um site da intranet de um local remoto sem precisar estabelecer um vínculo VPN manualmente. Além disso, muito para seu prazer, equipes IT podem gerenciar máquinas remotas através de uma conexão com a Internet em vez de através da VPN. Mesmo sem DirectAccess, um usuário remoto pode aproveitar o novo recurso VPN reconexão automática. Assim, se Estou trabalhando em casa, conectado à intranet da minha empresa e o link Internet cai, a VPN será restabelecer a conexão quando a Internet se torna disponível — sem pestering me reconectar e reinserir minhas credenciais como teria fazer — geralmente repetidamente — sem DirectAccess.

Na verdade, do ponto de vista do usuário, DirectAccess é invisível. Quando um usuário em um cliente habilitado clica no link de intranet, DirectAccess manipula a conexão e desconexão. Os usuários não precisam abrir o Gerenciador de conexões, insira suas credenciais, aguardar a conexão e assim por diante.

Enquanto a conexão remota é ao vivo, o usuário tem uma configuração “ divisão encapsulamento ” por padrão (consulte do Figura 5). Isso permite acesso simultâneo para a intranet, rede local (para uso de dispositivos como impressoras) e a Internet. Em um cenário típico de VPN sem encapsulamento dividida, conectando-se à Internet significa saltem primeiro na intranet e passando através do gateway de rede corporativa para conectividade. Além disso, não tenho nenhum acesso a minha rede local, embora as soluções alternativas são possíveis. Então, novamente, DirectAccess foi projetado para dar ao usuário remoto uma mais “ no escritório ” experiência que propicia VPN tradicional.

 

Figura 5 DirectAccess permite uma configuração de encapsulamento dividida para simultânea conectividade com a rede corporativa e a Internet.

De TI perspectiva, quando o computador estiver na Internet (Lembre-se de que DirectAccess está sempre ativado se ele estiver instalado), patches, diretivas e outras atualizações são fácil — e seguro via conexões IPsec — aplicar.

Requisitos de DirectAccess

Em uma configuração básica de DirectAccess, servidor DirectAccess é na rede de borda, fornecer conectividade de usuário remoto a recursos internos, incluindo os servidores de aplicativo, autoridades de certificação (CAs), os DNS e controladores de domínio (DCs). Servidores de CAs e o aplicativo devem ser configurados para aceitar o tráfego IPv6. Aqui estão os componentes essenciais de uma configuração de DirectAccess:

  • O domínio do Active Directory DirectAccess clientes só poderá acessar Windows 2008 ou 2008 R2 DCs.
  • Definições de diretiva de grupo devem impor configurações de DirectAccess para:
    • Identifica clientes DirectAccess.
    • Configure a tabela de diretivas de resolução de nome (NRPT).
    • Remova o Intra-Site Automatic encapsulamento endereços Protocol (ISATAP) da lista de restrição global DNS.
  • O servidor DirectAccess deve:
    • Ser membro do domínio do Active Directory.
    • Execute no Windows Server 2008 R2.
    • Tem dois adaptadores de rede configurado (uma para intranet e outro para conectividade com a Internet).
    • Ter dois consecutivos estáticos endereços IPv4 externamente resolvível.
  • Instalado com gerenciamento DirectAccess “ recurso ” (via Server Manager) e executar para configuração do Assistente de instalação.

 

  • O servidor Web/IIS permite a funcionalidade que determina se os recursos da intranet são acessíveis. Servidores de aplicativo devem ser configurados para permitir acesso por clientes ativados para DirectAccess.
  • Para uso com a CA necessária, instale serviços de certificados do Active Directory e emitir certificados para autenticação.
  • Tanto um nativo IPv6 rede transição tecnologias ou devem estar disponível em toda a intranet.
  • Usando diretivas IPsec para DirectAccess conexão criptografia e autenticação segura, o cliente autentica antes do usuário fizer logon.
  • Você pode encontrar exceções de firewall necessárias na Guia das Microsoft DirectAccess primeiras a adotar.

Como você pode ver, DirectAccess não é para os medrosos coração. O requisito de IPv6 sozinho sem dúvida irá disparar preocupação — e exigir a maioria das organizações para implementar tecnologias de transição — mas 2008 R2 tem os componentes. Além disso, você precisa ativar a segurança por meio de uma infra-estrutura de chave pública (PKI), fornecer serviços de autenticação e configurar a identificação de IPv6 para servidores de aplicativo. Antes de executar o Assistente de instalação DirectAccess, você tem também configurar os grupos de segurança, estabelecer diretivas de firewall, a instalação do DNS e concluir um número de outros pré-requisitos.

Servidor de DirectAccess

O servidor DirectAccess executa um número de funções definidas pelo Assistente de instalação de DirectAccess do Gerenciador de servidores (consulte do Figura 6).

Figura 6 DirectAccess iniciar a instalação através do Server Manager.

O Assistente DirectAccess executa quatro tarefas essenciais. O assistente irá:

  1. Identifica clientes ser habilitado DirectAccess. Você pode listar grupos de segurança de outros domínios ou florestas aqui, se as confianças são configuradas. Você deve definir grupos de segurança apropriado antes de executar o assistente.
  2. Defina conectividade e segurança (certificados) para o servidor DirectAccess. Você identificará a interface de rede que está no lado da Internet e que conecta à intranet. Instalar a CA e criar certificados antes de executar o Assistente para instalação de DirectAccess. Além disso, defina diretiva de cartão inteligente.
  3. Identificar o DNS DC e, opcionalmente, gerenciamento e outros servidores de infra-estrutura para usam no ambiente DirectAccess. Você também deve identificar um servidor altamente disponível como servidor de rede local. O servidor DirectAccess pode preencher essa função.
  4. Identifica os servidores de aplicativo configurados para aceitar conexões de clientes DirectAccess. O padrão não é nenhuma autorização adicional de ponta a ponta, mas você pode selecionar opções de segurança baseada em diretiva IPsec.

DNS e o NRTP

Conforme observado anteriormente, DirectAccess clientes podem acessar a intranet diretamente. Para habilitar isso, você deve implementar NRPT, que define os servidores DNS por espaço para nome DNS em vez de por interface de rede. Acho que isso como forma encaminhamento condicional funciona no Windows 2003 e servidores DNS 2008, onde você pode definir espaços para nome DNS com o endereço IP apropriado para se conectar ao servidor. NRPT permite que um cliente evitar iteração DNS normal e vá diretamente para o servidor DirectAccess.

Aqui está como o NRPT funciona (consulte do Figura 7):

  1. Uma solicitação de consulta de nome corresponde a um namespace configurado para a intranet corporativa, apontando para o servidor DirectAccess.
  2. O NRPT contém o endereço IP e totalmente qualificado FQDN do servidor DirectAccess (nome de domínio). Quando o endereço IP é usado, a conexão para o servidor DNS é criptografada para uma conexão segura.
  3. Quando o FQDN é usado, ele deve ser resolvido através da Internet e localizar o servidor DNS corporativo.
  4. Se o cliente envia uma solicitação de resolução de nomes para um espaço para nome não definido no NRPT (como www.microsoft.com), em seguida, ele segue resolução normal através da Internet

Figura 7 NRPT the permite a definição dos servidores DNS por espaço para nome DNS em vez de por interface.

 

NRPT é configurado durante a instalação de DirectAccess na página instalação do Infrastructure Server e o assistente preenche o endereço IPv6 do servidor DNS. Nome de diretiva de resolução, uma nova diretiva de grupo definindo para 2008 R2, define as configurações de diretiva específicas, como IPsec, servidor DNS e como a fallback de resolução de nome ocorre quando o namespace não está na rede consultada. Você encontrará isso do computador | configurações do Windows | diretiva de resolução de nome (Observe, você deve inserir espaços para nome de domínio com um ponto à esquerda “. ”— Por exemplo,. emea.corp. NET).

Você pode expor NRPT conteúdo usando o comando Netsh: nome do Netsh Mostrar diretiva.

Isso mostrará os espaços para nome definidos.

Exclusões de firewall

Exclusões de firewall serão dependem de como implementar rede IPv6 e se você usar as tecnologias de transição. Além disso, qualquer arquivo ou aplicativo servidores que clientes remotos devem se conectar ao precisará ele configurado adequadamente. Figura 8 e Figura 9 , abaixo, Mostrar firewall exclusões para firewall nos lados da Internet e intranet do servidor DirectAccess, respectivamente. Obviamente, você só precisará definir exclusões para tecnologias que estão usando. (Observe que embora a Figura 9 lista IPv4 + NAT-PT, não é implementada pelo Windows 2008 R2.)

 

Figura 8 do configurações de firewall para o firewall de Internet

Tecnologia de transição Protocolo para permitir
Teredo UDP 3544
6to4 Protocolo IP 41
IP HTTPS TCP 443
IPv6 nativo ICMPv6, protocolo 50

 

 

Figura 9 do configurações de firewall para o firewall de intranet

 

   
 
 
   
   
 

 

Conectividade - IPv6

Porque IPv6 permite que clientes DirectAccess mantenham conectividade contínua para recursos na rede corporativa, elas devem todas executar o protocolo. Mesmo se você tiver uma rede IPv6 totalmente implementada, permitindo que a conectividade remota pode exigir o uso de uma tecnologia de transição que permitiria que o cliente DirectAccess para se conectar a recursos de IPv4, encapsulando IPv6 dentro de pacotes IPv4. Essas tecnologias incluem 6to4, IP HTTPS e Teredo. ISATAP também é uma tecnologia de encapsulamento, mas somente é usado internamente. Não entrarei em descrições detalhadas aqui, mas do Figura 10 mostra as opções de conectividade básica.

 

Figura 10 preferencial opções de conexão para clientes DirectAccess

 

Se o cliente for atribuído a: Método conectividade preferencial:
Endereço IPv6 roteável globalmente Endereço IPv6 roteável globalmente
Endereço IPv4 público 6to4
Endereço particular IPv4 (NAT) Teredo
Se o cliente não conseguir conectar usando acima IP HTTPS

Origem: Os

No lado da intranet, sem IPv6 nativo, DirectAccess permite o uso de ISATAP, que gera um endereço IPv6 de um endereço IPv4 e implementa seu próprio descoberta de vizinho. Uso ISATAP ativado DirectAccess clientes acessar recursos em uma rede IPv4. Por exemplo, quando um cliente ISATAP for inicializado, ele deve localizar um roteador. Ele faz isso emitindo uma consulta DNS para ISATAP. < nome do domínio >. Isso para corp. NET ele ficaria para ISATAP.corp. NET. Windows 2008 DNS implementa GlobalQueryBlockList, um recurso de segurança adicionais que inclui ISATAP por padrão. Isso faz com que ele ignorar qualquer solicitação ISATAP. < nome do domínio >. Portanto, você deve limpar ISATAP na lista. Isso através do comando DNSCMD ou fazendo uma entrada de registro.

Em um prompt de comando, digite dnscmd /config /globalqueryblocklist wpad de e pressione ENTER. Isso irá definir o GlobalQueryBlockList como tendo apenas WPAD nele (assim removendo ISATAP). Você também pode fazer isso indo para a chave do registro a

HKLM:\System\Current controle Set\Services\DNS\Parameters. Do GlobalQueryBlockList editar e remover ISATAP.

Você também pode implementar 6to4 individualmente em hosts ou sobre uma rede inteira e transmitir pacotes IPv6 em uma rede IPv4. Curiosamente, 6to4 é implementado para uma rede inteira, ela requer apenas um endereço IPv4. Ele não oferece suporte ao tráfego entre hosts somente IPv6 e IPv4.

Teredo também fornece pacotes IPv6 para ser roteado para redes IPv4, mas é usado quando o cliente está atrás de um servidor de conversão de endereços de rede (NAT) não está configurado para IPv6. Armazena pacotes IPv6 no datagrama IPv4 que permite encaminhamento de NAT.

Windows 7 e Server 2008 R2 implementou um protocolo chamado IP-HTTPS encapsulamentos pacotes IPv6 em um HTTPS IPv4. Enquanto IP HTTPS tem um desempenho inferior que outros protocolos, você pode adicionar servidores IP HTTPS adicionais para melhorar o desempenho um pouco. IP HTTPS é um protocolo bastante fácil habilitar para obter conectividade de rede IPv6 via IPv4 para trabalhar.

Ao projetar a configuração do cliente DirectAccess, você pode usar DNS e o NRPT para separar o tráfego de Internet e intranet, ou você pode usar algo chamado forçar encapsulamento e forçar todo o tráfego através do encapsulamento. Força encapsulamento, que requer IP HTTPS, habilitada via configuração de computador Configuration\Policies\Administrative Administrativos\Rede\Conexões Connections\Route todo tráfego através da rede interna de diretiva de grupo. Esta diretiva seria necessário aplicar a clientes DirectAccess. Observei anteriormente que DirectAccess clientes podem acessar recursos locais enquanto estiver conectado à intranet. Isso ainda mantém true para clientes IP HTTPS, mas se o usuário tenta acessar sites da Internet, por exemplo, ele poderia ser roteado através da intranet.

Certamente o requisito de IPv6 e configurações complexas são desvantagens para DirectAccess mas aqueles são facilmente compensadas por melhorias de experiência do usuário e facilidade de gerenciamento de cliente remoto para IT.

Excelente Promise

O número de trabalhadores remotos ser eles em uma ramificação, em um escritório em casa ou em trânsito, aumentando. BranchOffice e DirectAccess mantenha promessa excelente para filial e outros funcionários remotos e gerentes de TI e administradores seria aconselhável investigá-los. Nem desses será uma configuração rápida e fácil, e há um número de opções e recursos que estão disponíveis. Além disso, esses recursos só funcionarão no Windows 7 clientes e servidores Windows Server 2008 R2, portanto, isso definitivamente impacto sobre um cronograma de implementação. Gerentes de TI e administradores seria aconselhável estudar a documentação da Microsoft disponível e configurar um laboratório de teste para garantir o sucesso.

Conteúdo relacionado

 

Gary Olsené um engenheiro de software de sistemas da HP Worldwide técnico Expert Center (WTEC) para serviços da Hewlett-Packard em Atlanta, Ga. e trabalhou no setor de TI desde 1981. Além sendo um MVP do Directory Services, ele é fundador/presidente do Atlanta Active Directory Users Group e é um colaborador assíduo Redmond revista .