Support Ping pour les applications héritées

Certaines applications et certains scripts hérités envoient un ping ICMP à un serveur et attendent une réponse avant d’ouvrir une connexion TCP ou UDP. Par exemple, un script peut envoyer un ping à plusieurs serveurs de fichiers et se connecter à celui qui répond le plus rapidement. La prise en charge du ping pour Netskope Private Access (NPA) permet à ces applications de fonctionner sans modification.

Lorsque la fonctionnalité est activée, le Netskope Client envoie la requête ping (requête d’écho ICMP) à une application privée via le tunnel NPA. Le Publisher le transfère au serveur d’application, et la réponse d’écho réelle du serveur revient à l’application. NPA ne génère pas de réponses au nom du serveur. Si le serveur, le Publisher ou le chemin est en panne, le ping échoue.

Exigences

• Système d’exploitation pris en charge : Windows. macOS et Linux ne sont pas pris en charge.
• Trafic pris en charge : demande d'écho ICMP IPv4 et réponse d'écho avec des tailles de charge utile par défaut (32 octets sur Windows).

Comment l'accès est contrôlé

• La destination doit être définie dans une application privée vers laquelle l’utilisateur est dirigé. Une politique de protection en temps réel doit également autoriser l’utilisateur à accéder à cette application.
• La correspondance utilise le destination host only. Les ports et protocoles dans la définition de l’application ou la politique sont ignorés pour le ping. Par exemple, un utilisateur autorisé à atteindre fileserver.corp.local sur TCP 445 peut également envoyer un ping à fileserver.corp.local.
• Si aucune application privée ne correspond ou si la politique n'autorise pas l'accès, le ping expire. L'utilisateur ne reçoit pas de réponse « destination inaccessible ».
• Les destinations qui ne sont pas des applications privées, ou qui sont ignorées, ne sont pas affectées. Leurs pings utilisent le réseau local comme avant.
• Vous pouvez envoyer un ping à une application privée par nom d'hôte ou par adresse IP.

Portée et limitations prises en charge

• Seules les demandes echo et les réponses echo sont prises en charge. Les autres types de messages ICMP sont abandonnés, donc traceroute (tracert) does not work via NPA.
• Les tailles de paquets personnalisées ne sont pas prises en charge. Les pings plus grands que le MTU du chemin sont fragmentés, et les pings fragmentés sont supprimés ; ils expirent donc.
• IPv6 et ICMPv6 ne sont pas pris en charge.
• Rate limit: chaque client autorise une rafale de 20 pings, puis 5 pings par seconde. Les pings au-dessus de ce taux sont abandonnés. L’utilisation standard de ping n’est pas affectée.
• Policy changes on Windows: un changement de stratégie, tel que Autoriser en Bloquer, peut prendre environ 30 secondes pour s'appliquer au ping. Windows réutilise la même session de ping, donc le changement s'applique une fois que la session existante est inactive depuis environ 30 secondes.
• Logging: À ce jour, le trafic ping n'est pas enregistré dans les événements réseau.
• Si l’application privée a la validation DNS activée et que l’application est inaccessible, la résolution de nom échoue (« impossible de trouver l’hôte ») et aucun ping n’est envoyé.

Temps de ping

Les temps de aller-retour Ping incluent le chemin ZTNA complet : Client → plan de données Netskope → Éditeur → serveur d'applications. Ils sont également affectés par le tunnel TLS-sur-TCP externe, de sorte qu'une retransmission TCP peut produire occasionnellement une valeur élevée. Lorsque le DNS de l'éditeur est désactivé, le premier ping vers un nom d'hôte peut prendre plus de temps pendant que la destination est résolue. La sélection du chemin peut varier entre les destinations et les connexions.

Ces résultats servent à des fins de compatibilité des applications. Ne les utilisez pas pour mesurer la latence du réseau ou la perte de paquets, ou pour déterminer quel serveur est le plus proche.

Dépannage et support

Le support Netskope n’accepte pas les résultats de ping côté client pour les applications privées NPA comme preuve de diagnostic. Pour les problèmes de connectivité, fournissez les journaux du Publisher et les diagnostics côté Publisher, y compris un ping du Publisher vers le serveur d’application. Utilisez Collecter les journaux à partir d’un Publisher lorsqu’il est activé, ou consultez Dépannage des performances et de la connectivité à l’aide de Ping, Traceroute ou Telnet.