Bekannte Einschränkungen für den globalen sicheren Zugriff

Der globale sichere Zugriff ist der vereinheitlichte Begriff, der sowohl für Microsoft Entra Internet Access als auch für Microsoft Entra Private Access verwendet wird.

In diesem Artikel werden die bekannten Probleme und Einschränkungen beschrieben, die bei verwendung des globalen sicheren Zugriffs auftreten können.

Einschränkungen des globalen Clients für den sicheren Zugriff

Der client für den globalen sicheren Zugriff ist auf mehreren Plattformen verfügbar. Wählen Sie jede Registerkarte aus, um Details zu den bekannten Einschränkungen für jede Plattform anzuzeigen.

Windows-Client-

Bekannte Einschränkungen für den globalen Secure Access-Client für Windows umfassen:

Secure Domain Name System (DNS)

Der Global Secure Access-Client unterstützt derzeit kein sicheres DNS in seinen verschiedenen Versionen, z. B. DNS over HTTPS (DoH), DNS over TLS (DoT) oder DNS Security Extensions (DNSSEC). Um den Client so zu konfigurieren, dass er Netzwerkdatenverkehr abrufen kann, müssen Sie sicheres DNS deaktivieren. Informationen zum Deaktivieren von DNS im Browser finden Sie unter Secure DNS disabled in Browsern.

DNS über TCP

DNS verwendet Port 53 UDP für die Namensauflösung. Einige Browser verfügen über einen eigenen DNS-Client, der auch Port 53 TCP unterstützt. Derzeit unterstützt der Global Secure Access-Client keinen DNS-Port 53 TCP. Deaktivieren Sie als Gegenmaßnahme den DNS-Client des Browsers, indem Sie die folgenden Registrierungswerte festlegen:

• Microsoft Edge
  [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge] "BuiltInDnsClientEnabled"=dword:00000000
• Chrom
  [HKEY_CURRENT_USER\Software\Policies\Google\Chrome] "BuiltInDnsClientEnabled"=dword:00000000
  Fügen Sie außerdem chrome://flags hinzu, und deaktivieren Sie Async DNS resolver.

Regeln für die Namensauflösungsrichtlinie in der Gruppenrichtlinie werden nicht unterstützt

Der globale Secure Access-Client für Windows unterstützt keine NrPT-Regeln (Name Resolution Policy Table) in der Gruppenrichtlinie. Um private DNS zu unterstützen, konfiguriert der Client lokale NRPT-Regeln auf dem Gerät. Diese Regeln leiten relevante DNS-Abfragen an den privaten DNS um. Wenn NRPT-Regeln in der Gruppenrichtlinie konfiguriert sind, überschreiben sie lokale NRPT-Regeln, die vom Client konfiguriert wurden, und private DNS funktioniert nicht.

Darüber hinaus haben NRPT-Regeln, die in älteren Versionen von Windows konfiguriert und gelöscht wurden, eine leere Liste der NRPT-Regeln in der datei registry.pol erstellt. Wenn dieses Gruppenrichtlinienobjekt (Group Policy Object, GPO) auf das Gerät angewendet wird, überschreibt die leere Liste die lokalen NRPT-Regeln und privates DNS funktioniert nicht.

Als Gegenmaßnahme:

1. Wenn der Registrierungsschlüssel HKLM\Software\Policies\Microsoft\Windows NT\DNSClient\DnsPolicyConfig auf dem Endbenutzergerät vorhanden ist, konfigurieren Sie ein Gruppenrichtlinienobjekt, um NRPT-Regeln anzuwenden.
2. So ermitteln Sie, welche GPOs mit NRPT-Regeln konfiguriert sind:
   1. Führen Sie gpresult /h GPReport.html auf dem Endbenutzergerät aus, und suchen Sie nach einer NRPT-Konfiguration.
   2. Führen Sie das folgende Skript aus, das die Pfade aller registry.pol Dateien in sysvol erkennt, die NRPT-Regeln enthalten.

Anmerkung

