Windows-Firewallprofil wechselt nicht immer zu Domäne, wenn Sie einen VPN-Client eines Drittanbieters verwenden

In diesem Artikel wird ein Problem behoben, bei dem das Windows-Firewallprofil nicht von "Öffentlich" oder "Privat" zu "Domäne" wechselt, wenn Sie eine Verbindung mit dem Domänennetzwerk mithilfe eines VPN-Clients eines Drittanbieters herstellen.

Gilt für: Windows 10 – alle Editionen
Ursprüngliche KB-Nummer: 4550028

Problembeschreibung

Sie verwenden einen VPN-Client (Virtual Private Network) eines Drittanbieters, um eine Verbindung mit einem Domänennetzwerk herzustellen. In diesem Szenario wechselt die Windows-Firewall nicht immer von dem öffentlichen oder privaten Profil zu dem Domänenprofil wie erwartet.

Ursache

Ein Zeitabstand in einigen VPN-Clients von Drittanbietern verursacht manchmal dieses Problem. Die Verzögerung tritt auf, wenn der Client die erforderlichen Routen zum Domänennetzwerk hinzufügt.

Lösung

Um dieses Problem zu beheben, empfehlen wir, dass Sie sich an den VPN-Anbieter wenden, um die Durch das Hinzufügen von Domänenrouten verursachte Zeitverzögerung zu verringern.

Bei VPN-Anbietern können Sie Rückruf-APIs verwenden, um Routen hinzuzufügen, sobald der VPN-Adapter bei Windows eintrifft. Zum Beispiel:

• NotifyUnicastIpAddressChange: Benachrichtigt Anrufer über änderungen an jeder IP-Adresse, einschließlich Änderungen am DAD-Zustand.
• NotifyIpInterfaceChange: Registriert einen Rückruf für die Benachrichtigung über Änderungen an allen IP-Schnittstellen.

Im Benutzermodus gibt es IpHelper-APIs. Zum Beispiel:

• NotifyAddrChanget: Benachrichtigt den Benutzer über Adressänderungen.

Problemumgehung

Wichtig

Folgen Sie den Schritten in diesem Abschnitt sorgfältig. Wird die Registrierung falsch angepasst, können schwerwiegende Probleme auftreten. Bevor Sie sie ändern, sichern Sie die Registrierung zwecks Wiederherstellung für den Fall, dass Probleme auftreten.

Um dieses Problem zu umgehen, deaktivieren Sie den negativen Cache, um den NLA-Dienst (Network Location Awareness) beim Erneuten Versuch der Domänenerkennung zu unterstützen. Verwenden Sie dazu die folgenden Methoden.

• Deaktivieren Sie zuerst den negativen Cache für die Domänenermittlung, indem Sie den Registrierungsschlüssel "NegativeCachePeriod " zu folgendem Unterschlüssel hinzufügen:

  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters

  Name: NegativeCachePeriod
  Typ: REG_DWORD
  Wertdaten: 0 (Standardwert: 45 Sekunden; auf 0 festgelegt, um die Zwischenspeicherung zu deaktivieren)

• Wenn das Problem nicht behoben wird, deaktivieren Sie den DNS-negativen Cache weiter, indem Sie den Registrierungsschlüssel "MaxNegativeCacheTtl " zum folgenden Unterschlüssel hinzufügen:

  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters

  Name: MaxNegativeCacheTtl
  Typ: REG_DWORD
  Wertdaten: 0 (Standardwert: 5 Sekunden; auf 0 festgelegt, um die Zwischenspeicherung zu deaktivieren)

Weitere Informationen

Wenn das Problem auftritt, lautet der Ereignisfluss wie folgt:

• Der Benutzer stellt eine Verbindung mit dem VPN bereit.
• Während der VPN-Tunneleinrichtung wird die VPN-Schnittstelle erstellt und eine IP-Adresse zugewiesen, und die erforderlichen Routen werden der Schnittstelle hinzugefügt. Die folgenden Bedingungen gelten:

  • TCP/IP fügt sofort eine Hostroute und On-Link-Subnetzrouten in einer der folgenden Situationen hinzu:

    • Die Adresse weist einen bestimmten Typ auf, z. B. DHCP, IPv6-Verknüpfung lokal und IPv6 temporär.
    • Optimistische Duplikataerkennung (Duplicate Address Detection, DAD) ist für diese Adresse aktiviert.

    Andernfalls fügt TCP/IP diese Routen hinzu, nachdem die DAD erfolgreich abgeschlossen wurde.

  • Der VPN-Client ist für die erforderlichen Routen für die VPN-Netzwerke verantwortlich, z. B. dass die VPN-Schnittstelle an den VPN-DNS-Server weitergeleitet werden kann.

• Die erste Routenänderung löst die Erkennung des Netzwerkverbindungsstatusindikators (Network Connection Status Indicator, NCSI) aus. Und der NLA-Dienst (Network Location Awareness) versucht, sich beim Domänencontroller zu authentifizieren, um der Firewall das richtige Profil zuzuweisen.
• Die Authentifizierung beginnt damit, dass der NLA-Dienst die DsGetDcName-Funktion aufruft, um den DC-Namen abzurufen. Dies erfolgt durch eine DNS-Namensauflösung für den Namen, z. B. as_ldap._tcp. CNNDC._sites.dc._msdcs.<domainname>.
• Wenn diese Namensauflösung auftritt, bevor die erforderlichen VPN-Routen an den VPN-DNS-Server der VPN-Schnittstelle hinzugefügt werden, schlägt diese DNS-Namensauflösung fehl. Außerdem wird "DsGetDcName-Funktion mit ERROR_NO_SUCH_DOMAIN fehlgeschlagen" zurückgegeben. Anschließend wird dieses Ergebnis zwischengespeichert.
• Der DNS-Namensauflösungsfehler kann auch einen negativen DNS-Cache erstellen. Der negative Cache verursacht zusätzlichen Fehler, wenn der NLA-Dienst die Domänenerkennung erneut aufruft.