Accéder à des segments d'application privés à l'aide d'un PQDN

Lors de la migration vers des solutions basées sur ZTNA, vous souhaiterez peut-être conserver la même expérience utilisateur pour vos utilisateurs. L'une des exigences les plus fréquentes est la capacité à prendre en charge l'accès aux applications par PQDN (nom court). Par exemple, au lieu de app1.example.com, un utilisateur pourrait taper app1 dans le navigateur.

Lorsque la fonction de prise en charge des domaines de recherche multiples est activée, le site Netskope Client prend en charge l'accès à l'aide des PQDN. Le site Netskope Client pourra itérer (de haut en bas) à travers les multiples domaines de recherche et valider les domaines après avoir ajouté des domaines de recherche.

Comment fonctionne la fonction "Multi Search Domains" ?

• Aucune configuration supplémentaire n'est requise dans l'interface web pour que cela fonctionne.
• Le site Netskope Client intercepte et valide la résolution des domaines en transmettant les requêtes DNS (en parcourant la liste) à l'éditeur pour les différents domaines de recherche.
• Attribuez une IP stub (100.64.0.0/16) uniquement si un domaine correspondant à la SRP peut être résolu sur l'éditeur.
• Si l'éditeur renvoie NXDOMAIN, la requête DNS est renvoyée au réseau local.
• Les réponses valides (stub IP - 100.64.0.0/16) sont mises en cache par le client.
• La validation DNS de l'éditeur reste effective, attribuant une IP réelle si le domaine peut être résolu sur l'éditeur.

Considérations importantes

• Pour que cette fonctionnalité fonctionne, il faut que la fonction Wildcard App Validation soit activée. Cette fonction est automatiquement activée en même temps que la fonction de prise en charge de domaines de recherche multiples; toutefois, si la fonction de validation d'application Wildcard est explicitement désactivée, la prise en charge de domaines de recherche multiples cessera de fonctionner.
• Il est prévu que la configuration et la résolution du serveur DNS soient identiques pour les éditeurs affectés à une application.
• En cas de correspondances multiples de domaines de recherche valides, seul le premier domaine valide de haut en bas fonctionnera.
• C'est l'administrateur qui doit gérer et contrôler les domaines de recherche, et non Netskope Client.
• Si le domaine saisi par l'utilisateur (PQDN ou FQDN) correspond à une définition d'application joker dans la SRP, le site Netskope Client envoie une requête DNS à l'éditeur pour déterminer si le domaine peut être résolu. Le comportement du FQDN avec cette fonctionnalité est expliqué dans les scénarios 2 et 3 ci-dessous. Essentiellement, lorsque la prise en charge des domaines de recherche multiples est activée, l'accès aux FQDN continue de fonctionner.

Cas d'utilisation

Scenario 1

• Private App Segment definition : *.acme.com (wildcard app definition).
• Les domaines de recherche DNS configurés sur l’adaptateur réseau (dans l’ordre) : *.acme.com, *.acme.local, *.eu.acme.com
• L'utilisateur final tape jira (PQDN) dans un navigateur pour accéder à l'application. Le domaine auquel l'utilisateur final a l'intention de se connecter est le suivant jira.eu.acme.com

Le comportement attendu est le suivant :

Step	Description
1	Le site Netskope Client apprend tous les domaines de recherche configurés sur la carte réseau.
2	Le site Netskope Client ajoute les domaines de suffixe de haut en bas et transmet les demandes DNS à l'éditeur pour validation.
3	La première requête DNS correspondant à SRP est jira.acme.com. L'éditeur renvoie NXDOMAIN au client.
4	Le domaine de suffixe suivant *.acme.local ne correspond pas à SRP et passe donc au domaine suivant.
5	Le client tente le domaine de suffixe suivant *.eu.acme.com (correspondance SRP) et transmet la demande DNS à l'éditeur.
6	Une fois que la résolution de jira.eu.acme.com a été effectuée avec succès par l'éditeur, le client en est informé, apprend la position du domaine de recherche valide et une adresse IP fictive lui est attribuée et mise en cache. L'accès à l'application réussit.

Scenario 2

• Private App Segment definition : *.acme.com (wildcard app definition).
• Les domaines de recherche DNS configurés sur l’adaptateur réseau (dans l’ordre) : *.acme.com, *.acme.local, *.eu.acme.com
• L'utilisateur final tape jira.eu.acme.com (FQDN) dans un navigateur pour accéder à l'application.

Le comportement attendu est le suivant :

Step	Description
1	Le site Netskope Client apprend tous les domaines de recherche configurés sur la carte réseau.
2	Le site Netskope Client ajoute les domaines de suffixe de haut en bas et transmet les demandes DNS à l'éditeur pour validation.
3	Lorsque la requête correspondant à la définition de l’application est un joker (dans ce cas, *.acme.com) et que cette fonctionnalité est activée, la première requête DNS envoyée au publicateur concerne jira.acme.com et non jira.eu.acme.com. L’éditeur renvoie NXDOMAIN pour jira.acme.com au client.
4	Le domaine de suffixe suivant *.acme.local ne correspond pas à SRP et passe donc au domaine suivant.
5	Le client tente le *.eu.acme.com de domaine du suffixe suivant (correspondance SRP) et tunnellise la requête DNS pour jira.eu.acme.com vers l’éditeur.
6	Une fois que la résolution de jira.eu.acme.com a abouti sur l'éditeur, le client en est informé, apprend la position du domaine de recherche valide dans la liste et une adresse IP fictive est attribuée et mise en cache. L'accès à l'application réussit.

Scenario 3

• Private App Segment definition : jire.eu.acme.com (FQDN app definition).
• Les domaines de recherche DNS configurés sur l’adaptateur réseau (dans l’ordre) : *.acme.com, *.acme.local, *.eu.acme.com
• L'utilisateur final tape jira.eu.acme.com (FQDN) dans un navigateur pour accéder à l'application.

Le comportement attendu est le suivant :

Step	Description
1	Le FQDN saisi par l'utilisateur correspond exactement à la définition de l'application, aucune autre validation n'est donc nécessaire. Cela signifie également qu'aucune requête DNS n'est transmise à l'éditeur.
2	Le site Netskope Client attribue une adresse IP de base au site jira.eu.acme.com et est mis en cache. L'accès à l'application réussit.