Network Location Awareness

Warum kann ich meine Server nicht mehr per RDP erreichen und warum laufen einige Dienste nicht? Vielleicht ist es ja nur, dass der NLASVC ihr LAN nicht als "Domain" oder "Private" sondern irrtümlich als Public erkannt hat. Sie können das Netz auch nicht manuelle auf "Domain" umstellen, sondern maximal auf "Privat". Diese Seite beschreibt, wie der NLASVC erkennt, wozu ein Netzwerk gehört und warum es manchmal daneben geht.

Das Problem

Wenn Sie dann irgendwie anders auf den Server gekommen sind, z.B. per virtuellem KVM, per ILO, DRAC, Intel-ME-Board oder auch per HyperV/VMWare-Konsole oder klassische mit Kabel und Monitor, dann kontrollieren Sie bitte zuerst einmal die Zone ihres Netzwerks.

Ein "Public "sollten Sie nicht sehen, wen ihre Server in einer Domäne ist und die Domain Controller über dieses LAN erreichen kann. Ein Public sehen Sie durchaus auf der ein oder anderen Karte, z.B. auf dem externen Interface eines Exchange Edge Server, eines Skype for Business Edge oder auch vielleicht eines Web Application Proxy. Quasi alle Systeme die zwei oder mehr Netzwerkkarten und eine davon eben nicht mit den internen DCs sprechen kann oder natürlich auf Systemen, die gar nicht in einer Domäne Mitglied sind und daher maximal manuell ein Netzwerk von "Public" auf "Privat" umgestellt wurde.

Zonen

Seit Windows Vista gibt es schon die Möglichkeit auf den Netzwerkkarten entsprechende Profile anzuwenden. Erst seit Windows 7/Windows 2008 ist diese Einstellung nicht mehr Global sondern pro Netzwerkkarte anzuwenden und es gibt drei Optionen

  • Öffentlich
    Der Client ist in einem "unsicheren" Netzwerk und sollte daher möglichst keine Dienste selbst anbieten
  • Privat
    Der Client steht "zuhause" und erlaubt deutlich mehr.
  • Domain
    Der Domain-Joined Client hat erkannt, dass er im Firmennetzwerk ist.

Während Sie "Öffentlich" und "Privat" selbst einstellen können, ist die Einstellung von "Domain" komplett automatisiert und kann nicht von Hand einer Verbindung zugewiesen werden.

Erkennung und die Fallen

Für die Erkennung ist bei Windows ein eigener Dienst Namens "NLASVC" (Network Location Service) zuständig, der automatisch gestartet wird und immer dann aktiv wird, wenn sich ein "Netzwerk-Link" verändert, d.h. sich irgendetwas bei den Netzwerkkarten ändert. Das kann auch ein Wechsel im WLAN oder der Auf/Abbau eines VPN sein. Auch beim Hochfahren wird entsprechend eine Erkennung durchgeführt. Das funktioniert auf Clients fast immer aber auf Servern kann das ein Problem darstellen.

Server haben normalerweise eine "feste" Netzwerkkarte mit stabiler Verbindung. Wenn die Verbindung mal "wackelt", dann ist das auch kein Problem, weil der NLASVC wieder nachschaut und in der Regel die Verbindung korrekt wieder konfiguriert. Knifflig wird es, wenn beim Hochfahren die Erkennung fehlschlägt. Im schlimmsten Fall wird die Netzwerkverbindung auf "Public"  (also Internet) gestellt und die meisten Administratoren bemerken das zuerst einmal daran, dass Sie per RDP nicht mehr auf den Server kommen. Da die Netzwerkverbindung dann sich nicht mehr ändert, gibt es für NLASVC auch keinen Grund wieder nachzuschauen.