Denken Sie daran, die sysvolPath Variable so zu ändern, dass sie der Konfiguration Ihres Netzwerks entspricht.

# =========================================================================
# THIS CODE-SAMPLE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER 
# EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES 
# OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE.
#
# This sample is not supported under any Microsoft standard support program 
# or service. The code sample is provided AS IS without warranty of any kind. 
# Microsoft further disclaims all implied warranties including, without 
# limitation, any implied warranties of merchantability or of fitness for a 
# particular purpose. The entire risk arising out of the use or performance
# of the sample and documentation remains with you. In no event shall 
# Microsoft, its authors, or anyone else involved in the creation, 
# production, or delivery of the script be liable for any damages whatsoever 
# (including, without limitation, damages for loss of business profits, 
# business interruption, loss of business information, or other pecuniary 
# loss) arising out of  the use of or inability to use the sample or 
# documentation, even if Microsoft has been advised of the possibility of 
# such damages.
#========================================================================= 

# Define the sysvol share path.
# Change the sysvol path per your organization, for example: 
# $sysvolPath = "\\dc1.contoso.com\sysvol\contoso.com\Policies"
$sysvolPath = "\\<DC FQDN>\sysvol\<domain FQDN>\Policies"  ## Edit

# Define the search string.
$searchString = "dnspolicyconfig"

# Define the name of the file to search.
$fileName = "registry.pol"

# Get all the registry.pol files under the sysvol share.
$files = Get-ChildItem -Path $sysvolPath -Recurse -Filter $fileName -File

# Array to store paths of files that contain the search string.
$matchingFiles = @()

# Loop through each file and check if it contains the search string.
foreach ($file in $files) {
    try {
        # Read the content of the file.
        $content = Get-Content -Path $file.FullName -Encoding Unicode
        
        # Check if the content contains the search string.
        if ($content -like "*$searchString*") {
            $matchingFiles += $file.FullName
        }
    } catch {
        Write-Host "Failed to read file $($file.FullName): $_"
    }
}

# Output the matching file paths.
if ($matchingFiles.Count -eq 0) {
    Write-Host "No files containing '$searchString' were found."
} else {
    Write-Host "Files containing '$searchString':"
    $matchingFiles | ForEach-Object { Write-Host $_ }
}

3. Bearbeiten Sie die einzelnen GPOs, die im vorherigen Abschnitt gefunden wurden:
   1. Wenn der NRPT-Abschnitt leer ist, erstellen Sie eine neue fiktive Regel, aktualisieren Sie die Richtlinie, löschen Sie die fiktive Regel, und aktualisieren Sie die Richtlinie erneut. Mit diesen Schritten wird die DnsPolicyConfig aus der registry.pol-Datei entfernt (die in einer älteren Version von Windows erstellt wurde).
   2. Wenn der NRPT-Abschnitt nicht leer ist und Regeln enthält, vergewissern Sie sich, dass Sie diese Regeln weiterhin benötigen. Wenn Sie die Regeln nicht benötigen, löschen Sie sie. Wenn Sie die Regeln benötigen und das Gruppenrichtlinienobjekt auf einem Gerät mit globalem Secure Access-Client anwenden, funktioniert die private DNS-Option nicht.

Verbindungsfallback

Wenn ein Verbindungsfehler mit dem Clouddienst auftritt, greift der Client entweder auf eine direkte Internetverbindung zurück oder blockiert die Verbindung, basierend auf dem Härtung Wert der übereinstimmenden Regel im Weiterleitungsprofil.

Geolocation

Bei Netzwerkdatenverkehr, der an den Clouddienst getunnelt wird, erkennt der Anwendungsserver (Website) die Quell-IP der Verbindung als IP-Adresse des Edges (und nicht als IP-Adresse des Benutzers). Dieses Szenario kann sich auf Dienste auswirken, die auf Geolocation basieren.

Trinkgeld

Damit Microsoft 365 und Microsoft Entra die tatsächliche Quell-IP des Geräts erkennen können, sollten Sie Quell-IP-Wiederherstellungaktivieren.

Virtualisierungsunterstützung

