Netskope LogoNetskope Logo
  • Services de sécurité
  • Services d’IA
  • Services de miseenréseau
  • Services d'analyse
  • Intégrations
  • getting-started.svgPour commencer
    • Support
    • Communauté
    • Netskope.com
    © 2026 Tous droits réservés. Netskope Inc.
    Accueil
    Netskope Private Access
    Dépannage de l'accès privé
    Dépannage des performances et de la connectivité à l'aide de Ping, Traceroute ou Telnet

    Dépannage des performances et de la connectivité à l'aide de Ping, Traceroute ou Telnet

    Ce guide couvre la deuxième partie de la vérification de la connectivité des applications via Netskope Private Access (NPA). Elle couvre la vérification de la connectivité entre l'éditeur Netskope et les applications privées et doit être envisagée après l'utilisation du dépanneur Netskope dans l'interface utilisateur et en conjonction avec la vérification de la connectivité entre le client et l'éditeur. Les outils utilisés sont tous des outils courants que l'on trouve dans la plupart des systèmes d'exploitation, et certains sont nativement inclus dans l'éditeur. Des instructions d'installation sont fournies pour les outils qui ne sont pas nativement inclus dans l'Éditeur. Netskope n'approuve ni ne soutient l'installation, la configuration ou le dépannage des outils ci-dessous. Ils sont fournis à titre d'exemple et vous pouvez choisir d'utiliser d'autres outils qui remplissent des fonctions similaires.

    Ping (ICMP)

    Ping est une méthode simple et courante pour vérifier la connectivité. Utilisez-le on the Publisher pour valider que le Publisher peut atteindre l’application, tant que le protocole ICMP n’est pas bloqué sur ce réseau. Ping ne valide pas la connectivité spécifique à un port ou à un protocole.

    Certains tenants ont activé la prise en charge du ping pour les applications héritéesxx, ce qui permet aux clients Windows d’envoyer un ping aux applications privées via NPA. Cette fonctionnalité existe uniquement pour la compatibilité des applications. Les résultats du ping côté client ne permettent pas d’identifier la partie du chemin qui est à l’origine du problème, et le support de Netskope ne les accepte pas comme preuve de diagnostic. Exécutez toujours un ping à partir du Publisher, ou utilisez Collecter les logs à partir d’un Publisher avec le diagnostic Ping et le serveur d’applications comme cible.

    1. Accédez à l'éditeur en SSH à l'aide d'une application de terminal ou d'une application SSH telle que Putty.
    2. Quittez le menu principal de l'éditeur en utilisant l'option Quitter (dépend de la plate-forme, mais 5 dans ce cas).
      image1.png
    3. Effectuez un ping vers le périphérique en tapant ping ip-10-0-0-162.ec2.internal où ip-10-0-0-162.ec2.internal est le nom d'hôte de l'application. En cas de succès, vous devriez obtenir une réponse indiquant les temps de réponse.
      image2.png

      Si vous ne pouvez pas atteindre l'application, vous n'obtiendrez aucune réponse ou un nombre limité de réponses (en cas de perte de paquets).

      image3.png

      A la fin du ping, vous verrez un résumé des informations sur la perte de paquets.

      image4.png

    Traceroute

    Traceroute valide le chemin et la connectivité entre deux hôtes. Il n'est pas installé par défaut sur l'éditeur et présente des limitations similaires à celles d'ICMP, car ICMP est utilisé par traceroute pour déterminer la connectivité à chaque saut du chemin.

    Traceroute n’est pas pris en charge par NPA depuis le client, même si la prise en charge du ping est activée.
    1. Connectez-vous en SSH à l'éditeur à l'aide d'une application de terminal ou d'une application SSH telle que Putty.
    2. Quittez le menu principal de l'éditeur en utilisant l'option Quitter (5 dans le cas d'un éditeur AWS).
      image1.png
    3. Saisissez sudo yum install traceroute pour installer traceroute et confirmez l'installation en saisissant y.
      image5.png
    4. Testez le chemin et la connectivité en entrant traceroute ip-10-0-0-162.ec2.internal où ip-10-0-0-162.ec2.internal est le nom d'hôte que vous dépannez.
      image6.png

    Dans l'exemple ci-dessus, l'éditeur se trouve sur le même sous-réseau que l'application, de sorte qu'il n'y a qu'un seul saut vers l'hôte de l'application. Dans les environnements plus complexes, vous observerez probablement plusieurs entrées, car le trafic peut traverser plusieurs périphériques de réseau entre l'éditeur et l'application.

    Telnet

    Telnet n'est pas installé par défaut sur l'éditeur. Suivez les instructions ci-dessous pour installer telnet.

    1. Accédez à l'éditeur en SSH à l'aide d'une application de terminal ou d'une application SSH telle que Putty.
    2. Quittez le menu principal de l'éditeur en utilisant l'option Quitter (5 dans le cas d'un éditeur AWS).
      image1.png
    3. Saisissez sudo yum install telnet pour installer telnet et confirmez l’installation en saisissant y.
      image7.png
    4. Une fois que telnet est installé, vous pouvez maintenant tester la connectivité sur des ports spécifiques à une application privée spécifique. Par exemple, entrez telnet ip-10-0-0-162.ec2.internal 22 pour tester la connectivité au nom d'hôte ip-10-0-0-162.ec2.internal sur le port 22. Une connexion réussie reflète un état connecté.
      image8.png

      En cas d'échec de la connexion, la connexion ne sera pas rétablie.

      image9.png
    Dans ce thème
    • Dépannage des performances et de la connectivité à l'aide de Ping, Traceroute ou Telnet