Netskope Private Access peut-il coexister avec d'autres clients VPN ?
Netskope prend en charge le modèle de déploiement suivant pour Netskope Private Access en présence d'un autre client VPN sur le périphérique de l'utilisateur.
Le tunnel Netskope Private Access dans le Netskope Client peut activement transmettre le trafic, à condition que le client VPN soit désactivé et que le tunnel VPN n'intercepte pas activement et/ou ne transmette pas le trafic aux applications privées (y compris le DNS).
Le client utilise-t-il un ordre quelconque pour faire correspondre les hôtes définis dans les applications privées ? Si vous avez des sous-réseaux, des sous-domaines, des caractères génériques et des hôtes, dans quel ordre le client essaiera-t-il de faire correspondre le trafic ?
L'ordre vertical de correspondance des règles est le suivant :
- Hôte ou IP (sans joker)
- Subnet (CIDR)
- Subdomain
L'ordre horizontal n'est pas garanti, sauf pour les sous-domaines, qui correspondent d'abord au préfixe le plus long.
Voici un exemple d'ordre horizontal :
- App1 : 10.10.0.0/23
- App2 : 10.10.0.0/24
- App3 : myserver.mydomain
Sous-réseau : App1, App2 sont au même niveau, et donc horizontaux.
Sous-domaine : App3
La passerelle/client trouvera d'abord App1 et App2, puis App3.
Quels sont les services et les intervalles d'interrogation utilisés par un éditeur pour vérifier si une application ou un service privé est disponible ?
L'intervalle d'interrogation est d'environ 1 minute.
The Publisher will try to connect to a configured port on a Private App to check whether the private app is reachable.
Facteurs importants à prendre en compte :
- L'éditeur fonctionne mieux lorsque vous définissez l'application privée par nom d'hôte (comme
jira.globex.io) et port (comme8080). - When a Private App is specified with a port range, the Publisher will use only the first port from the range to check availability. For example, port range 70-90 will return unreachable, even if you are listening on port 80, because the only port that will be checked is 70 (this is a known limitation).
- Si une définition d’application spécifie des ports et/ou des plages de ports, elle vérifiera si l’un d’eux est accessible. Par exemple, si vous spécifiez 22, 70-90, si elle peut atteindre le port 22, elle marquera l’application comme accessible.
L’éditeur ne peut pas vérifier la portée des applications privées définies avec un joker (*.globex.io) ou un bloc CIDR (10.0.1.0/24).
Comment revenir au menu de configuration pendant une session SSH de l'éditeur ?
Depuis le dossier /home/ubuntu , entrez sudo ./npa_publisher_wizard.
Comment Netskope gère-t-il la connexion d'une application lorsque l'utilisateur final met fin à une session ?
Netskope met fin au tunnel de bout en bout entre l'éditeur et l'application finale à la fin de la session dans SSH et d'autres flux basés sur TCP.
Les éditeurs prennent-ils en charge la fonction Active-Active dans le cas où plusieurs éditeurs ont accès à la même application privée ?
Les éditeurs travaillent en mode actif-actif. Le mode actif-actif permet d'augmenter le débit. Jusqu'à 16 éditeurs sont pris en charge dans un déploiement actif-actif par application. Pour plus d'informations sur la sélection des éditeurs, cliquez ici.
Que se passe-t-il si le jeton d'enregistrement de l'éditeur est corrompu au cours de la phase de déploiement initial ? Puis-je le réinitialiser localement chez l'éditeur ?
Si l'enregistrement a échoué (par exemple, parce que vous avez oublié un chiffre du code d'enregistrement), vous pouvez vous connecter en SSH à l'éditeur et fournir un jeton d'enregistrement New.
Si l'enregistrement a réussi, mais que vous avez décidé d'enregistrer l'éditeur avec un autre jeton, cette opération n'est pas officiellement prise en charge et n'est pas conseillée. Vous devrez réinstaller l'éditeur.
Dans l'interface utilisateur de Netskope, mon deuxième éditeur (ou les suivants) apparaît comme étant connecté à un ancien enregistrement d'éditeur. Et maintenant ?
Il pourrait s'agir d'un problème connu. Si vous avez copié votre New Publisher à partir d'un ancien Publisher (fonctionnel), vous avez probablement rencontré ce problème. Par exemple, la création d'une image AMI à partir d'une instance EC2 fonctionnelle connue, puis le lancement d'une instance New à partir de cette image AMI, est un exemple d'une façon de résoudre ce problème.
Veuillez contacter le support Netskope ou créer un éditeur New plutôt que de copier une AMI ou une image.
Quelle est la capacité de la bande passante d'un éditeur ?
Un éditeur individuel peut gérer un débit d'environ 500 Mbps et environ 32 000 connexions UDP ouTCP simultanées.
A combien de temps d'arrêt dois-je m'attendre pendant les mises à jour de Publisher et/ou le basculement vers un Publisher secondaire ?
Éditeur unique : 1 à 3 minutes pendant que le système est mis à niveau jusqu'à ce que l'éditeur apparaisse.
Éditeurs HA : Moins de 5 secondes lorsque le trafic passe aux autres éditeurs dans la définition de l'application.
Puis-je réinscrire un éditeur existant ?
Non. La réinscription d'un éditeur n'est pas possible actuellement.
L'éditeur peut-il utiliser la fonctionnalité de mise à l'échelle automatique des plateformes de cloud public ?
Oui. Les éditeurs Netskope peuvent utiliser les capacités natives d'autoscaling des plateformes de Cloud public via l'API REST de Netskope ou des outils d'automatisation tels que Terraform.
Peut-on configurer syslog sur un éditeur ?
Oui. Les étapes de base sont les suivantes :
- Connectez-vous en SSH à l'éditeur.
- Select l’option du menu Configure syslog.
- Indiquez l'hôte/IP et le port du serveur syslog.
- L'éditeur redémarre pour appliquer les paramètres et envoie ces entrées au serveur syslog configuré.
Pour l'autorisation de l'application privée, quelle adresse IP est vue au niveau de l'application privée depuis le NPA ?
L'hôte de l'application privée considère que la connexion provient de l'adresse IP de l'éditeur qui se connecte à lui. Il n'y a pas de plage, mais en fonction du nombre d'éditeurs utilisés pour se connecter à l'hôte de l'application privée, vous devrez autoriser la liste de chacune de ces adresses IP.
Quel accès doit être autorisé pour que le NPA fonctionne correctement ?
| Composant | URL | Port | Notes |
|---|---|---|---|
| Client |
| TCP 443 (HTTPS) |
|
| Publisher |
| TCP 443 (HTTPS) UDP 53 (DNS) TCP 80 (HTTP) pour *.ubuntu.com |
|
| Client et éditeur |
| TCP 443 (HTTPS) | Requiert un accès sortant lors de l'inscription ou de la réinscription du NPA pour le client et pour l'enregistrement de l'éditeur.
Exemple d'URL : Variables MP-Name :
Note N'autorise l'accès entrant que si vous utilisez un serveur CRL maintenu en interne dans votre infrastructure pour l'inscription Prelogon, ou si vous activez l'accès par navigateur. Cela n'est pas nécessaire pour le trafic de données. Pour l'autorisation de |
| Client et éditeur |
| TCP 443 (HTTPS) |
Netskope abandonne les anciens mécanismes EDNS et LDNS au profit de DNS et de DNS-over-HTTPS. Pour la plupart des clients, les règles DNS seront utilisées comme mécanisme de repli, et c'est la méthode préférée, ce qui signifie que le mécanisme principal est une connexion API via HTTPS à notre passerelle GSLB. Consultez vos contacts techniques chez Netskope pour valider les règles exactement nécessaires. |
| Client et éditeur | dns.google | TCP + UDP 53 (DNS) TCP 443 (DNS sur HTTPS / DoH) |
|
Je ne suis pas certain des ports TCP/UDP dont mon application a besoin pour fonctionner. Que puis-je faire ?
Pour connecter les utilisateurs aux applications/services, un administrateur NPA doit configurer les politiques d'applications privées dans l'interface utilisateur Netskope à quelques endroits. Voici les options de configuration et les détails pour les types d'applications/services connus.
| Application | Protocol/Port | Factors |
|---|---|---|
| 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, de sorte que la duplication des ports de navigation web pour TCP et UDP peut améliorer les performances. |
| Secure Shell (SSH) | TCP: 22 | |
| Bureau à distance (RDP) | TCP: 3389 UDP: 3389 | Certaines applications clientes Windows RDP (en particulier, New versions Windows 10) préfèrent désormais utiliser UDP:3389 pour effectuer la connectivité au bureau à distance. |
| Windows SQL Server | TCP: 1433, 1434 UDP: 1434 | Le port par défaut pour Windows SQL Server est le 1433, mais il peut être personnalisé dans vos environnements. Pour plus de détails, consultez la documentation Microsoft : Configurer le pare-feu Windows pour autoriser l’accès à SQL Server. |
| MySQL | TCP : 3300-3306, 33060 TCP : 33062 (pour les connexions spécifiques aux admins) | Pour les cas d'utilisation générale de la connexion MySQL, seul le port 3306 est nécessaire, mais certains clients peuvent tirer parti des ports supplémentaires de MySQL. Netskope recommande d'utiliser une plage de ports pour les applications privées de base de données MySQL. MySQL bloque les connexions de l'éditeur NPA car il détecte le test d'accessibilité comme une attaque potentielle. L'utilisation d'une plage dans la configuration du port aura pour conséquence que le NPA Publisher n'effectuera une vérification de l'accessibilité que sur le premier port de la plage et empêchera donc MySQL de voir ce trafic et d'éviter le blocage du port. |
Pour plus de détails, veuillez contacter votre Technical Success Manager ou votre ingénieur commercial Netskope pour obtenir de l'aide.
Le NPA peut-il tunneliser des protocoles et des ports autres que les protocoles courants énumérés ci-dessus ?
Oui. Le NPA peut tunneliser des applications en dehors de cette liste. NPA prend en charge les protocoles TCP et UDP ainsi que tous les ports associés, à une exception notable près : Netskope ne tunnelise pas actuellement la plupart du trafic DNS, mais nous prenons en charge le tunnelage des consultations DNS SRV sur le port 53. Elle est nécessaire pour la découverte des services, qui est utilisée dans divers scénarios Windows AD impliquant LDAP, Kerberos, etc.
Note
Parfois, des applications telles que la VoIP peuvent poser problème. Ce n'est pas tant le tunnel qui est en cause, mais plutôt la configuration. Par exemple, les applications qui effectuent une allocation dynamique des ports lors de l'établissement d'une connexion peuvent être problématiques, car un administrateur ne peut pas savoir à l'avance quels ports seront configurés par la partie service de l'application, et il n'y a donc aucun moyen de savoir quels ports spécifier.
Quels sont les protocoles et les ports que NPA peut utiliser pour les applications privées ?
NPA peut prendre en charge n'importe quel trafic TCP et UDP de client à serveur.
Le site NPA peut-il faire office de tunnel ICMP ?
Non. NPA ne tunnelise pas ICMP, mais seulement TCP et UDP. Vous ne pouvez donc pas faire de ping ou de traceroute sur le NPA pour tester les connexions réseau. Pour vérifier rapidement si le pilotage NPA fonctionne pour une application privée définie par le FQDN, entrez dans une fenêtre de commande/Terminal : nslookup<FQDN_of_Private_App>. Vous pouvez utiliser tcping, psping ou d'autres outils basés sur tcp pour tester la connectivité.
Le NPA supporte-t-il le tunneling des connexions établies à partir d'une application privée vers un Client ?
Non. Le NPA ne prend pas en charge les protocoles qui établissent des connexions entre une application privée et un client. Par exemple, le mode FTP actif n'est pas pris en charge.
Qu'est-ce que la SRP et comment NPA exploite-t-elle la SRP pour diriger le trafic ?
L'ASR est un document décrivant la liste des applications disponibles pour un utilisateur. Lorsqu'un tunnel NPA est établi pour un utilisateur donné, le plan de gestion NPA effectue le calcul du protocole de routage de service (SRP). En outre, la SRP peut être révisée dynamiquement en fonction des changements apportés à la politique NPA, à la direction, à l'application, à la posture du périphérique ou à l'appartenance à un groupe.
Sur la base du SRP, la NPA filtre et achemine le trafic de l'application privée vers le plan de données de la NPA et, s'il est autorisé, le transmet à l'application privée par l'intermédiaire de l'infrastructure de la NPA. S'il n'est pas autorisé, le plan de données NPA bloque le trafic.
Important
À partir de la version v118, le backend Netskope Private Access interrompt le trafic si le SRP résultant est supérieur à 40MB.
Il s'agit d'un mécanisme de protection permettant d'éviter que les erreurs de configuration d'un locataire ne nuisent à l'ensemble de la solution.
Toute politique d'application privée importante, telle que l'énumération d'un grand nombre de ports un par un, doit être désactivée afin de réduire la taille et de débloquer l'accès à ces utilisateurs.
Si ces configurations ne peuvent pas être optimisées, veuillez contacter le service d'assistance de Netskope pour obtenir une aide supplémentaire.
Combien de temps faut-il pour qu'un client reçoive les changements de politique de New (par exemple, lorsqu'une application privée New lui est attribuée et que les changements se propagent au client) ?
Actuellement, chaque client se connecte au plan de gestion toutes les 15 minutes pour vérifier si des changements de politique doivent être téléchargés et si le SRP doit être recalculé. Ainsi, il ne faut pas plus de 15 minutes pour que les changements de politique de New se propagent à tous les clients. En réalité, ce délai peut aller de quelques secondes à 15 minutes, en fonction de la position de la minuterie sur le client en question.
En option, vous pouvez vérifier la dernière mise à jour de la politique NPA en recherchant au bas du fichier npadebuglog.log la chaîne SRP live status is 1, et en vérifiant le dernier horodatage de l'entrée du journal. Il se peut que vous voyiez des dizaines d'entrées de journal ; assurez-vous de rechercher celle qui se trouve à l'adresse New.
Comment le site Netskope Client vérifie-t-il les mises à jour de la configuration ?
Le Client vérifie automatiquement les mises à jour définies par l'administrateur ou l'utilisateur final.
Le client envoie-t-il des modifications d'état pour l'authentification mise à jour ?
Oui. Le client fournit des mises à jour périodiques et dynamiques, telles que la classification du périphérique, le statut d'authentification et l'utilisateur au contrôleur pour les informations d'autorisation.
Quelle est la bonne méthode pour résoudre les problèmes d'accessibilité d'une application ou d'un service privé derrière un éditeur ?
- Pour le client, sélectionnez un utilisateur, puis cliquez Troubleshoot.
- Pour l’accès au navigateur, saisissez un nom d’hôte personnalisé, sélectionnez un utilisateur, puis cliquez TroubleShoot.
Le Troubleshooter affiche la liste des contrôles exécutés, les problèmes qui peuvent affecter votre configuration et les solutions à ces problèmes.
Le dépanneur a une douzaine de contrôles à son actif. Cependant, il existe de nombreuses conditions supplémentaires susceptibles d'affecter l'accès (que Troubleshooter ne vérifie pas). Il est donc utile de pouvoir effectuer certains contrôles manuellement.