Sie können den globalen Secure Access-Client nicht auf einem Gerät installieren, auf dem virtuelle Computer gehostet werden. Sie können den globalen Secure Access-Client jedoch auf einem virtuellen Computer installieren, sofern der Client nicht auf dem Hostcomputer installiert ist. Aus demselben Grund erhält ein Windows-Subsystem für Linux (WSL) keinen Datenverkehr von einem Client, der auf dem Hostcomputer installiert ist.

Hyper-V Unterstützung:

1. Externer virtueller Switch: Der Windows-Client für den globalen sicheren Zugriff unterstützt derzeit keine Hostcomputer mit einem Hyper-V externen virtuellen Switch. Der Client kann jedoch auf den virtuellen Computern installiert werden, um den Datenverkehr in den globalen sicheren Zugriff zu tunneln.
2. Interner virtueller Switch: Der Windows-Client für den globalen sicheren Zugriff kann auf Host- und Gastcomputern installiert werden. Der Client tunnelt nur den Netzwerkdatenverkehr des Computers, auf dem er installiert ist. Anders ausgedrückt: Ein auf einem Hostcomputer installierter Client tunnelt nicht den Netzwerkdatenverkehr der Gastcomputer.

Der Windows-Client für den globalen sicheren Zugriff unterstützt Azure Virtual Machines und Azure Virtual Desktop (AVD).

Anmerkung

Der Windows-Client für den globalen sicheren Zugriff unterstützt keine AVD-Mehrsitzung.

Stellvertreter

Wenn ein Proxy auf Anwendungsebene (z. B. ein Browser) oder auf Betriebssystemebene konfiguriert ist, konfigurieren Sie eine PAC-Datei (Proxy Auto Configuration), um alle FQDNs und IPs auszuschließen, die der Client tunnelt.

Um zu verhindern, dass HTTP-Anforderungen für bestimmte FQDNs/IPs in den Proxy tunneln, fügen Sie die FQDNs/IPs als Ausnahmen zur PAC-Datei hinzu. (Diese FQDNs/IPs befinden sich im Weiterleitungsprofil des globalen sicheren Zugriffs für tunneling). Zum Beispiel:

function FindProxyForURL(url, host) {   
        if (isPlainHostName(host) ||   
            dnsDomainIs(host, ".microsoft.com") || // tunneled 
            dnsDomainIs(host, ".msn.com")) // tunneled 
           return "DIRECT";                    // If true, sets "DIRECT" connection 
        else                                   // If not true... 
           return "PROXY 10.1.0.10:8080";  // forward the connection to the proxy
}

Wenn eine direkte Internetverbindung nicht möglich ist, konfigurieren Sie den Client so, dass eine Verbindung mit dem globalen Sicheren Zugriffsdienst über einen Proxy hergestellt wird. Legen Sie z. B. die grpc_proxy Systemvariable so fest, dass sie dem Wert des Proxys entspricht, z. B. http://proxy:8080.

Um die Konfigurationsänderungen anzuwenden, starten Sie die Windows-Dienste des globalen Secure Access-Clients neu.

Paketeinfügung

Der Client tunnelt nur Datenverkehr, der mithilfe von Sockets gesendet wird. Der in den Netzwerkstapel eingefügte Datenverkehr wird nicht mithilfe eines Treibers getunnelt (z. B. einige des datenverkehrsgeneriert von Network Mapper (Nmap)). Injizierte Pakete werden direkt in das Netzwerk verschoben.

Mehrere Sitzungen

Der client für den globalen sicheren Zugriff unterstützt keine gleichzeitigen Sitzungen auf demselben Computer. Diese Einschränkung gilt für RDP-Server (Remote Desktop Protocol) und VDI-Lösungen (Virtual Desktop Infrastructure) wie Azure Virtual Desktop (AVD), die für mehrere Sitzungen konfiguriert sind.

Arm64

Der globale Secure Access-Client unterstützt keine Arm64-Architektur.

QUIC für Internet Access nicht unterstützt

