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:

  • Windows Firewall
    Die Windows Firewall muss auf den Clients aber auch den Servern gestartet sein
  • Client-Versionen
    Funktioniert nur der eine Client nicht oder alle Clients ?. Vielleicht ist es doch nur ein Notebook, der mit der vorinstallierten Windows Version in Betrieb genommen wurde anstatt die Enterprise Version zu erhalten
  • IP-Verbindung
    Hat der Client wirklich eine funktionierende IP-Verbindung zum Internet. Diverse Hotspots haben eine vorgeschaltete Anmeldeseite. Ohne TunnelMode sollten Sie jede Adresse außerhalb ihres eigenen DNS-Domäne auflösen und erreichen können.
  • Lokale Firewall/Filter
    Heute gehört es schon zum guten Ton, dass auch Virenscanner auf dem Client per IP-Filtertreiber oder Protokoll-Proxy in die Kommunikation einschalten. Diverse Exchange Server wurden so schon daran gehindert per Port 25 Mails zu senden, obwohl sie wirklich kein Virus sind. Aber auch auf dem Clients gibt es solche Wunderdinge, die Directaccess stören.

1

Windows 7 mit Windows 2008R2 versuchen eine Verbindung per 6to4 und Teredo.
Windows 2008 und höher versuchen per Default nur noch IPHTTPS

Aber auch da kann einiges schief gehen:

  • DNS-Auflösung
    Zuerst muss der Client natürlich den konfigurierten DA-Zugriffspunkt auflösen können. Beachten Sie, dass die zweite IP-Adresse des DA-Servers hierfür genutzt wird. Testen Sie die Erreichbarkeit einfach per Browser oder Telnet auf Port 443 des Servers
  • NRPT-Ausschluss
    Normalerweise schließt der Assistent alleine diesen Namen in der NRPT-Tabelle aus. Gerade bei Split-DNS-Umgebungen sollten Sie dies aber auf jeden Fall noch mal prüfen.
  • Zertifikatname
    Das auf dem DA-Server installierte Zertifikat muss natürlich auf den Namen ausgestellt sein. Auch das können Sie von extern mit einem Browser prüfen
  • CRL-Erreichbarkeit
    und natürlich möchte der Client die passende CRL prüfen. Gerade wenn sie kein öffentliches Zertifikat sondern ein privates Zertifikat verwenden, muss die interne CA korrekt konfiguriert und veröffentlicht sein.
  • HTTP-Proxy
    Der Zugriff vom DA-Client über HTTPS funktioniert auch über Proxies aber nur, wenn diese keine Authentifizierung erfordern. Zugänge wie Hotspots, bei denen Sie per Browser sich anmelden und danach keine weitere Anmeldung kommt, sind erst dann auch nutzbar.
  • Client Zertifikat
    Zuletzt fordert zumindest die Installation von UAG dem Client auch ein Zertifikat ab. Wer eine interne CA mit eigenen Templates verwendet, muss hier auf die oben bei IPHTTTPTUNNEL genannten Punkte aufpassen

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.

  • 6to4
    ICMPv6 Echo in beide Richtungen.
  • Teredo
    Nutzt UDP 3544 auf beide IP-Adresse
  • IPHTTPSTunnel
    Nutzt 443 auf die zweite IP-Adresse

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

  1. 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
  2. Eingabe von

    netsh trace start scenario=directaccess capture=yes report=yes

    Damit starte ich den Trage
  3. 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.
  4. Test-Funktionen ausführen
    Protokollieren Sie sich bitte den Zeitpunkt der Aktion mit, um später im Log die Zuordnung zu vereinfachen
    1. DNS-Cache leeren, um auch die Namensauflösung zu triggern.
      "ipconfig /flushdns"
    2. IP-Helper durchstarten
      net stop iphlpsvc && net start iphlpsvc
    3. Gewünschtes Ziel über den Namen "anpingen"
      Damit wird eine Namensauflösung über DNS64 und eine IP.Umsetzung (NAT64) gestartet
    4. Gewünschten Service ansprechen.
      z.B.: einen Dateiserver o.ä.
  5. 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

Damit sollte auch auf dem Client schnell ein erster Überblick möglich sein.

Weitere Links