Netskope Client Configuration du réseau

Cette rubrique décrit les différentes exigences de configuration du réseau pour Netskope Client en ce qui concerne le Global Server Load Balancing (GSLB) et son fonctionnement.

Exigences en matière de connectivité du client vers l'extérieur

Pour un fonctionnement normal, le site Netskope Client doit être autorisé à se connecter directement aux sous-réseaux, domaines, ports et protocoles indiqués dans les tableaux suivants :

Netskope Client Exigences de la liste de permis des pare-feu

Les destinations, ports et protocoles suivants doivent être autorisés sur votre pare-feu, proxy ou VPN pour que le Netskope Client se connecte et fonctionne correctement. 

Exigences en matière de connectivité de l'éditeur vers l'extérieur

Cette section s'applique à toutes les versions du Private Access Publisher à partir de la version 109.0.0 où la fonction GSLB est activée pour les éditeurs Private Access.

Sélection de la passerelle de gestion du trafic NewEdge

NewEdge Traffic Management 2.0 (GSLB) est une méthode de sélection de passerelle basée sur la latence qui utilise un service API propriétaire hébergé par Netskope au lieu de s'appuyer sur des services tiers tels que Google DNS. Le Global Server Load Balancing (GSLB) offre une meilleure expérience utilisateur en permettant à Netskope d'identifier et de résoudre rapidement les problèmes de réseau, d'améliorer les performances, la stabilité et la résilience. Le site Netskope Client considère maintenant plusieurs centres de données NewEdge proches et calcule la latence (RTT) vers chacun d'entre eux, puis sélectionne le centre de données ayant la latence la plus faible. Si la GSLB ne peut être atteinte, le site Netskope Client revient au comportement précédent de sélection de passerelle basée sur la géolocalisation du DNS étendu (EDNS) et du DNS local (LDNS).

Systèmes d'exploitation pris en charge

GSLB est compatible avec tous les systèmes d'exploitation. Pour plus d'informations, consultez la page « Systèmes d'exploitation et plateformes pris en charge par Netskope Client ».

Conditions préalables

Consultez les tableaux des sections précédentes de cette page pour les exigences de la version client et de la connectivité réseau. Consultez le portail Support pour comprendre les plages IP autorisées pour l’accès sortant sur votre pare-feu.

Assurez-vous également que votre VPN n'est pas configuré pour faire passer ces plages d'adresses IP par un tunnel VPN. Pour en savoir plus sur la compatibilité VPN, consultez les applications VPN.

Processus de sélection de la passerelle GSLB

1. Le site Netskope Client se connecte à l'API de Netskope(gateway.gslb.goskope.com). en utilisant HTTPS (tcp/443) pour demander une liste des centres de données Netskope les plus proches.

2. L'API de Netskope utilise l'IP publique de la demande d'API pour rechercher la géolocalisation du point final.

3. Netskoperépond ensuite avec une liste de centres de données Netskope géographiquement proches.

4. Le site Netskope Client teste la latence vers chacun des centres de données Netskope situés à proximité.

5. Le site Netskope Client utilise ces mesures de latence pour choisir le meilleur centre de données (DC). Il s'agit généralement de celui dont la latence (RTT) est la plus faible ; toutefois, dans certains cas, un DC proche présentant des caractéristiques de latence similaires peut être sélectionné.

   • Si la connexion HTTPS à l'API de Netskopepasse par un VPN, l'IP publique de la demande sera modifiée et la géolocalisation de l'utilisateur sera incorrecte, ce qui peut avoir pour conséquence que Netskope Client se connecte à un centre de données Netskope éloigné du point d'arrivée.
   • Si l'IP publique du point d'extrémité est mal enregistrée dans les bases de données de géolocalisation, le site Netskope Client peut se connecter à un centre de données Netskope éloigné du point d'extrémité.
   • Si la connexion HTTPS à l'API de Netskopeest bloquée, Netskope Client tentera d'utiliser EDNS et LDNS pour la sélection de la passerelle.