Da QUIC für Den Internetzugriff noch nicht unterstützt wird, kann der Datenverkehr zu den Ports 80 UDP und 443 UDP nicht tunnelt werden.

Trinkgeld

QUIC wird derzeit in Private Access- und Microsoft 365-Workloads unterstützt.

Administratoren können QUIC-Protokolltriggering-Clients deaktivieren, um auf HTTPS über TCP zurückzugreifen, das vollständig in Internet Access unterstützt wird. Weitere Informationen finden Sie unter QUIC für Internet Accessnicht unterstützt.

WSL 2-Konnektivität

Wenn der globale Secure Access-Client für Windows auf dem Hostcomputer aktiviert ist, werden ausgehende Verbindungen vom Windows-Subsystem für Linux (WSL) 2 möglicherweise blockiert. Um dieses Vorkommen zu verringern, erstellen Sie eine .wslconfig Datei, die dnsTunneling auf falsefestlegt. Auf diese Weise umgeht der gesamte Datenverkehr von WSL den globalen sicheren Zugriff und wechselt direkt zum Netzwerk. Weitere Informationen finden Sie unter Konfiguration erweiterter Einstellungen in WSL-.

macOS-Client-

Bekannte Einschränkungen für den globalen Secure Access-Client für macOS umfassen:

Secure Domain Name System (DNS)

Wenn Secure DNS im Browser oder in macOS aktiviert ist und der DNS-Server Secure DNS unterstützt, wird der Client nicht tunneln, der von FQDN abgerufen werden soll. (Der von IP erworbene Netzwerkdatenverkehr ist nicht betroffen und wird gemäß dem Weiterleitungsprofil getunnelt.) Um das Secure DNS-Problem zu beheben, deaktivieren Sie Secure DNS, legen Sie einen DNS-Server fest, der secure DNS nicht unterstützt, oder erstellen Sie Regeln basierend auf IP.

Verbindungsfallback

Wenn ein Verbindungsfehler mit dem Clouddienst auftritt, greift der Client entweder auf eine direkte Internetverbindung zurück oder blockiert die Verbindung, basierend auf dem Härtung Wert der übereinstimmenden Regel im Weiterleitungsprofil.

Geolocation der Quell-IP-Adresse

Bei Netzwerkdatenverkehr, der an den Clouddienst getunnelt wird, erkennt der Anwendungsserver (Website) die Quell-IP der Verbindung als IP-Adresse des Edges (und nicht als IP-Adresse des Benutzers). Dieses Szenario kann sich auf Dienste auswirken, die auf Geolocation basieren.

Trinkgeld

Damit Office 365 und Microsoft Entra die tatsächliche Quell-IP des Geräts erkennen können, sollten Sie Quell-IP-Wiederherstellungaktivieren.

Virtualisierungsunterstützung mit UTM

• Wenn sich das Netzwerk im Modus befindet und der client für den globalen sicheren Zugriff auf dem Hostcomputer installiert ist:
  • Wenn der globale Secure Access-Client auf dem virtuellen Computer installiert ist, unterliegt der Netzwerkdatenverkehr des virtuellen Computers der lokalen Richtlinie. Die Richtlinie des Hostcomputers wirkt sich nicht auf das Weiterleitungsprofil auf dem virtuellen Computer aus.
  • Wenn der globale Secure Access-Client nicht auf dem virtuellen Computer installiert ist, wird der Netzwerkdatenverkehr des virtuellen Computers umgangen.
• Der Global Secure Access-Client unterstützt kein Netzwerk freigegebenen Modus, da er den Netzwerkdatenverkehr des virtuellen Computers möglicherweise blockiert.
• Wenn sich das Netzwerk im modus freigegebenen befindet, können Sie den globalen Secure Access-Client auf einem virtuellen Computer installieren, auf dem macOS ausgeführt wird, sofern der Client nicht auch auf dem Hostcomputer installiert ist.

QUIC für Internet Access nicht unterstützt

Da QUIC für Den Internetzugriff noch nicht unterstützt wird, kann der Datenverkehr zu den Ports 80 UDP und 443 UDP nicht tunnelt werden.

