Choix de l'éditeur

Lorsqu'un utilisateur accède à une application privée autorisée, la politique est appliquée dans le nuage Netskope au niveau du nœud NPA Client Gateway. La passerelle client NPA est chargée de sélectionner le(s) éditeur(s) par le(s)quel(s) une connexion doit être acheminée.

Le diagramme ci-dessus décrit les composants du pilotage du trafic sur le site NPA.

• Netskope Client <-> Client Gateway
• Client Gateway <-> Publisher Gateway, c’est-à-dire Stitcher (Netskope New Edge)
• Éditeur <-> Publisher Gateway, c'est-à-dire Stitcher
• Editeur <-> Private App

Les sections suivantes décrivent le comportement attendu lorsque la sélection de l'éditeur en fonction du temps de latence est activée et expliquent le comportement sans la fonction de sélection de l'éditeur en fonction du temps de latence, ainsi que le fonctionnement de l'adhérence.

Sélection d'un éditeur en fonction du temps de latence

Lorsque la fonction de sélection de l'éditeur en fonction de la latence est activée, NPA choisit l'éditeur le plus proche de l'utilisateur dans le pool d'éditeurs configuré, en fonction de la latence.

Cette fonction optimise les performances et fournit un accès plus rapide en sélectionnant les éditeurs en fonction de la latence entre la passerelle NPA et l'éditeur. L'objectif est de réduire la latence entre la passerelle et l'éditeur en sélectionnant l'éditeur dans le groupe de latence le plus bas.

Cas d'utilisation

Lorsque la fonction de sélection de l'éditeur en fonction de la latence est activée pour une application géodistribuée (par exemple, Active Directory Services), on s'attend à ce que l'éditeur le plus optimal (en fonction de la latence) soit sélectionné, ce qui permet d'améliorer les performances et l'expérience de l'utilisateur final.

De même, pour la découverte d'applications, lorsque le champ d'application est défini, l'activation de cette fonction garantit que l'éditeur le plus optimal est choisi pour le trafic de l'utilisateur final.

Comment fonctionne la sélection d'éditeurs basée sur le temps de latence ?

• Le temps de latence entre la passerelle client et l'éditeur de NPA peut être divisé en deux parties :
  • Latence entre la passerelle du client NPA et la passerelle de l'éditeur (Stitcher).
  • Temps de latence entre l'éditeur et la passerelle de l'éditeur (Stitcher)
• La passerelle client NPA prendra des décisions de routage pour les connexions New sur la base d'une recherche de latence entre la passerelle client NPA et les éditeurs.
• Les temps de latence sont enregistrés dans des groupes prédéfinis et la passerelle client NPA préférera l'itinéraire ayant le temps de latence le plus faible.

Les mesures individuelles de latence entre la passerelle client et l'éditeur sont séparées en tranches prédéfinies de plages de latence : (ci-dessous en millisecondes).

Seaux : [0, 32), [32, 64), [64, 128), [128, 256), [256, 512), [512, 1024), etc.

Un algorithme sélectionnera un éditeur dans le panier dont la latence est la plus faible. Par exemple, pour une application privée définie, si nous avons plusieurs éditeurs disponibles, la passerelle sélectionnera l'un des éditeurs dans l'intervalle de latence le plus faible [0-32]. Si aucun des éditeurs n'est disponible dans l'intervalle [0-32] ms, la passerelle essaiera de sélectionner l'un des éditeurs dans l'intervalle [32-64] et ainsi de suite.

Les éditeurs dont les valeurs de latence maximales sont de 32, 64, 128, etc. appartiennent à la catégorie des latences élevées. Par exemple, un éditeur avec une latence de 32 ms tombera dans le compartiment de latence [32,64), et un éditeur avec une latence de 64 ms tombera dans le compartiment de latence [64,128).

Par exemple,

Publisher	Client Gateway to Publisher #n Latence
Éditeur #1	10 ms (preferred route)
Éditeur #2	12 ms (preferred route)
Éditeur #3	42 ms
Éditeur #4	42 ms

Bonnes pratiques pour la sélection d'un éditeur en fonction du temps de latence

• Assurez-vous que les instances régionales de Publisher peuvent gérer le trafic des utilisateurs pour chaque région. Sans la fonction de sélection de l'éditeur basée sur la latence, les utilisateurs risquent de voir leur charge répartie entre les éditeurs des deux régions. Grâce à cette fonction, la sélection de l'éditeur devient plus prévisible et une planification adéquate de la capacité est nécessaire. Par exemple, dans le diagramme, les utilisateurs californiens se connectent aux applications californiennes par l'intermédiaire des éditeurs californiens. Il est impératif que les éditeurs californiens puissent gérer le trafic des utilisateurs californiens.
  
• Netskope recommande de placer les applications privées aussi près que possible de l'éditeur (faible latence).
• Netskope vous recommande d'identifier les applications et les politiques qui bénéficieraient de l'activation de cette fonctionnalité. Idéalement, les instances d'applications distribuées au niveau mondial (telles que les serveurs AD distribués au niveau mondial) avec des éditeurs répartis dans plusieurs régions devraient bénéficier de cette fonctionnalité. On s'attend à ce que l'éditeur le plus optimal (en termes de latence) soit sélectionné.
  Sans sélection basée sur la latence, il est possible qu'un éditeur sous-optimal soit sélectionné.

