Méthodes générales de dépannage

Comment puis-je savoir que l'utilisateur/OU est autorisé à se rendre sur le site Private Access?

Ouvrez le fichier nsdebuglog.log et recherchez le mot enroll. Vous pouvez voir plus de détails sur la raison pour laquelle le processus d'inscription ne fonctionne pas pour l'utilisateur.

Le bilan de santé de l'éditeur dans l'interface utilisateur de Netskope montre-t-il qu'il est capable de se connecter à l'application ?

Si l'application privée est définie avec une liste de ports TCP/UDP, seul le premier port est vérifié pour la connectivité. L'état ne dépend pas de l'accessibilité de tous les ports définis. Cela peut donner l'impression, à tort, que l'éditeur peut se connecter avec succès à tous les ports définis.

L'éditeur peut-il atteindre l'application privée définie du point de vue du routage et de la politique ?

1. SSH à l’éditeur (nom d’utilisateur ubuntu.)
2. Choisissez l'option n° 3 pour quitter le menu.
3. Saisissez su. Cela vous permettra d'entrer dans la racine.
4. Saisissez apt-get install traceroute -y.
5. Essayez de traceroute vers l'adresse IP locale/le nom de domaine de l'application privée.

L'éditeur peut-il atteindre l'application privée définie sur TOUS les ports définis ?

1. SSH à l'éditeur.
2. Saisissez su. Cela vous permettra d'entrer dans la racine.
3. Saisissez apt-get install telnet -y.
4. Essayez de connecter par telnet à l’adresse IP locale / nom de domaine de l’application privée : telnet <hostname><port>.

S'il se connecte, tout va bien. Si ce n'est pas le cas, c'est qu'une politique de sécurité du réseau ou de l'hôte empêche l'éditeur de communiquer avec le serveur pour le port défini.

Les limites du descripteur de fichier ouvert d'OSX doivent-elles être augmentées ?

OSX a une limite basse de 256 descripteurs de fichiers (par défaut), ce qui est problématique si vous avez un trafic d'accès au réseau important. Vérifiez d'abord vos limites actuelles, puis créez une limite personnalisée pour pallier cette limitation.

Trouvez les limites par défaut/actuelles de votre système

Exécutez les commandes suivantes pour connaître la limite souple et la limite stricte de votre système.

1. Pour trouver la limite souple, exécutez : ulimit -Sn Exemple de sortie : % ulimit -Sn 256
2. Pour connaître la limite stricte, exécutez : ulimit -Hn Exemple de sortie : % ulimit -Hn unlimited

Définir des limites personnalisées

1. Exécutez : sudo touch /Library/LaunchDaemons/limit.maxfiles.plist
2. Ouvrez le fichier dans votre éditeur de fichiers préféré et collez les données suivantes comme contenu du fichier. <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>limit.maxfiles</string> <key>ProgramArguments</key> <array> <string>launchctl</string> <string>limit</string> <string>maxfiles</string> <string>25600</string> <string>100000</string> </array> <key>RunAtLoad</key> <true/> <key>ServiceIPC</key> <false/> </dict> </plist>
3. Vous pouvez remplacer les limites par les valeurs de votre choix. La limite stricte doit être inférieure à ce que votre système prend en charge, qui est la sortie de ulimit -Hn. Lors de la définition d'une valeur personnalisée, OSX ne permet actuellement pas de définir la limite stricte comme unlimited, vous devez donc la définir sur une valeur élevée. Dans l'exemple ci-dessus, la limite souple est 25600 et la limite dure est 100000.
4. Enregistrez le fichier et redémarrez le système.
5. Après le redémarrage du système, vérifiez les limites actuelles en exécutant les commandes suivantes. Pour vérifier la limite souple, exécutez : ulimit -Sn Exemple de sortie : % ulimit -Sn 256 Pour vérifier la limite dure, exécutez : ulimit -Hn Exemple de sortie : % ulimit -Hn 100000.

L'application privée dispose-t-elle d'un groupe de sécurité/ACL qui bloque l'accès à l'adresse IP de l'éditeur ?

C'est le cas lorsque l'éditeur est déployé dans un environnement IaaS comme AWS. Vérifiez le groupe de sécurité de l'hôte. Tout le trafic vers l'application privée définie sera perçu sur le réseau local comme provenant de l'adresse IP du client.

Existe-t-il une politique de protection en temps réel permettant à l'utilisateur d'accéder à l'application privée ?

Dans l'interface utilisateur de Netskope, allez sur Policies > Real-time Protection et vérifiez que l'utilisateur/OU autorise l'utilisateur pour l'application privée.

La politique en temps réel que vous venez d'appliquer est-elle entrée en vigueur ?

Ouvrez le fichier npadebuglog.log dans un éditeur de texte. Recherchez le nom de votre application privée tel que défini dans l'application privée du locataire Netskope.

Pour les fenêtres : C:UsersPublicnetSkopenpadebuglog.log

Pour MacOS : /Library/Logs/Netskope/npadebuglog.log

Si vous ne trouvez aucune mention du nom de votre application privée dans ce fichier, vous ne pourrez pas vous connecter à l'application privée. Cela peut être dû au fait que l'utilisateur n'est pas autorisé à utiliser cette application privée (vérifiez la politique de protection en temps réel).

Les certificats racine à signature croisée sont-ils pris en charge lors de la configuration des certificats d'applications privées pour les URL personnalisées avec accès au navigateur NPA ?

Netskope prend en charge les certificats racine auto-signés. Les certificats racine à signature croisée ne sont pas pris en charge dans le fichier de la chaîne de certificats. Si des certificats racine à signature croisée sont utilisés, vous verrez apparaître l'erreur Aucun certificat racine n'a été trouvé.

Par défaut, Let's Encrypt CA créera une chaîne de certificats à l'aide de l'autorité de certification racine X1 de l'EIGR et de l'autorité de certification racine X3 de la DST. C'est ce qui provoque l'erreur.

Workaround

Retirez le certificat ISRG Root X1 signé de la chaîne de certificats, qui devrait se trouver en bas. Ajoutez ensuite le certificat ISRG Root X1 auto-signé, qui peut être téléchargé ici.