Trinkgeld

QUIC wird derzeit in Private Access- und Microsoft 365-Workloads unterstützt. Administratoren können QUIC-Protokoll in Browsern deaktivieren und Clients auslösen, um auf HTTPS über TCP zurückzugreifen, was in Internet Access vollständig unterstützt wird. Weitere Informationen finden Sie unter QUIC für Internet Accessnicht unterstützt.

Android-Client

Bekannte Einschränkungen für den globalen Secure Access-Client für Android umfassen:

• Mobile Geräte mit Android (Go Edition) werden derzeit nicht unterstützt.
• Microsoft Defender für Endpunkt unter Android auf gemeinsam genutzten Geräten wird derzeit nicht unterstützt.
• Das Private Domain Name System (DNS) muss auf dem Gerät deaktiviert sein. Diese Einstellung befindet sich häufig in den System- > Netzwerk- und Internetoptionen.
• Das Ausführen von Nicht-Microsoft-Endpunktschutzprodukten zusammen mit Microsoft Defender für Endpunkt kann zu Leistungsproblemen und unvorhersehbaren Systemfehlern führen.
• Die Koexistenz für globalen sicheren Zugriff mit Microsoft Tunnel wird derzeit nicht unterstützt. Weitere Informationen finden Sie unter Voraussetzungen für den Microsoft Tunnel in Intune.

iOS-Client-

Bekannte Einschränkungen für den globalen Secure Access-Client für Android umfassen:

• Der Tunneling Quick User Datagram Protocol (UDP) Internet Connections (QUIC)-Datenverkehr (mit Ausnahme von Exchange Online) wird nicht unterstützt.
• Die Koexistenz für globalen sicheren Zugriff mit Microsoft Tunnel wird derzeit nicht unterstützt. Weitere Informationen finden Sie unter Voraussetzungen für den Microsoft Tunnel in Intune.

Einschränkungen für Remotenetzwerke

Bekannte Einschränkungen für Remotenetzwerke umfassen:

• Die maximale Anzahl von Remotenetzwerken pro Mandant beträgt 10. Die maximale Anzahl von Geräteverbindungen pro Remotenetzwerk beträgt vier.
• Microsoft-Datenverkehr wird über Remotenetzwerkkonnektivität ohne den Global Secure Access-Client zugegriffen. Die Richtlinie für bedingten Zugriff wird jedoch nicht erzwungen. Mit anderen Worten: Richtlinien für bedingten Zugriff für den globalen sicheren Zugriff werden nur erzwungen, wenn ein Benutzer über den globalen Client für den sicheren Zugriff verfügt.
• Sie müssen den globalen Secure Access-Client für microsoft Entra Private Access verwenden. Remotenetzwerkkonnektivität unterstützt nur Microsoft Entra Internet Access.
• Derzeit können Remotenetzwerke nur dem Microsoft-Datenverkehrsweiterleitungsprofil zugewiesen werden.

Einschränkungen für Zugriffssteuerungen

Bekannte Einschränkungen für Zugriffssteuerungen umfassen:

• Die Kontinuierliche Zugriffsauswertung (Continuous Access Evaluation, CAE) wird für den universellen bedingten Zugriff für Microsoft-Datenverkehr derzeit nicht unterstützt.
• Das Anwenden von Richtlinien für bedingten Zugriff auf privaten Zugriff wird derzeit nicht unterstützt. Um dieses Verhalten zu modellieren, können Sie eine Richtlinie für bedingten Zugriff auf Anwendungsebene für Apps für den Schnellzugriff und globalen sicheren Zugriff anwenden. Weitere Informationen finden Sie unter Anwenden des bedingten Zugriffs auf Private Access-Apps.
• Microsoft-Datenverkehr kann über Remotenetzwerkkonnektivität ohne den Global Secure Access Client zugegriffen werden; Die Richtlinie für bedingten Zugriff wird jedoch nicht erzwungen. Mit anderen Worten: Richtlinien für bedingten Zugriff für den globalen sicheren Zugriff werden nur erzwungen, wenn ein Benutzer über den globalen Client für den sicheren Zugriff verfügt.
• Kompatible Netzwerküberprüfungsdatenebenenerzwingung (Vorschau) mit fortlaufender Zugriffsauswertung wird für SharePoint Online und Exchange Online unterstützt.
• Das Aktivieren der Signalisierung für den bedingten Zugriff für den globalen sicheren Zugriff ermöglicht signalisieren sowohl für Authentifizierungsebenen (Microsoft Entra ID) als auch für Datenebenensignale (Vorschau). Es ist derzeit nicht möglich, diese Einstellungen separat zu aktivieren.
• Die kompatible Netzwerküberprüfung wird derzeit für Private Access-Anwendungen nicht unterstützt.
• Wenn die Quell-IP-Wiederherstellung aktiviert ist, können Sie nur die Quell-IP sehen. Die IP-Adresse des globalen Diensts für den sicheren Zugriff ist nicht sichtbar. Wenn Die IP-Adresse des globalen Sicheren Zugriffsdiensts angezeigt werden soll, deaktivieren Sie die Quell-IP-Wiederherstellung.
• Derzeit Microsoft-Ressourcen IP-standortbasierte Richtlinien für bedingten Zugriff auswerten, da die ursprüngliche Quell-IP-Adresse nicht von Microsoft stammenden Ressourcen bekannt ist, die durch kontinuierliche Zugriffsauswertung (Continuous Access Evaluation, CAE) geschützt sind.
• Wenn Sie die strikte Erzwingung des Standorts von CAEverwenden, werden Benutzer blockiert, obwohl sie sich in einem vertrauenswürdigen IP-Bereich befinden. Führen Sie eine der folgenden Empfehlungen aus, um diese Bedingung zu beheben:
  • Wenn Sie über RICHTLINIEN für den standortbasierten bedingten Zugriff verfügen, die nicht von Microsoft stammende Ressourcen sind, aktivieren Sie keine strikte Standorterzwingung.
  • Stellen Sie sicher, dass die Quell-IP-Wiederherstellung den Datenverkehr unterstützt. Andernfalls senden Sie den relevanten Datenverkehr nicht über globalen sicheren Zugriff.
• Zurzeit ist eine Verbindung über den globalen Secure Access-Client erforderlich, um den Datenverkehr für den privaten Zugriff zu erwerben.
• Datenschutzfunktionen befinden sich in der Vorschau (Authentifizierungsebenenschutz ist allgemein verfügbar).
• Wenn Sie Einschränkungen für universelle Mandanten aktiviert haben und auf das Microsoft Entra Admin Center für einen Mandanten auf der Zulassungsliste zugreifen, wird möglicherweise ein Fehler "Zugriff verweigert" angezeigt. Um diesen Fehler zu beheben, fügen Sie dem Microsoft Entra Admin Center das folgende Featurekennzeichnung hinzu:
  • ?feature.msaljs=true&exp.msaljsexp=true
  • Beispielsweise arbeiten Sie für Contoso. Fabrikam, ein Partnermandant, befindet sich auf der Zulassungsliste. Möglicherweise wird die Fehlermeldung für das Microsoft Entra Admin Center des Fabrikam-Mandanten angezeigt.
    • Wenn Sie die Fehlermeldung "Zugriff verweigert" für die URL https://entra.microsoft.com/erhalten haben, fügen Sie das Feature-Flag wie folgt hinzu: https://entra.microsoft.com/?feature.msaljs%253Dtrue%2526exp.msaljsexp%253Dtrue#home
