Qu’est-ce que Netskope Private Access ?

La configuration matérielle de Netskope Private Access diffère d’un environnement de déploiement à l’autre. Pour en savoir plus, consultez ces articles : Configuration matérielle pour un éditeur Netskope Private Access.

Pour connecter des utilisateurs avec des applications et des services, un administrateur de Netskope Private Access doit configurer des politiques d’application privées au sein de l’interface utilisateur de Netskope à quelques endroits. Voici les options de configuration et les détails des types d’application et de service connus.

Application	Protocole et port	Facteurs
Trafic Web	TCP : 80, 443 (ports personnalisés : 8080, etc.) UDP: 80, 443	Google Chrome utilise le protocole QUIC (HTTP/S sur UDP) pour certaines applications Web. La duplication des ports de navigation Web pour TCP et UDP peut améliorer les performances.
SSH	TCP : 22
Remote Desktop (RDP)	TCP : 3389 UDP: 3389	Certaines des applications client Windows Remote Desktop Protocol (RDP) (telles que les versions de Windows 10 récentes) préfèrent utiliser UDP : 3389 pour effectuer une connectivité de Bureau distant.
Windows SQL Server	TCP : 1433, 1434 UDP: 1434	Le port par défaut pour Windows SQL Server est 1433, mais il peut être personnalisé dans vos environnements. Pour plus d’informations, consultez Configurer le pare-feu Windows pour autoriser l’accès à SQL Server (https://docs.microsoft.com/sql/sql-server/install/configure-the-windows-firewall-to-allow-sql-server-access?view=sql-server-2017).
MySQL	TCP : 3300-3306, 33060 TCP: 33062 (pour les connexions propres à l’administrateur)	Pour les cas d’utilisation de connexion MySQL généraux, seul le port 3306 est requis, mais certains utilisateurs peuvent profiter de ports de fonctionnalité MySQL supplémentaires. Netskope recommande d’utiliser une plage de ports pour les applications privées de base de données MySQL. MySQL bloque les connexions de Netskope Private Access, car il détecte le test d’accessibilité comme une attaque potentielle. L’utilisation d’une plage dans la configuration des ports fait que l’éditeur Netskope Private Access effectue une vérification de l’accessibilité uniquement sur le premier port de la plage. Cela empêche MySQL de voir ce trafic et d’éviter le blocage du port. Pour plus d’informations, consultez les tableaux de référence des ports MySQL (https://dev.mysql.com/doc/mysql-port-reference/en/mysql-ports-reference-tables.html).

Oui. Netskope Private Access peut acheminer les applications en dehors de cette liste. Netskope Private Access prend en charge à la fois les protocoles TCP et UDP et tous les ports associés, avec une exception notable : Netskope ne réalise pas de protocole de tunnel du trafic DNS, mais nous prenons en charge les recherches par tunnel des services DNS (SRV) sur le port 53. Ce processus est nécessaire pour la découverte des services, qui est utilisée dans divers scénarios Windows Active Directory impliquant LDAP, Kerberos, etc.

L’intervalle d’interrogation dure environ une minute.

L’éditeur Netskope Private Access tente de se connecter à un port configuré sur une application privée pour vérifier si celle-ci est accessible.

Facteurs importants à prendre en compte :

• L’éditeur fonctionne mieux lorsque vous définissez des applications privées par nom d’hôte (par exemple, jira.globex.io) et port (par exemple, 8080).
• Lorsqu’une application est spécifiée avec plusieurs ports ou une plage de ports, l’éditeur utilise uniquement le premier port de la liste ou de la plage pour vérifier la disponibilité.
• L’éditeur ne peut pas vérifier l’accessibilité pour les applications privées qui sont définies à l’aide d’un caractère générique (*.globex.io) ou d’un bloc CIDR (10.0.1.0/24). Il ne vérifie pas non plus l’accessibilité des applications avec des plages de ports définies (3305-3306).

En cas d’échec de l’enregistrement (par exemple, parce qu’il manque un chiffre dans le code d’enregistrement saisi), utilisez le protocole SSH dans l’éditeur et fournissez un nouveau jeton d’enregistrement.

Si l’enregistrement a réussi, mais que vous avez décidé d’enregistrer l’éditeur avec un autre jeton, cela n’est pas pris en charge et n’est pas recommandé. Dans ce scénario, réinstallez l’éditeur.

Non. Netskope Private Access n’effectue pas de protocole de tunnel ICMP, mais uniquement TCP et UDP. Vous ne pouvez pas exécuter ping ou traceroute sur Netskope Private Access pour tester les connexions réseau.

Non. Netskope Private Access ne prend pas en charge les protocoles qui établissement des connexions d’une application privée vers un client. Par exemple, le mode actif FTP n’est pas pris en charge.

Non. L’éditeur effectue l’épinglage SSL pour le processus d’enregistrement et l’authentification du certificat côté serveur par rapport à un certificat spécifique.

Dans ce cas, s’il existe un proxy qui met fin à la connexion TLS, la destination doit être sur liste blanche/contournée (*.newedge.io).

L’hôte de l’application privée voit la connexion comme provenant de l’adresse IP de l’éditeur qui s’y connecte. Il n’existe aucune plage. En fonction du nombre d’éditeurs utilisés pour se connecter à l’hôte de l’application privée, placez sur liste blanche chacune de ces adresses IP.

S'il est déployé dans Amazon Web Services, attribuez l'AMI (Amazon Machine Image) à un fichier KeyPair.pem que vous possédez déjà (ou générez un nouveau KeyPair.pem) au cours du provisionnement de l'éditeur.

Depuis un client SSH, saisissez ssh -i [KEYPAIR.PEM] centos@[PUBLISHER], puis appuyez sur Entrée.

Après avoir réussi à utiliser SSH pour vous connecter à l’éditeur, vous êtes redirigé vers un menu d’interface de ligne de commande (CLI) interactif. Vous pouvez choisir l’option 3 pour être redirigé vers une CLI UNIX normale pour un dépannage supplémentaire. Pour plus d’informations, consultez la section Quelles sont les bonnes méthodes de dépannage des problèmes d’accessibilité à une application/un service privé derrière un éditeur ? (en anglais).

1. Cliquez avec le bouton droit de la souris sur le menu Démarrer de Windows, puis cliquez sur Exécuter.

2. Dans l’interface d’exécution, saisissez cmd, puis appuyez sur OK.

3. Dans l'invite de commandes, saisissez ssh centos@[publisher], puis appuyez sur Entrée.

Les éditeurs fonctionnent en mode actif/passif. Tout le trafic est transmis à un premier éditeur s’il est opérationnel (connecté). S’il tombe en panne, nous basculons vers un éditeur secondaire.

La première option consiste à utiliser l’utilitaire de dépannage. Cliquez sur Utilitaire de dépannage à partir de la page des applications privées.

Sélectionnez l'application privée et l'appareil auxquels vous tentez d'accéder, puis cliquez sur Dépanner.

L’utilitaire de dépannage des problèmes restitue la liste des contrôles effectués, les problèmes susceptibles d’affecter votre configuration, ainsi que les solutions.