Ich habe bislang folgende Situationen nachstellen können, bei denen diese Deadlock-Situation entstehen kann.

  • Logische Switch Probleme
    "Eigentlich sollte es heute kein Problem sein, dass sich zwei Endgeräte auf Verbindungsparameter einigen. Solange Sie sich nicht "einigen" passiert auch nicht, da NLASVC erkennt, dass der Link nicht steht. Problematisch wird es, wenn der Link aus Sicht des Netzwerktreibers steht aber dennoch keine Daten übertragen werden. Das kann durchaus ein Softwarefehler des Treibers sein. Es kann aber auch daran liegen, dass der "Next Hop", in der Regel der Switch, die Pakete noch nicht weiterleitet. Prüfen Sie mal, ob ihr Switch hier "Funktionen" hat, die ein sofortiges Durchleiten von Paketen nach der Herstellung des Link verhindern. (Stichwort, Firewall, Authentifizierung, MAC-Verifikation, Fastpath
  • Netzwerklink mit Virtualisierung
    Auch für virtuelle Maschinen kann es solche Probleme geben, da der Gast über den virtuellen Switch nicht erkennen kann, ob der Host auch einen "Link" hat. Gerade wenn der Host nach einem Update neu gestartet hat und viele VMs zeitgleich angestartet werden ist es denkbar, dass der Gast schon loslegen will aber die darunter liegende Schicht noch gar nicht "ready" ist. In dem Fall hilft es oft, wenn die VMs erst verspätet gestartet werden.
  • Alle DCs down
    Das sollte nicht passieren aber wenn ein Windows Update o.ä. dafür sorgt, dass alle DCs zeitgleich gepatched und gebootet werden, dann kann das schon passieren. Ein DC muss auch nicht down. Es reicht die "Nichterreichbarkeit" durch ihren Server z.B. weil ein Firmware-Update auf dem Switch zwar einen "Link" suggeriert aber doch keine Übertragung möglich ist.

Das alles hängt immer damit zusammen, wie NLASVC arbeitet. Das es irgendwas mit der Verbindung am Anfang zu tun hat ist immer dann wahrscheinlich wenn ein Neustart des Diensts NLASVC das Problem löst.

So funktioniert NLASVC

Der Dienst "NLASVC" ist auf jedem halbwegs modernen Windows Betriebssystem enthalten und steht auch auf "automatisch".

Aktiv wird er aber nur zu zwei Zeiten.

  1. Wenn ihr Computer startet (oder aus dem Suspend/Himernation-Mode zurück kommt)
  2. Wenn sich "etwas" am Netzwerk ändert.

Eine Änderung am Netzwerk kann ganz klassisch "Kabel gezogen" sein, d.h. ein echter "Link Loss". Aber auch eine Änderung bezüglich der WLAN-SSID triggert den NLASVC wieder an, seine Umgebung zu befragen und die Firewall-Zonen auf den Verbindungen ggfls. anzupassen. Auch ein VPN sollte über eine virtuelle Netzwerkkarte o.ä., Windows bescheid sagen, dass es aufgebaut wurde. Auch eine Netzwerk-Authentifizierung (8021.x) kann den NLASVC antriggern. Es könnte sich ja nun die Erreichbarkeit bestimmter Dienste geändert haben. Wie sie schon an der Firewall sehen können, gibt es drei Bereiche für Netzwerke

Auf einer Netzwerkkarte können Sie selbst zwischen den Einstellungen "Öffentlich" und "Privat" wechseln. Anscheinend nutzt Windows dann die MAC-Adresse des Default Gateway, um das Netzwerk später wieder zu erkennen und die vermeintlich richtig Einstellung anzuwenden. Die Einstellung "Domänenprofil" hingegen können Sie nicht auswählen. Diese ermittelt NLASVC eigenständig und nur auf Clients, die auch in einer Domäne Mitglied sind. Der Client versucht dann nämlich per LDAP einen Domain Controller zu erreichen und nur wenn das klappt, geht der Client auch davon aus, dass er in einem "Domänennetzwerk" ist. Damit ist natürlich klar, dass Sie nie einen DC direkt ins Internet stellen sollten.

Ein Schlüssel ist dabei die Information, wo der Client vorher die Gruppenrichtlinien bezogen hat. Der Client vergleicht die aktuelle Antwort mit einer früher erhaltenen Information zur DNS-Domäne und das ist quasi der "Schlüssel". Damit kommt natürlich auch wieder die DHCP-Option zum Domänennamen ins Spiel, die einer Netzwerkkarte eine DNS-Domäne zuweisen kann. Das spiegelt sich auch in der Registrierung wieder.

