ETAPA 5: testar a conectividade do DirectAccess pela Internet e por meio do cluster
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Agora, o CLIENT1 está pronto para testar o DirectAccess.
Testar a conectividade do DirectAccess pela Internet. Conectar CLIENT1 à Internet simulada. O cliente recebe endereços IPv4 públicos quando é conectado à Internet simulada. Quando um cliente do DirectAccess recebe um endereço IPv4 público, ele tenta estabelecer uma conexão com o servidor de Acesso Remoto usando uma tecnologia de transição IPv6.
Testar a conectividade do cliente do DirectAccess por meio do cluster. Testar a funcionalidade do cluster. Antes de começar a testar, é recomendável desligar EDGE1 e EDGE2 por pelo menos cinco minutos. Há vários motivos para isso, que incluem os tempos limite de cache de ARP e as alterações relacionadas ao NLB. Ao validar a configuração do NLB em um laboratório de teste, você precisará ser paciente, pois as alterações na configuração não afetarão a conectividade imediatamente, apenas determinado tempo depois. É importante considerar isso quando você realizar as tarefas a seguir.
Dica
É recomendável que você limpe o cache do Internet Explorer antes de realizar este procedimento e cada vez que testar a conexão por meio de um servidor de Acesso Remoto diferente para verificar se está testando a conexão e não recuperando as páginas da Web do cache.
Testar a conectividade do DirectAccess pela Internet
Desconecte CLIENT1 do comutador corpnet e conecte-o ao comutador da Internet. Aguarde 30 segundos.
Na janela de privilégios elevados do Windows PowerShell, digite ipconfig /flushdns e pressione ENTER. Isso libera entradas de resolução de nome no cache de DNS do cliente de quando o computador estava conectado à rede corporativa.
Na janela do Windows PowerShell, digite Get-DnsClientNrptPolicy e pressione ENTER.
O resultado mostra as configurações atuais da NRPT (Tabela de Políticas de Resolução de Nomes). Essas configurações indicam que todas as conexões com .corp.contoso.com devem ser resolvidas pelo servidor DNS de Acesso Remoto com o endereço IPv6 2001:db8:1::2. Observe também a entrada de NRPT indicando uma exceção para o nome nls.corp.contoso.com. Nomes na lista de exceção não são respondidos pelo servidor DNS de Acesso Remoto. Você pode executar o ping do endereço IP do servidor DNS de Acesso Remoto para confirmar se há conectividade com o servidor de Acesso Remoto; por exemplo, você pode executar o ping 2001:db8:1::2.
Na janela do Windows PowerShell, digite ping app1 e pressione ENTER. Você deve ver as respostas do endereço IPv6 para APP1, que nesse caso é 2001:db8:1::3.
Na janela do Windows PowerShell, digite ping app2 e pressione ENTER. Você deverá ver as respostas do endereço assinado NAT64 pelo EDGE1 para APP2, que neste caso é fdc9:9f4e:eb1b:7777::a00:4.
A capacidade de executar ping no APP2 é importante, pois o sucesso nesse caso indica que você conseguiu estabelecer uma conexão usando NAT64/DNS64, pois APP2 é um recurso somente IPv4.
Deixe a janela do Windows PowerShell aberta para o próximo procedimento.
Abra o Internet Explorer, digite https://app1/ na barra de endereços e pressione ENTER. Você verá o site de IIS padrão no APP1.
Na barra de endereços do Internet Explorer, insira https://app2/ e pressione ENTER. Você verá o site padrão no APP2.
Na tela Iniciar, digite\\App2\Files e, em seguida, pressione ENTER. Clique duas vezes no arquivo Novo Documento de Texto.
Isso demonstra que você conseguiu se conectar a um servidor somente IPv4 usando o SMB para obter um recurso no domínio de recursos.
Na tela Iniciar, digite wf.msc e pressione ENTER.
No console Firewall do Windows com Segurança Avançada, observe que somente o Perfil público ou o Privado está ativo. O Firewall do Windows deve estar habilitado para que o DirectAccess funcione corretamente. A conectividade do DirectAccess não funcionará se o Firewall do Windows estiver desabilitado.
No painel esquerdo do console, expanda o nó Monitoramento e clique no nó Regras de Segurança de Conexão. Você deve ver as regras de segurança de conexão ativas: DirectAccess Policy-ClientToCorp, DirectAccess Policy-ClientToDNS64NAT64PrefixExemption, DirectAccess Policy-ClientToInfra e DirectAccess Policy-ClientToNlaExempt. Role o painel central para a direita para mostrar as colunas 1º Métodos de autenticação e 2º Métodos de autenticação. Observe que a primeira regra (ClientToCorp) usa Kerberos V5 para estabelecer o túnel da intranet e a terceira regra (ClientToInfra) usa NTLMv2 para estabelecer o túnel de infraestrutura.
No painel esquerdo do console, expanda o nó Associações de segurança e clique no nó Modo principal. Observe as associações de segurança de túnel de infraestrutura usando NTLMv2 e a associação de segurança de túnel da intranet usando o Kerberos V5. Clique com o botão direito do mouse na entrada que mostra Usuário (Kerberos V5) como o 2º Método de autenticação e clique em Propriedades. Na guia Geral, observe que a Segunda ID local de autenticação é CORP\User1, indicando que User1 foi capaz de se autenticar com êxito no domínio CORP usando o Kerberos.
Testar a conectividade do cliente do DirectAccess por meio do cluster
Execute um desligamento normal no EDGE2.
Você pode usar o Gerenciador de Balanceamento de Carga de Rede para exibir o status dos servidores ao executar esses testes.
Em CLIENT1, na janela do Windows PowerShell, digite ipconfig /flushdns e pressione ENTER. Isso libera entradas de resolução de nomes que ainda podem existir no cache de DNS do cliente.
Na janela do Windows PowerShell, execute ping em APP1 e APP2. Você deve receber respostas dos dois recursos.
Na tela Iniciar, digite \\app2\files. Você deve ver a pasta compartilhada no computador APP2. A capacidade de abrir o compartilhamento de arquivos no APP2 indica que o segundo túnel, que exige autenticação Kerberos para o usuário, está funcionando corretamente.
Abra o Internet Explorer e os sites https://app1/ e https://app2/. A capacidade de abrir os dois sites confirma que o primeiro e o segundo túneis estão funcionando. Feche o Internet Explorer.
Inicie o computador EDGE2.
Em EDGE1, execute um desligamento normal.
Aguarde 5 minutos e retorne para CLIENT1. Execute as etapas 2 a 5. Isso confirma que CLIENT1 foi capaz de fazer failover de forma transparente para EDGE2 depois que EDGE1 ficou indisponível.