Comment valider l'efficacité de la sélection des éditeurs basée sur les temps de latence ?

1. Vérifiez que l'évaluation du périphérique indique publisher_selection:true lorsque l'indicateur de sélection de l'éditeur est activé pour le locataire.
   1. Check the device assessment in the npadebuglog.log on the client machine.
   2. The publisher_selection flag should be true.
   3. Voici un exemple de journal provenant d'une machine macOS.
2. Vérifiez que l'interface utilisateur de votre locataire affiche l'éditeur sélectionné avec les détails de la latence.
   1. Dans votre locataire Netskope, allez sur Skope IT > Network Events.
   2. Cliquez sur View Publisher Latency Details, qui affiche le(s) éditeur(s) dans la même tranche de latence, ainsi que la plage de latence.

FAQs

J'ai plusieurs éditeurs associés à une application privée donnée. Comment NPA sélectionne-t-il un éditeur pour un utilisateur ?

Imaginons le scénario suivant :

Application privée	Éditeur associé
#1 Jira	Éditeur n° 1 et Éditeur n° 2
#2 SQL Server	Éditeur n°1, Éditeur n°3 et Éditeur n°4
#3 Web Server	Éditeur n°1, Éditeur n°2, Éditeur n°3 et Éditeur n°4

Supposons également que tous les éditeurs sont connectés à Netskope Cloud et qu'il est possible d'accéder aux applications privées respectives à partir des éditeurs.

Lorsque la sélection de l'éditeur basée sur la latence est activée

Lorsqu'un ensemble d'éditeurs est défini dans une application privée, les connexions sont réparties sur le pool d'éditeurs ayant le moins de temps de latence.

Supposons que l'utilisateur A ait accès aux applications privées n° 2 et n° 3.

Lorsque l'utilisateur A accède pour la première fois à l'application privée n° 2, disons pour l'éditeur n° 1, l'intervalle de latence est de [32,64] ms et les éditeurs n° 3 et n° 4 se trouvent dans l'intervalle de latence de [0,32] ms. Dans ce scénario, lapasserelle NPA peut attribuer au hasard l'éditeur n° 3 car il appartient à l'un des pools d'éditeurs ayant le moins de temps de latence. Toutes les demandes ultérieures pour l'utilisateur A et l'application privée n° 2 passeront par le même éditeur n° 3 tant que l'éditeur reste connecté/actif.

Si le même utilisateur A tente d'accéder à l'application privée n° 3, étant donné qu'il s'agit d'un flux TCP/UDP New, NPA Gateway récupérera la liste des éditeurs actifs pour l'application privée n° 3 et choisira un éditeur dans le pool de seaux avec le moins de latence, et il se peut que ce soit l'éditeur n° 1.

Lorsque l'utilisateur B accède à l'application privée n° 2 pour la première fois, son trafic peut être dirigé vers l'éditeur n° 1, car il peut s'agir de l'un des éditeurs dont la latence est la plus faible pour l'utilisateur B. De même, toutes les demandes ultérieures de l'utilisateur B et de l'application privée n° 2 passeront par le même éditeur n° 1.

On s'attend à ce qu'un éditeur reste fidèle à un utilisateur par application privée. La solidité d'un utilisateur par application privée est maintenue jusqu'à ce que le client obtienne une PRS New ou qu'il se reconnecte au tunnel, ou tant qu'un éditeur reste connecté/actif.

Lorsque la sélection de l'éditeur basée sur la latence n'est pas activée

Lorsqu'un ensemble d'éditeurs est défini dans une application privée, les connexions sont réparties entre les différents éditeurs.

Supposons que l'utilisateur A ait accès aux applications privées n° 1 et n° 2.

Lorsque l'utilisateur A accède pour la première fois à l'application privée n° 1, disons que l'éditeur n° 1 est sélectionné. Toutes les demandes ultérieures pour l'utilisateur A et l'application privée n° 1 passeront par le même éditeur n° 1.

Si le même utilisateur A tente d'accéder à l'application privée n° 2, étant donné qu'il s'agit d'un flux TCP/UDP New, la passerelle NPA récupérera la liste des éditeurs actifs pour l'application privée n° 2 et choisira l'un des éditeurs (éditeur n° 1, éditeur n° 3 et éditeur n° 4).

Lorsque l'utilisateur B accède à l'application privée n° 1 pour la première fois, son trafic peut passer par l'éditeur n° 2, et pas nécessairement par l'éditeur n° 1 comme pour l'utilisateur A. De même, toutes les demandes ultérieures de l'utilisateur B et de l'application privée n° 1 passeront par le même éditeur n° 2.

Comme pour la sélection d'éditeurs basée sur la latence, on s'attend à ce qu'il y ait un maintien de la fidélité de l'éditeur pour un utilisateur par application privée. Cette adhérence est maintenue jusqu'à ce qu'un New SRP est obtenu par le client ou la reconnexion au tunnel, ou tant qu'un éditeur reste connecté/actif.

Où puis-je trouver l'éditeur choisi pour une session ?

L'éditeur sélectionné est visible dans la section Événements du réseau. Dans votre locataire Netskope, accédez à Skope IT > Network Events.