Direct Access - Fehlersuche
Die Tatsache, dass bei Direct Access viele Komponenten zusammen spielen und in den meisten Fällen irgendwas nicht geht, nutzen wir wieder unser Bild vom Anfang um exemplarisch ein paar Fehlerquellen aufzuzeigen und indirekt damit die Funktionsweise erneut in Erinnerung zu rufen.
Prüfpunkte
Das Bild zeigt noch Windows 2008R2 mit allen verschiedenen Tunneloptionen und dem UAG als Hilfsmittel für NAT64/DNS64.
Hier folgt die Beschreibung zu den Fehlern:
Position | Beschreibung | Erledigt |
---|---|---|
0 |
Ehe Sie in die Untiefen von Direct Access einsteigen, sollten Sie die einfachen Dinge prüfen:
|
|
1 |
Windows 7 mit
Windows 2008R2
versuchen eine
Verbindung per
6to4 und Teredo. Aber auch da kann einiges schief gehen:
|
|
2 |
Der Einsatz von Teredo erfordert eine Erreichbarkeit über UDP-Port 3544. Es gibt nicht wenige Provider und auch DSL-Router (Hier besonders AVM Fritz!Box), die diesen Zugriff aus "Sicherheitsgründen" blockieren. |
|
3 |
Bei einer direkten IPv4 Verbindung, wie sie z.B. mit einer UMTS-Karte im Notebook vorhanden sein kann, kommt 6to4 zum Einsatz. Auch hier blocken diverse Provider gerne die erforderlichen ICMP-Ports. Insbesondere der Rückweg vom DA-Server zum Client wird hier oft verhindert. Sie können das mit NETMON auf dem Server und dem Client schön sehen. |
|
4 |
Der Direct Access Server muss natürlich aus dem Internet ansprechbar sein. Insbesondere wenn eine Firewall "davor" steht, passiert es immer wieder, dass nicht alle Ports geöffnet sind. Gerade Teredo, welches auch die zweite IP anspricht, wird gerne übersehen. Prüfen Sie die Firewall-Logs auf blockierte Pakete.
|
|
5 |
Über die Erreichbarkeit des NLS-Servers findet der Client heraus, ob er intern ist oder nicht. Der NLS-Server darf also unter gar keinen umständen von extern erreichbar sein und muss von intern erreichbar sein. Fällt er aus, haben auch interne Clients Probleme. Ist der externe Client an einem Provider oder Firmen-LAN angeschlossen, die jeden Namen erfolgreich auflösen und auf eine Suchseite umlenken (z.B. Telekom Navigationshilfe oder WLAN-Provider), dann wird Direct Access hoffentlich das fehlerhafte oder fehlende Zertifikat bemerken. |
|
6 |
Schon bei Fehler 1 habe ich auf die Wichtigkeit der CRL hingewiesen, insbesondere beim Einsatz einer internen CA. DA ist sicher und erfordert daher die CRL-Prüfung. Sie sollten diese Funktion daher eventuell redundant auslegen. |
|
7 |
Beim Einsatz einer internen CA werden oft eigene Templates angelegt, die z.B. länger als 1 Jahr gültig sind. Stellen Sie sicher, dass die ausgestellten Computerzertifikate auch für DA tauglich sind. Alle Computerzertifikate sollten von der gleichen CA ausgestellt werden. |
|
8 |
Die komplette Konfiguration von DA erfolgt über Gruppenrichtlinien. Sowohl die Clients als auch die Server erhalten so ihre Einstellungen. Verzögerungen oder Fehler bei der AD-Replikation und dem Abgleich von "SYSLOG" über den Windows FRS können die Umsetzung verzögern. Natürlich muss ein Computer nach der Aufnahme in die Gruppe einmal gestartet werden, um seine neue Mitgliedschaft zu erkennen und die GPO anzuwenden. |
|
9 |
DA erlaubt nur den Zugriff auf IPv6 Dienste und Server bzw. Server, die über Tunnel (ISATAP) erreichbar sind. Aber auch dann muss IPv6 erst mal sauber funktionieren. Die DAClients sind nämlich im Gegensatz zu RRAS in einem eigenen Subnetz. IPv6 Router Advertising (RA) muss funktionieren oder Sie pflegen statisch Leitwege. |
|
10 |
Natürlich darf nicht vergessen werden, dass die DNS-Server, die vom Client für die "interne Domain" verwendet werden, per IPv6 erreichbar sein müssen. |
|
11 |
Das Zertifikat auf dem Client ist natürlich mit eine der Schlüsselkomponenten einer DA-Konfiguration. Es muss von einer internen CA ausgestellt sein, die richtigen Namen im Subject bzw. SAN haben, damit der DA-Server im Active Directory das Computerobjekt finden kann. Normalerweise laufen Computer-Zertifikate auch nach einem Jahr mit einem 6 Wochen Renew-Windows ab. Das kann durchaus eine Herausforderung für Client sein, die länger unterwegs sind. Ein angepasstes Template kann hier ratsam sein. Und weil die 11 der einzige Fehler am Client ist sei hier auch noch mal erwähnt, dass Direct Access nur mit Windows 7 Enterprise/Ultimate funktioniert. Zudem sollte der Dienst "IKE- und AuthIP IPsec-Schlüsselerstellungsmodule" automatisch gestartet werden:
|
|
Es gibt noch eine ganze Reihe weiterer Fehler und Problemfälle, die ich aber nicht alle aufführen kann. Mit NETMON, PING, Traceroute und etwas Erfahrung im Troubleshooting mit Eventlog und anderen Werkzeugen sollten sie auch ihre Direct Access-Umgebung zum Laufen bekommen.
Fehlersuche von Hand (Windows 2008)
Wenn Sie verstanden haben, wie Direct Access "tickt", dann ist die Fehlersuche relativ schnell möglich. Ich gehe mal von der aus meiner Sicht häufigsten Konfiguration aus:
- Zuerst sucht Direct Access
nach der angegebenen URL um
heraus zu finden, ob er intern
oder extern ist
ist er intern, dann kommt DA nicht zu Einsatz - Namensauflösung
DA nutzt abhängig von der NRPT-Tabelle entweder die internen oder externen DNS-Server. Ein "PING" auf z.. www.google.de sollte eine externe IP-Adresse auflösen.
Auf dem Direct Acces Server gibt es auch die "Monitoring"-Seite, die schnell anzeigt, welche Dienste gerade in Benutzung sind. Sind wie hier alle Dienste "Gelb", dann sind diese bereit aber gerade nicht aktiv. Sobald sich ein Client verbindet, wird die Anzeige grün. Dann lohnt es sich auch über "Details" letztlich den Windows Performance Monitor zu starten, um eine numerische Anzeige zum ausgewählten Protokoll zu erhalten.
Diese Anzeige ist nicht mehr verfügbar, wenn Sie parallel auch UAG installiert haben. Dann müssen Sie die Status-Webseite von UAG nutzen, die dann aber auch anzeigt, welche Benutzer wie angemeldet sind.
Fehlersuche mir NetSH
Weniger bekannt ist die Funktion per NetSH ein passendes Trace-File zu erstellen. Folgende Schritte sind dazu erforderlich, um auf dem Client den Trace zu erstellen
-
CMD-Shell als Administrator öffnen
Dies können und sollten Sie sowohl auf dem Client als auch dem Server ausführen. Noch wissen wir ja nicht, wo der Fehler ist -
Eingabe von
netsh trace start scenario=directaccess capture=yes report=yes
Damit starte ich den Trage - Problem wieder reproduzieren. Nur so landen dann auch die gewünschten Ausgaben im Trace. Ich hoffe, dass sie das Problem auch immer wieder leicht nachstellen können.
- Test-Funktionen ausführen
Protokollieren Sie sich bitte den Zeitpunkt der Aktion mit, um später im Log die Zuordnung zu vereinfachen- DNS-Cache leeren, um auch die
Namensauflösung zu triggern.
"ipconfig /flushdns" - IP-Helper durchstarten
net stop iphlpsvc && net start iphlpsvc - Gewünschtes Ziel über den Namen "anpingen"
Damit wird eine Namensauflösung über DNS64 und eine IP.Umsetzung (NAT64) gestartet - Gewünschten Service ansprechen.
z.B.: einen Dateiserver o.ä.
- DNS-Cache leeren, um auch die
Namensauflösung zu triggern.
- Trace beenden
Das geht wieder mit "net stop trace"
NetSH schreibt die gesammelte Daten nach files in the %LOCALAPPDATA%\Temp\NetTraces\NetTrace.cab
Die Trace-Datei können Sie z.B.: zu Microsoft senden oder auch selbst auspacken und untersuchen.
Hilfreiche PowerShell-Commandlets
Mittlerweile gibt es auch für Direct Access entsprechende Befehle in der PowerShell
- Get-DAClientExperienceConfiguration
https://docs.microsoft.com/en-us/powershell/module/directaccessclientcomponent/get-daclientexperienceconfiguration?view=win10-ps
Zeigt auf dem Client die aktuelle Konfiguration an. So sehen Sie schnell, ob überhaupt eine Konfiguration vorhanden ist. Sie sehen auch den "WebProbeHost", den der Client prüft, um den Erfolg zu kontrollieren - Get-NetIPHttpsConfiguration
https://docs.microsoft.com/en-us/powershell/module/networktransition/get-netiphttpsconfiguration?view=win10-ps
Damit sehen Sie die DirectAccess-Gegenstelle, die vom Client genutzt wird. - Get-NetIPHttpsState
https://docs.microsoft.com/en-us/powershell/module/networktransition/Get-NetIPHttpsState?view=win10-ps
DirectAccess mit Windows 2012 nutzt nur noch IPHTTPS und keine andere Tunneltechnik mehr. Damit sehen Sie sofort, ob der Tunnel etabliert wurde. - Get-DnsClientNrptPolicy
https://docs.microsoft.com/en-us/powershell/module/dnsclient/get-dnsclientnrptpolicy?view=win10-ps
Der DNS-Client löst je nach Ziel den Namen über einen anderen DNS-Server auf. Hier sollten Sie dann ihre interne Domain finden, die zur IPv6-Adresse des DNS64-Service des DA-Servers verweist. Ausnahmen, die nicht durch den Tunnel sollen, sind ohne DNS-Server eingetragen. - Resolve-DnsName <interner Servername>
https://docs.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname?view=win10-ps
Damit wird der DNS-Client ihres Computers unter Nutzung der NRPT-Tabelle gefragt und sollte eine IPv6-Adresse liefern, ggfls. umgesetzt durch NAT64. PING sollte auch die Adresse auflösen. NSLOOKUP/DIG etc liefern falsche Werte, da die NRPT nicht genutzt wird.
Damit sollte auch auf dem Client schnell ein erster Überblick möglich sein.
Weitere Links
- Tools für Troubleshooting
Direct Access :
Event Viewer
http://technet.microsoft.com/en-us/library/ee624055(WS.10).aspx - 7 easy steps
to help
troubleshoot
Direct Access
clients.
http://www.windowsnetworking.com/articles_tutorials/7-Steps-Troubleshooting-Direct Access-Clients.html - Direct
Access-Server
mit Teredo nicht
erreichbar
http://technet.microsoft.com/de-de/library/ee844188(WS.10).aspx - Direct
Access-Client
ermittelt eine
Internetverbindung
bei einer
Intranet-Verbindung
http://technet.microsoft.com/de-de/library/ee844105(WS.10).aspx - [Direct Access]
Part 5:
Troubleshooting
guide für Direct Access
http://www.nomizo.fr/2013/07/Direct Access-part-5-troubleshooting.html -
Troubleshooting
DirectAccess
Manage Out
Connections
http://blogs.technet.com/b/privatecloud/archive/2013/04/01/troubleshooting-directaccess-manage-out-connections.aspx -
Top 5
DirectAccess
Troubleshooting
PowerShell
Commands
https://directaccess.richardhicks.com/2017/07/10/top-5-directaccess-troubleshooting-powershell-commands/