Les locataires de Netskope Private Access peuvent désormais profiter des zones basées sur l'intention de NewEdge Traffic Management. Certaines organisations ont des exigences de conformité en ligne (ou "données en mouvement") qui limitent le traitement du trafic en ligne à des régions géographiques spécifiques. Désormais, les locataires de Private Access peuvent restreindre le trafic aux zones prises en charge. Pour en savoir plus : Configurez les zones de gestion du trafic NewEdge par locataire NPA.

Comportement de sélection des passerelles à l'aide d'EDNS et de LDNS

NewEdge Traffic Management 1.0 est une méthode de sélection de passerelle basée sur la géolocalisation qui utilise le DNS. Initialement, le site Netskope Client utilisait EDNS pour résoudre l'un des noms de domaine pleinement qualifiés (FQDN) suivants :

• <tenant>passerelle-[.région].goskope.com

• gateway-backup-<tenant>[.region].goskope.com

  Si la résolution EDNS échoue, le site Netskope Client utilise LDNS pour résoudre les FQDN de la passerelle.

  Processus de sélection de la passerelle EDNS

  Reportez-vous aux instructions suivantes pour comprendre le processus de sélection de la passerelle EDNS :

  1. Le se Netskope Client connecte au DNS Google (dns.google) via DNS via HTTPS (tcp/443) pour demander une adresse IP pour la<tenant>passerelle[.region].goskope.com.

  2. Google DNS utilise l'adresse IP publique de la requête DNS over HTTPS pour rechercher la géolocalisation du point final.

  3. Le DNS de Google résout ensuite gateway-<tenant>[.region].goskope.com vers le centre de données Netskope géographiquement le plus proche de l'adresse IP publique du point de terminaison.

  4. Le site Netskope Client se connecte au centre de données Netskope en utilisant l'adresse IP fournie.

     • Si la connexion DNS sur HTTPS passe par un VPN, l'IP publique de la requête est modifiée et l'utilisateur est mal géolocalisé, ce qui peut conduire à ce que le site Netskope Client se connecte à un centre de données Netskope éloigné du point d'extrémité.
     • Si l'IP publique du point d'extrémité est mal enregistrée dans les bases de données de géolocalisation, le site Netskope Client peut se connecter à un centre de données Netskope éloigné du point d'extrémité.
     • Si la connexion DNS via HTTPS est bloquée, le Netskope Client tente d’utiliser LDNS pour résoudre la<tenant>passerelle-[.region].goskope.com.

Processus de sélection de la passerelle LDNS

Reportez-vous aux instructions suivantes pour comprendre le processus de sélection de la passerelle LDNS :

1. Le Netskope Client utilise le serveur DNS configuré du point de terminaison en utilisant le DNS standard (udp/53) pour résoudre gateway-<tenant>[.region].goskope.com.

2. Le site Netskope Client se connecte au centre de données Netskope en utilisant l'adresse IP fournie.

   Si l'IP publique du serveur DNS est enregistrée à une distance géographique éloignée du point d'extrémité, le site Netskope Client peut se connecter à un centre de données Netskope éloigné du point d'extrémité. Par exemple, si le terminal se trouve à San Jose, en Californie, mais qu'il est configuré pour utiliser un serveur DNS d'entreprise situé à Ashburn, en Virginie, le terminal se connectera à un centre de données Netskope près d'Ashburn, en Virginie. Il en résulterait un temps de latence supplémentaire significatif pour toute la connectivité Internet et Private Access via Netskope.

Repli de la GSLB en Chine

Avec la sortie de la version 121.0.7, pour les locataires utilisant les POP de Netskopeen Chine, le périphérique utilisant Netskope Client en dehors de la Chine peut maintenant se rabattre sur EDNS puis sur LDNS lorsque GSLB n'est pas joignable. Dans le même temps, les périphériques ayant Netskope Client en Chine continuent d'utiliser exclusivement GSLB pour s'assurer que ces utilisateurs ne se connectent qu'à Netskope POP en Chine.

Valider EDNS/LDNS 

Vous pouvez vérifier l'indicatif de pays dans vos journaux lors du débogage :