In dem Schlüssel "NetworkName" steht normalweise die DNS-Domäne des ADForests den NLASVC mit den gefundenen Antworten vergleicht.

Zusätzlich macht der Client auch noch eine HTTP-Anfrage auf einen Server zu machen um zu prüfen, ob er in das Internet kommt. Der Client prüft dabei auch noch, ob der Inhalt überein stimmt. Probieren Sie es doch einfach mal aus

PS C:\> (Invoke-WebRequest http://www.msftncsi.com/ncsi.txt -UseBasicParsing).content
Microsoft NCSI

Das hat aber nicht direkt etwas mit den drei Firewall-Einstellungen zu tun sondern nur, ob ihr Client anzeigt, dass eine Verbindung zum Internet besteht

Troubleshooting mit Eventlog

Die beste Option die Arbeit des NLASVC zu analysieren ist das Windows Eventlog. Es gibt ein eigenes Eventlog für den NLASVC

Hier sollten Sie fündig werden, da hier alle "Disconnects" und Verbindung mit ihrem Status sehen. Hier sehen Sie einmal meine Verbindung im Homeoffice.

Log Name: Microsoft-Windows-NetworkProfile/Operational
Source: Microsoft-Windows-NetworkProfile

Folgende Events habe ich bislang gefunden:

Level

EventID

Description:

Information

10000

Network Connected
            Name: Identifying...
            Desc: Identifying...
            Type: Unmanaged
            State: Connected,IPV4 (Local),IPV6 (Local)
            Category: Public 

Information

10001

Network Disconnected
            Name: msxfaq.net
            Desc: msxfaq.net
            Type: Managed
            State: Disconnected
            Category: Domain Authenticated

Information

10000

Network Connected
            Name: msxfaq.net
            Desc: msxfaq.net
            Type: Managed
            State: Connected,IPV4 (Internet),IPV6 (Local)
            Category: Domain Authenticated

Information

4001

Eingegebener Status: Das Netzwerk wird identifiziert. Schnittstellen-GUID: {90a254eb-1f67-4eda-942d-41e92b19d065}

Information

4002

Übergang zu Status: Das Netzwerk wurde identifiziert. Schnittstellen-GUID: {c566ef7e-d476-40c7-8078-c0e35be4ebb0}

Information

4003

Übergang zu Status: Nicht identifiziertes Netzwerk. Schnittstellen-GUID: {60bc6758-df32-4876-b9dd-28f13f3cb098}

Wer mag kann also aus den Events durchaus nachverfolgen, wo ein Client wann war.

Für den NLASVC gibt es aber noch ein zweites Eventlog:

Log Name: Microsoft-Windows-NlaSvc/Operational
Source: Microsoft-Windows-NetworkProfile

Folgende Events habe ich bislang gefunden:

Level

EventID

Description:

Error

4343

LDAP authentication on interface {8F2D5AF2-7F6C-4587-A1EE-B38DE5...

Error

4205

Error Gateway resolution failed on interface {3443304C-5A6D-4B04-8E6F-...

Für die Fehlersuche ist dies nützlich, wenn Sie mal schauen wollen, ob ein "Link" geflackert hat. Per PowerShell geht das recht elegant

PS C:\> Get-WinEvent -LogName "Microsoft-Windows-NlaSvc/Operational" 

     ProviderName: Microsoft-Windows-NlaSvc 

TimeCreated            Id   Level Message
-----------            --   ----- -------
10/23/2016 11:20:43 PM 4343 Error LDAP authentication on interface {3443304C-5A6D-4B04-8E6F-4228C2...
7/3/2016 11:19:14 PM   4343 Error LDAP authentication on interface {3443304C-5A6D-4B04-8E6F-4228C2...
6/8/2016 9:16:59 AM    4205 Error Gateway resolution failed on interface {3443304C-5A6D-4B04-8E6F-...
3/10/2015 1:02:38 PM   4343 Error LDAP authentication on interface {8F2D5AF2-7F6C-4587-A1EE-B38DE5...
3/10/2015 1:02:31 PM   4343 Error LDAP authentication on interface {8F2D5AF2-7F6C-4587-A1EE-B38DE5...

Weitere Links