Partilhar via


Implantar o acesso remoto em um cluster

O Windows Server 2016 e o Windows Server 2012 combinam o DirectAccess e a VPN de RAS (Serviço de Acesso Remoto) em uma única função de Acesso Remoto. O Acesso Remoto pode ser implantado em diversos cenários corporativos. Esta visão geral fornece uma introdução ao cenário corporativo para implantar servidores de Acesso Remoto multissite em uma carga de cluster balanceada com o NLB (Balanceamento de Carga de Rede) do Windows ou com um ELB (balanceador externo de carga), como F5 Big-IP.

Descrição do cenário

A implantação de um cluster reúne diversos servidores de Acesso Remoto em uma única unidade, que então atua como um ponto único de contato para computadores cliente remotos que se conectam por meio do DirectAccess ou VPN à rede corporativa interna utilizando o endereço IP virtual (VIP) externo do cluster de Acesso Remoto. A carga de tráfego para o cluster é balanceada utilizando o NLB do Windows ou com um balanceador externo de carga (como o F5 Big-IP).

Pré-requisitos

Antes de começar a implantar este cenário, examine esta lista de requisitos importantes:

  • Balanceamento de carga padrão por meio do Windows NLB.

  • Há suporte para balanceadores de carga externos.

  • O modo unicast é o padrão e o modo recomendado para NLB.

  • Não há suporte para alteração de políticas fora do console de gerenciamento do DirectAccess ou dos cmdlets do PowerShell.

  • Quando é usado NLB ou um balanceador externo de carga, o prefixo IPHTTPS não pode ser alterado para algo diferente de /59.

  • Os nós balanceados para carga devem estar na mesma sub-rede do IPv4.

  • Em implantações ELB, se houver necessidade de gerenciamento externo, os clientes DirectAccess não poderão usar Teredo. Apenas IPHTTPS pode ser usado para comunicação de ponta a ponta.

  • Certifique-se de que todos os hotfixes NLB/ELB conhecidos estejam instalados.

  • Não há suporte para ISATAP na rede corporativa. Se você estiver usando ISATAP, remova-o e use o IPv6 nativo.

Neste cenário

O cenário de implantação de cluster inclui diversas etapas:

  1. Implantar um servidor VPN Always On com opções avançadas. Um único servidor de Acesso Remoto com configurações avançadas deve ser implantado antes de configurar uma implantação de cluster.

  2. Planejar uma implantação de cluster de acesso remoto. Para criar um cluster de uma implantação de servidor único, várias etapas adicionais são necessárias, incluindo preparar certificados para a implantação de cluster.

  3. Configurar um cluster de acesso remoto. Isso consiste em uma série de etapas de configuração, incluindo preparar o servidor único para NLB do Windows ou o balanceador externo de carga, preparar servidores adicionais para ingressar no cluster e habilitar o balanceamento de carga.

Aplicações práticas

Reunir diversos servidores em um cluster de servidor fornece:

  • Escalabilidade. Um único servidor de acesso remoto fornece um nível limitado de confiabilidade de servidor e de desempenho escalável. Ao agrupar os recursos de dois ou mais servidores em um único cluster, você aumenta a capacidade para número de usuários e taxa de transferência.

  • Alta disponibilidade. Um cluster fornece a alta disponibilidade para acesso sempre contínuo. Se um servidor no cluster falhar, os usuários remotos podem continuar acessando a rede corporativa por meio de um servidor diferente no cluster. Todos os servidores no cluster possuem o mesmo conjunto de endereços IP virtuais (VIP) de cluster, ao mesmo tempo que mantêm endereços IP exclusivos e dedicados para cada servidor.

  • Facilidade de gerenciamento. Um cluster permite o gerenciamento de diversos servidores como uma entidade única. As configurações compartilhadas podem ser facilmente definidas no servidor de cluster. As configurações de acesso remoto podem ser gerenciadas por meio de qualquer um dos servidores no cluster ou remotamente utilizando as RSAT (Ferramentas de Administração de Servidor Remoto). Além disso, todo o cluster pode ser monitorado a partir de um único console de Gerenciamento de Acesso Remoto.

Funções e recursos incluídos neste cenário

A tabela a seguir lista funções e recursos necessários para o cenário:

Função/recurso Como este cenário tem suporte
Função Acesso Remoto A função é instalada e desinstalada pelo console Gerenciador do Servidor. Essa função engloba o DirectAccess, que era anteriormente um recurso no Windows Server 2008 R2 e Serviços de Roteamento e Acesso Remoto (RRAS) que eram anteriormente um serviço de função sob a função de servidor de Serviços de Acesso e Política de Rede (NPAS). A função Acesso Remoto consiste em dois componentes:

– A VPN Always On e a VPN de Serviços de Roteamento e Acesso Remoto (RRAS) – O DirectAccess e VPN são gerenciados juntos no console de Gerenciamento de Acesso Remoto.
– Roteamento de RRAS – Os recursos de roteamento de RRAS são gerenciados no console de Roteamento e Acesso Remoto legado.

As dependências são as seguintes:

– Servidor Web de IIS (Serviços de Informações da Internet) – Este recurso é necessário para configurar o servidor de local de rede e a investigação da Web padrão.
– Banco de Dados Interno do Windows – Utilizado para contabilização local no servidor de acesso remoto.

Recurso Ferramentas de Gerenciamento de Acesso Remoto Este recurso é instalado da seguinte maneira:

