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 Hyper-V/VMWare-Konsole oder klassische mit Kabel und Monitor, dann kontrollieren Sie bitte zuerst einmal die Zone ihres Netzwerks.

Bei Windows 10 uns neuer gibt es ebenfalls eine Netzwerk Statusanzeige:

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 (NCSI)

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. Da stellt sich die Frage, woran Windows diese Erkennung fest macht.

Microsoft does not recommend disabling the NCSI probes. Several operating system components and applications rely on NCSI. For example, if NCSI does not function correctly, Microsoft Outlook may not be able to connect to a mail server, or Windows may not be able to download updates even if the computer is connected to the internet
Quelle: An Internet Explorer or Edge window opens when your computer connects to a corporate network or a public network
https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/internet-explorer-edge-open-connect-corporate-public-network.

Zuerst gibt es einmal die grundlegende Verbindung, deren Parameter auch in der Registrierung zu finden sind.

Im Schlüssel "Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet" gibt es jede Menge Parameter, die NLASVC konfigurieren.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet]
"ActiveDnsProbeContent"="131.107.255.255"
"ActiveDnsProbeContentV6"="fd3e:4f5a:5b81::1"
"ActiveDnsProbeHost"="dns.msftncsi.com"
"ActiveDnsProbeHostV6"="dns.msftncsi.com"
"ActiveWebProbeContent"="Microsoft Connect Test"
"ActiveWebProbeContentV6"="Microsoft Connect Test"
"ActiveWebProbeHost"="www.msftconnecttest.com"
"ActiveWebProbeHostV6"="ipv6.msftconnecttest.com"
"ActiveWebProbePath"="connecttest.txt"
"ActiveWebProbePathV6"="connecttest.txt"
"CaptivePortalTimer"=dword:00000000
"CaptivePortalTimerBackOffIncrementsInSeconds"=dword:00000005
"CaptivePortalTimerMaxInSeconds"=dword:0000001e
"EnableActiveProbing"=dword:00000001
"PassivePollPeriod"=dword:0000000f
"StaleThreshold"=dword:0000001e
"WebTimeout"=dword:00000023

Hier sehen Sie auch die Gegenstelle, die sie einfach per Browser testen können:

Millionen von Client fordern diese URL und kleine Text-Datei von Microsoft ab, um die Verbindung zum Internet zu prüfen. Früher gab es noch eine andere URL:

Vor Windows 1607  http://www.msftncsi.com/ncsi.txt
Ab  Windows 1607  http://www.msftconnecttest.com/connecttest.txt

In Grenzen können Sie die Funktion des NLASVC auch per Gruppenrichtlinien anpassen:

Computer Configuration 
  -> Administrative Templates 
     -> System
       -> Internet Communication Management  
         -> Internet Communication settings 
  -> Network
    ->Network Connectivity Status Indicator
         "Corporate Website probe URL" =  Webseite der Firma als Testgegenstelle
         "Corporate DNS Probe Host Name" = DNS-Name, der auf eine IP-Adresse (A-Record) auflöst
         "Corporate DNS Probe Host Address = "erwartete IP Adresse als Antwort"

Fallstricke

Auf Clients funktioniert NLASVC fast immer problemlos aber auf Servern habe ich schon die ein oder andere Problem analysiert. 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 aktiv 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...

msftconnecttest.com-Standort

Der Host www.msftconnecttest.com hat natürlich eine zentrale Rolle für alle Windows Clients und muss verfügbar sein. Das geht ab besten durch viele Server, die weltweit verteilt sind und per DNS passend aufgelöst werden. Ein deutscher Client muss ja nicht in Redmond nachfragen. Microsoft nutzt dazu interessanterweise nicht seine eigenen Datacenter, von denen Sie dank Azure ja genug hätte, sondern baut auf Content Delivery Provider auf. Die haben den Vorteil, dass Sie sogar Server in der Nähe oder direkt bei den Zugangsprovider haben.

Die erste Information bekommen Sie durch einen NSLOOKUP, bei dem bei mir schon ein Server bei Akamai erscheint.

C:\> nslookup www.msftconnecttest.com

Nicht autorisierende Antwort:
Name: a1961.g2.akamai.net
Addresses: 185.22.140.10
185.22.140.18
Aliases: www.msftconnecttest.com
ncsi-geo.trafficmanager.net
www.msftncsi.com.edgesuite.net

Wenn ich dann einen Traceroute starten, dann sehen Sie bei meinem Glasfaseranschluss, dass das Zielsystem gar nicht weit weg ist.

C:\> tracert www.msftconnecttest.com

Routenverfolgung zu a1961.g2.akamai.net [185.22.140.18] über maximal 30 Hops:

1 2 ms 1 ms 1 ms fritz.box [192.168.178.1]
2 8 ms 6 ms 6 ms 100.124.1.57
3 10 ms 5 ms 6 ms 100.127.1.132
4 9 ms 5 ms 6 ms 100.127.1.131
5 6 ms 6 ms 6 ms 185.22.46.145
6 12 ms 8 ms 7 ms 185.22.140.18

Ablaufverfolgung beendet.

Die IP-Adresse 185.22.140.18 gehört in dem Fall sogar noch in den Netzwerkbereich von Deutsche Glasfaser.


https://ipinfo.io/AS60294/185.22.140.0/22

Das bedeutet im Umkehrschluss aber auch, dass die Prüfung natürlich nur "lokale" Störungen erkennen kann. Wenn das Problem aber beim Uplink des Providers zum eigentlichen Internet ist, dann wird ihr Client ein "OK" melden. Das ist aber nicht anders möglich, denn Sie können ja nicht "Das Internet" mit seinen Millionen Systemen und WAN-Links überwachen.

Weitere Links