Table of contents
TOC
Minimera innehållsförteckningen
Maximera innehållsförteckningen

STEG 5 testet DirectAccess-anslutningen från Internet och via klustret

James McIllece|Senast uppdaterad: 2017-03-10
|
1 Medverkande

Gäller för: Windows Server 2016

KLIENT1 är nu klar för testning av DirectAccess.

  • Testa DirectAccess-anslutningen från Internet. Anslut KLIENT1 till det simulerade Internet. När du är ansluten till det simulerade Internet tilldelas klienten offentliga IPv4-adresser. När en DirectAccess-klient har tilldelats en offentlig IPv4-adress, försök att upprätta en anslutning till fjärråtkomstservern med hjälp av en IPv6-överföringsteknik.

  • Testa anslutningen för DirectAccess-klienten via klustret. Testa funktionerna i klustret. Vi rekommenderar att du stänger av både EDGE1 och EDGE2 i minst fem minuter innan du börjar testning. Det finns ett antal orsaker till detta, som omfattar ARP-cache-timeout och ändringar på NLB. Vid validering av NLB-konfiguration i en testmiljö, måste du bli patient som ändringar i konfigurationen inte omedelbart återspeglas i anslutning till en viss tidsperiod har förflutit. Detta är viktigt att tänka på när du utför följande åtgärder.

    Tips

    Vi rekommenderar att du har rensat Internet Explorer innan du utför den här proceduren och varje gång du testa anslutningen via en annan fjärråtkomstserver och kontrollera att du testar anslutningen och inte hämta webbsidorna från cacheminnet.

Testa DirectAccess-anslutningen från Internet

  1. Koppla från KLIENT1 från växeln corpnet och anslut den till Internet-växeln. Vänta i 30 sekunder.

  2. I en upphöjd Windows PowerShell-fönster, skriver ipconfig/flushdns och tryck på RETUR. Detta tömmer name resolution poster som kan finnas kvar i cacheminnet på DNS-klienten från när klientdatorn anslöts till corpnet.

  3. I fönstret Windows PowerShell anger Get-DnsClientNrptPolicy och tryck på RETUR.

    Utdata visas de aktuella inställningarna för den principen tabell NRPT (Name Resolution). Dessa inställningar anger att alla anslutningar till. corp.contoso.com ska lösas av Remote Access DNS-servern med IPv6-adressen 2001:db8:1::2. Tänk också på NRPT-post som visar att det finns ett undantag för namnet nls.corp.contoso.com; namn på listan över undantag besvaras inte Remote Access DNS-servern. Du kan pinga Remote Access DNS-server IP-adress för att bekräfta anslutningar till RAS-servern. Du kan till exempel pinga 2001:db8:1::2.

  4. I fönstret Windows PowerShell anger ping app1 och tryck på RETUR. Du bör se svar från IPv6-adressen för APP1, som i det här fallet är 2001:db8:1::3.

  5. I fönstret Windows PowerShell anger ping Prog2 och tryck på RETUR. Du bör se svaren från NAT64 adressen som tilldelas av EDGE1 APP2, som i det här fallet är fdc9:9f4e:eb1b:7777::a00:4.

    Möjligheten att pinga Prog2 är viktigt eftersom lyckade visar att du kunde upprätta en anslutning med NAT64/DNS64 Prog2 är en enda resurs IPv4.

  6. Lämna fönstret Windows PowerShell öppen för nästa procedur.

  7. Öppna Internet Explorer, i adressfältet i Internet Explorer, ange http://app1/ och tryck på RETUR. Du ser standard IIS-webbplats på APP1.

  8. Ange i adressfältet i Internet Explorer http://app2/ och tryck på RETUR. Standardwebbplats visas på Prog2.

  9. På den Start skriver\\App2\Files, och tryck sedan på RETUR. Dubbelklicka på filen nya textdokument.

    Detta visar att du kunde ansluta till en enda IPv4-server använder SMB för att erhålla en resurs i resursdomänen.

  10. På den Start skriverwf.msc, och tryck sedan på RETUR.

  11. I den Windows-brandväggen med avancerad säkerhet konsolen, Observera att endast de privata eller publika profilen är aktiv. Windows-brandväggen måste aktiveras för DirectAccess ska fungera korrekt. DirectAccess-anslutningen fungerar inte om Windows-brandväggen är inaktiverad.

  12. I den vänstra rutan i konsolen expanderar den övervakning noden och klicka på den anslutningssäkerhetsregler noden. Du bör se aktiva anslutningssäkerhetsregler: principen DirectAccess-ClientToCorp, principen DirectAccess-ClientToDNS64NAT64PrefixExemption, principen DirectAccess-ClientToInfra, och principen DirectAccess-ClientToNlaExempt. Rulla den mittersta rutan till höger för att visa den 1 autentiseringsmetoder och 2 autentiseringsmetoder kolumner. Observera att den första regeln (ClientToCorp) använder Kerberos V5 för att upprätta intranättunneln tredje regeln (ClientToInfra) används NTLMv2 upprätta infrastrukturtunneln.

  13. I den vänstra rutan i konsolen expanderar den säkerhetsassociationer noden och klicka på den huvudläge noden. Observera infrastruktur tunnel säkerhetsassociationer med NTLMv2 och säkerhetsassociation för intranät tunnel med Kerberos V5. Högerklicka på posten som visar användare (Kerberos V5) som den 2 autentiseringsmetod och klicka på egenskaper. På den allmänna, fliken, meddelande i andra autentiseringen lokalt ID för den är CORP\User1, som anger att User1 kunde autentisera CORP domänen med hjälp av Kerberos.

Testa anslutningen för DirectAccess-klienten via klustret

  1. Utföra en korrekt avslutning på EDGE2.

    Du kan använda i Utjämning av nätverksbelastning för att visa status för servrarna när du kör dessa tester.

  2. Skriv på KLIENT1 i fönstret Windows PowerShell ipconfig/flushdns och tryck på RETUR. Detta tömmer name resolution poster som kan finnas kvar i klienten DNS-cachen.

  3. Pinga APP1 och Prog2 i Windows PowerShell-fönster. Du bör få svar från båda dessa resurser.

  4. På den Start skriver\\app2\files. Du bör se den delade mappen på datorn Prog2. Möjlighet att öppna filresursen på Prog2 anger att andra tunneln, vilket kräver Kerberos-autentisering för användaren, fungerar korrekt.

  5. Öppna Internet Explorer och öppna webbplatser som http://app1/ och http://app2/. Möjlighet att öppna båda webbplatserna bekräftar att både de första och andra tunnlarna är uppåt och fungerar. Stäng Internet Explorer.

  6. Starta datorn EDGE2.

  7. Utföra en korrekt avslutning på EDGE1.

  8. Vänta fem minuter och sedan gå tillbaka till KLIENT1. Utföra steg 2 – 5. Det bekräftar att KLIENT1 kunde transparent växlas över till EDGE2 när EDGE1 inte blev tillgänglig.

© 2017 Microsoft