ETAPA 6: testar a conectividade do cliente DirectAccess por trás de um dispositivo NAT

  • Artigo

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Quando o cliente de DirectAccess é conectado à Internet por trás de um dispositivo NAT ou um servidor de proxy da web, o cliente do DirectAccess usa o Teredo ou o IP-HTTPS para se conectar ao servidor de Acesso Remoto.

Se o dispositivo NAT habilitar a porta UDP de saída 3544 para o endereço IP público do servidor de acesso remoto, o Teredo será usado. Se o acesso pelo Teredo não estiver disponível, o cliente do DirectAccess retornará para o IP-HTTPS pela porta TCP 443 de saída, que permite o acesso através de firewalls e servidores de proxy da web pela porta SSL tradicional.

Se o proxy da web pedir autenticação, a conexão do IP-HTTPS falhará automaticamente. As conexões do IP-HTTPS também falharão se o proxy da web realizar uma inspeção SSL de saída, devido ao fato de a sessão HTTPS ser encerrada pelo proxy da web em vez do servidor de Acesso Remoto. Nesta seção, você realizará os mesmos testes executados ao conectar-se usando uma conexão 6to4 da seção anterior.

Os procedimentos a seguir são executados em ambos os computadores cliente:

  1. Teste a conectividade Teredo. O primeiro conjunto de testes é executado quando o cliente DirectAccess é configurado para usar o Teredo. Esta é a configuração automática usada quando o dispositivo NAT permite acesso de saída à porta UDP 3544.

  2. Teste a conectividade IP-HTTPS. O segundo conjunto de testes é executado quando o cliente DirectAccess é configurado para usar IP-HTTPS. Para demonstrar a conectividade IP-HTTPS, o Teredo é desabilitada nos computadores cliente.

Dica

É recomendável limpar o cache do Internet Explorer antes de executar esses procedimentos para garantir que você está testando a conexão e não recuperando as páginas de site do cache.

Pré-requisitos

Antes de realizar esses testes, desconecte o CLIENT1 do comutador da Internet e conecte-o ao comutador da Rede doméstica. Se for perguntado que tipo de rede você pretende definir para a rede atual, selecione Rede Doméstica.

Inicie EDGE1 e EDGE2 se já não estiverem em execução.

Testar conectividade Teredo

  1. Em CLIENT1, abra uma janela elevada do Windows PowerShell, digite ipconfig /all e pressione ENTER.

  2. Examine o resultado do comando ipconfig.

    O CLIENT1 estará então conectado à Internet por trás de um dispositivo NAT e um endereço IPv4 privado será atribuído a ele. Quando o cliente do DirectAccess estiver atrás de um dispositivo NAT e receber um endereço IPv4 privado, a tecnologia de transição IPv6 preferida será Teredo. Ao observar o resultado do comando ipconfig, deverá ver uma seção indicando Pseudo-interface de criação de túneis Teredo do adaptador de túnel e a descrição Microsoft Teredo Tunneling Adapter com um endereço IP iniciando com 2001: conforme endereços Teredo. Se você não visualizar a seção do Teredo, habilite o Teredo com o seguinte comando: netsh interface Teredo set state enterpriseclient e, em seguida, execute novamente o comando ipconfig. Você não verá um gateway padrão listado para o adaptador de túnel Teredo.

  3. Na janela do Windows PowerShell, digite ipconfig /flushdns e pressione ENTER.

    Isso liberará as entradas de resolução de nome no cache do DNS do cliente que ainda poderiam existir de quando o computador estava conectado à Internet.

  4. 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 Remot; por exemplo, você pode executar o ping 2001:db8:1::2 neste exemplo.

  5. Na janela do Windows PowerShell, digite ping app1 e pressione ENTER. Você deverá ver as respostas do endereço IPv6 do APP1, 2001:db8:1::3.

  6. 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.

  7. Deixe a janela do Windows PowerShell aberta para o próximo procedimento.

  8. 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.

  9. Na barra de endereços do Internet Explorer, insira https://app2/ e pressione ENTER. Você verá o site padrão no APP2.

  10. 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 SMB para obter um recurso em um host somente IPv4.

Testar conectividade IP-HTTPS

  1. Abra uma janela elevada do Windows PowerShell, digite netsh interface teredo set state disabled e pressione ENTER. Isso desativa o Teredo no computador cliente e permite que o computador cliente configure a si mesmo para usar IP-HTTPS. Uma resposta Ok aparecerá quando o comando for concluído.

  2. Na janela do Windows PowerShell, digite ipconfig /all e pressione ENTER.

  3. Examine o resultado do comando ipconfig. Este computador estará então conectado à Internet por trás de um dispositivo NAT e um endereço IPv4 privado será atribuído a ele. O Teredo foi desabilitado e o cliente do DirectAccess retornará para o IP-HTTPS. Ao observar o resultado do comando ipconfig, você verá uma seção para o Adaptador de túnel iphttpsinterface com um endereço IP iniciado por 2001:db8:1:100 compatível com endereços IP-HTTPS com base no prefixo definido ao configurar o DirectAccess. Você não verá um gateway padrão listado para o adaptador de túnel IP-HTTPS.

  4. Na janela do Windows PowerShell, digite ipconfig /flushdns e pressione ENTER. Isso liberará as entradas de resolução de nome no cache do DNS do cliente que ainda poderiam existir de quando o computador estava conectado à rede corporativa.

  5. Na janela do Windows PowerShell, digite ping app1 e pressione ENTER. Você deverá ver as respostas do endereço IPv6 do APP1, 2001:db8:1::3.

  6. 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.

  7. 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.

  8. Na barra de endereços do Internet Explorer, insira https://app2/ e pressione ENTER. Você verá o site padrão no APP2.

  9. 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 SMB para obter um recurso em um host somente IPv4.