– Ele é instalado por padrão em um servidor de acesso remoto quando a função acesso remoto for instalada e oferece suporte a interface do usuário do console de Gerenciamento remoto.
– Ele pode ser instalado opcionalmente em um servidor que não esteja executando a função de servidor de acesso remoto. Neste caso, ele é usado para gerenciamento remoto de um computador de Acesso Remoto que executa o DirectAccess e VPN.

O recurso de Ferramentas de Gerenciamento de Acesso Remoto consiste em:

– GUI de acesso remoto e ferramentas de linha de comando
– Módulo de acesso remoto para o Windows PowerShell

As dependências incluem:

– Console de Gerenciamento de Política de Grupo
– Kit de administração do Gerenciador de Conexões de RAS (CMAK)
– PowerShell 3.0 do Windows
– Ferramentas e Infraestrutura de Gerenciamento Gráfico

Network Load Balancing Este recurso fornece o balanceamento de carga em um cluster utilizando o NLB do Windows.

Requisitos de hardware

Os requisitos de hardware para este cenário incluem o seguinte:

  • Pelo menos dois computadores que atendam aos requisitos de hardware para Windows Server 2012.

  • Para o cenário do balanceador externo de carga, é necessário hardware dedicado (ou seja, BigIP F5).

  • Para testar o cenário, você deve ter pelo menos um computador executando o Windows 10 configurado como um cliente VPN Always On.

Requisitos de software

Há diversos requisitos para este cenário:

  • Requisitos de software para implantação de servidor único. Para saber mais, confira Implantar um único servidor do DirectAccess com configurações avançadas. Um único Acesso Remoto).

  • Além dos requisitos de software para um servidor único, há diversos requisitos específicos de cluster:

    • Em cada servidor de cluster IP-HTTPS, o nome de assunto do certificado deve corresponder ao endereço ConnectTo. Uma implantação de cluster dá suporte para uma mistura de certificados de caractere curinga e sem caractere curinga em servidores de cluster.

    • Se o servidor de local de rede estiver instalado no servidor de Acesso Remoto, em cada servidor de cluster, o certificado do servidor de local de rede deve ter o mesmo nome de assunto. Além disso, o nome do certificado do servidor de local de rede não deve ter o mesmo nome de nenhum servidor na implantação do DirectAccess.

    • Certificados de IP-HTTPS e de servidor de local de rede devem ser emitidos utilizando o mesmo método com que o certificado para o servidor único foi emitido. Por exemplo, se o servidor único usar uma CA (Autoridade de Certificação) pública, então todos os servidores no cluster deverão ter um certificado emitido por uma CA pública. Ou se o servidor único utilizar um certificado autoassinado para IP-HTTPS, então todos os servidores no cluster deverão fazer o mesmo.

    • O prefixo de IPv6 atribuído a computadores cliente do DirectAccess em clusters de servidores deve ser de 59 bits. Se a VPN estiver habilitada, o prefixo da VPN também deve ser de 59 bits.

Problemas conhecidos

Os problemas a seguir são conhecidos quando se configura um cenário de cluster:

  • Depois de configurar o DirectAccess em uma implantação somente IPv4 com um único adaptador de rede e depois que o DNS64 padrão (o endereço IPv6 que contém ":3333::") for configurado automaticamente no adaptador de rede, a tentativa de habilitar o balanceamento de carga por meio do console de Gerenciamento de Acesso Remoto faz com que um prompt para o usuário forneça um DIP IPv6. Se for fornecido um DIP IPv6, ocorrerá falha na configuração depois de clicar em Confirmar com o erro: O parâmetro está incorreto.

    Para resolver o problema:

    1. Baixe os scripts de backup e restauração em Fazer Backup e Restauração da Configuração de Acesso Remoto.

    2. Faça backup dos seus GPOs de acesso remoto usando o script Backup-RemoteAccess.ps1 baixado

    3. Tente habilitar o balanceamento de carga até a etapa em que ocorre a falha. Na caixa de diálogo Habilitar Balanceamento de Carga, expanda a área de detalhes, clique com o botão direito do mouse na área de detalhes e, em seguida, clique em Copiar Script.

    4. Abra o Bloco de Notas e cole o conteúdo da área de transferência. Por exemplo:

      Set-RemoteAccessLoadBalancer -InternetDedicatedIPAddress @('10.244.4.19 /255.255.255.0','fdc4:29bd:abde:3333::2/128') -InternetVirtualIPAddress @('fdc4:29bd:abde:3333::1/128', '10.244.4.21 /255.255.255.0') -ComputerName 'DA1.domain1.corp.contoso.com' -Verbose
      
    5. Feche todas as caixas de diálogo de Acesso Remoto abertas e feche o console de Gerenciamento de Acesso Remoto.

    6. Edite o texto colado e remova os endereços IPv6. Por exemplo:

      Set-RemoteAccessLoadBalancer -InternetDedicatedIPAddress @('10.244.4.19 /255.255.255.0') -InternetVirtualIPAddress @('10.244.4.21 /255.255.255.0') -ComputerName 'DA1.domain1.corp.contoso.com' -Verbose
      
    7. Em uma janela elevada do PowerShell, execute o comando da etapa anterior.

    8. Se o cmdlet falhar durante a execução (não devido a valores de entrada incorretos), execute o comando Restore-RemoteAccess.ps1 e siga as instruções para certificar-se de que a integridade da sua configuração original seja mantida.

    9. Agora é possível abrir o console de Gerenciamento de Acesso Remoto novamente.