• Ab Version 1.8.239.0 ist nur der globale Secure Access-Client für Windows bekannt. Auf anderen Plattformen verwendet der Global Secure Access-Client reguläre Zugriffstoken.
• Microsoft Entra ID gibt kurzlebige Token für globalen sicheren Zugriff aus. Die Lebensdauer eines universellen CaE-Zugriffstokens liegt zwischen 60 und 90 Minuten, mit Unterstützung für nahezu echtzeitbasierte Sperrung.
• Es dauert etwa zwei bis fünf Minuten, bis das Microsoft Entra-ID-Signal den Global Secure Access-Client erreicht, und der Benutzer wird aufgefordert, erneut zu authentifizieren.
• Benutzer haben nach Erhalt eines CAE-Ereignisses eine zweiminütige Nachfrist, um die erneute Authentifizierung abzuschließen. Nach zwei Minuten werden vorhandene Netzwerkflüsse über den globalen sicheren Zugriff unterbrochen, bis sich der Benutzer erfolgreich beim Global Secure Access-Client anmeldet.

Einschränkungen des Datenverkehrsweiterleitungsprofils

Bekannte Einschränkungen für Datenverkehrsweiterleitungsprofile umfassen:

• Einzelne Dienste werden dem Microsoft-Datenverkehrsprofil fortlaufend hinzugefügt. Derzeit werden Microsoft Entra ID, Microsoft Graph, Exchange Online und SharePoint Online als Teil des Microsoft-Datenverkehrsprofils unterstützt.
• Zu diesem Zeitpunkt kann der Private Access-Datenverkehr nur mit dem globalen Secure Access-Client erworben werden. Der Datenverkehr für den privaten Zugriff kann nicht aus Remotenetzwerken abgerufen werden.
• Das Tunneln von Datenverkehr zu Zielen des privaten Zugriffs nach IP-Adresse wird nur für IP-Bereiche außerhalb des lokalen Subnetzes des Endbenutzergeräts unterstützt.
• Sie müssen DNS über HTTPS (Secure DNS) deaktivieren, um Netzwerkdatenverkehr basierend auf den Regeln der vollqualifizierten Domänennamen (FQDNs) im Datenverkehrsweiterleitungsprofil zu tunneln.

Einschränkungen für den privaten Zugriff

Zu den bekannten Einschränkungen für den privaten Zugriff gehören:

• Vermeiden Sie überlappende App-Segmente zwischen Schnellzugriffs- und globalen Apps für den sicheren Zugriff.
• Vermeiden Sie überlappende App-Segmente zwischen Schnellzugriff und App-Zugriff.
• Das Tunneln von Datenverkehr zu Zielen des privaten Zugriffs nach IP-Adresse wird nur für IP-Bereiche außerhalb des lokalen Subnetzes des Endbenutzergeräts unterstützt.
• Zu diesem Zeitpunkt kann der Private Access-Datenverkehr nur mit dem globalen Secure Access-Client erworben werden. Remotenetzwerke können dem Profil für die Weiterleitung des privaten Zugriffs nicht zugewiesen werden.

Einschränkungen des Internetzugriffs

Zu den bekannten Einschränkungen für den Internetzugriff gehören:

• Derzeit kann ein Administrator bis zu 100 Webinhaltsfilterrichtlinien und bis zu 1.000 Regeln basierend auf bis zu 8.000 Gesamt-FQDNs erstellen. Administratoren können auch bis zu 256 Sicherheitsprofile erstellen.
• Die Plattform setzt Standardports für HTTP/S-Datenverkehr (Ports 80 und 443) voraus.
• Der globale Secure Access-Client unterstützt IPv6 nicht. Der Client tunnelt nur IPv4-Datenverkehr. IPv6-Datenverkehr wird nicht vom Client erworben und wird daher direkt in das Netzwerk übertragen. Um sicherzustellen, dass der gesamte Datenverkehr an den globalen sicheren Zugriff weitergeleitet wird, legen Sie die Netzwerkadaptereigenschaften auf IPv4-bevorzugtefest.
• UDP wird auf dieser Plattform noch nicht unterstützt.
• Benutzerfreundliche Endbenutzerbenachrichtigungen befinden sich in der Entwicklung.
• Die Remotenetzwerkkonnektivität für Internet Access befindet sich in der Entwicklung.
• Die Transport Layer Security (TLS)-Inspektion befindet sich in der Entwicklung.
• URL-pfadbasierte Filterung und URL-Kategorisierung für HTTP- und HTTPS-Datenverkehr werden entwickelt.