• Si le site se trouve en Chine :

  2024/09/25 17:33:58.421 stAgentSvc p1d14 t1ed8 info GatewaySelection.cpp:139 gslb [NSClient] Pops fetched begin rtt_protocol:tcp country:CN

• Si le lieu est situé en dehors de la Chine :

  2024/09/25 09:09:52.105766 stAgentNE p14257 t15367 info GatewaySelection.cpp:139 gslb [NSClient] Pops fetched begin rtt_protocol:http country:US

Netskope Client dans un environnement sans procuration

Voici les détails du flux de paquets de la manière dont le trafic de l'application cloud est intercepté et envoyé à travers le tunnel lorsque le client est installé dans un environnement sans proxy :

Netskope Client dans un environnement proxy explicite

Voici les détails du flux de paquets de la façon dont le trafic de l'application Cloud est intercepté et envoyé à travers le tunnel lorsque le client est installé dans un environnement de proxy explicite :

1. Le client établit le tunnel SSL entre le client et la passerelle Netskope. Le client tente d'abord de se connecter directement via la passerelle par défaut pour établir le tunnel SSL. Si cela est bloqué, il recherche alors les paramètres proxy du système, tels que les fichiers PAC (proxy auto-config), WPAD (Web Proxy Auto-Discovery Protocol) et la configuration manuelle. Le client utilise les paramètres du proxy et se connecte à la passerelle Netskope via HTTP Connect.

   La passerelle Netskope doit être inscrite sur la liste d'autorisation SSL si le proxy est configuré pour le décryptage SSL. Si votre environnement utilise un pare-feu ou un proxy, veillez à traiter l'URL de la passerelle de secours de la même manière que l'URL de la passerelle principale. L'URL de la passerelle de secours est suffixée par gateway-backup à votre URL principale.

2. Le navigateur ou l'application native lit les paramètres du proxy (fichier PAC, paramètres du proxy explicite) et ouvre une connexion à un serveur proxy explicite, par exemple : ep.customer.com.

3. Le client analyse l'en-tête initial de la connexion.

4. Si l'en-tête initial indique que la connexion est :

   • Mode cloud (application SaaS) : L'en-tête initial indique le nom d'hôte de l'application SaaS. Si le nom d'hôte ne fait pas partie de la configuration de l'exception de l'application SaaS gérée, le client contourne le trafic vers un serveur proxy local.

   • Web et All Traffic : L'en-tête initial indique le nom d'hôte de l'application web. Si le nom d'hôte fait partie de l'exception, le client contourne le trafic vers un serveur proxy local. Dans le cas contraire, le trafic est acheminé vers la passerelle Netskope.

5. Si l'en-tête initial n'indique pas l'accès à SaaS app HTTPS, Netskope Client contourne le trafic et transmet l'intégralité de la charge utile au serveur mandataire explicite. Par exemple : ep.customer.com.

Netskope Client Messages de journalisation avec le proxy sur site

Steering traffic flow and Log message: Avec le proxy on-prem, le site Netskope Client surveille les demandes HTTP CONNECT. Il vérifie si le nom de domaine contenu dans ces demandes est conforme à la liste des domaines gérés. Si le nom correspond, il reconstruira le paquet TCP SYN et l'enverra à travers le tunnel Netskope et, en même temps, il enverra TCP RST au proxy on-prem, et prendra le contrôle de cette connexion. Après la poignée de main TCP à trois voies avec le proxy Netskope, il envoie la requête HTTP CONNECT et le flux se poursuit avec le proxy Netskope. Puisque le flux TCP sera avec l'IP de destination du proxy on-prem lorsque Netskope Client enregistrera le message, il montrera l'IP de destination comme Proxy on-prem et le nom de domaine sera le domaine géré.

Si l'adresse IP du proxy local est 10.10.10.11, le port du proxy est 8080 et le domaine géré est www.box.com, vous verrez la ligne de journal suivante :

2021/07/18 17:16:11.282 stAgentSvc pfbc t296c 4 tunnel.cpp:618 nsTunnel TLS [sessId 1]
Tunneling flow from addr: 192.168.13.40:49614, 
process: chrome.exe to host: www.box.com,addr: 10.10.10.11:8080