¿Qué es Netskope Private Access?

Los requisitos del sistema de Netskope Private Access difieren entre los entornos de implementación. Para obtener más información, consulte Requisitos del sistema para el uso de un editor de Netskope Private Access.

Para conectar usuarios con aplicaciones o servicios, un administrador de Netskope Private Access debe configurar políticas de aplicaciones privadas en la interfaz del usuario de Netskope en algunas ubicaciones. A continuación, se presentan las opciones de configuración y los detalles de los tipos de aplicaciones o servicios conocidos.

Aplicación	Protocol/Port	Factor
Tráfico web	TCP: 80, 443 (puertos personalizados: 8080, etc.) UDP: 80, 443	Google Chrome utilizará el protocolo QUIC (HTTP/S en UDP) para algunas aplicaciones web, de modo que la duplicación de los puertos de navegación web para TCP y UDP pueda mejorar el rendimiento.
Secure Shell (SSH)	TCP: 22
Escritorio remoto (RDP)	TCP: 3389 UDP: 3389	Algunas aplicaciones del cliente del protocolo de escritorio remoto (RDP) de Windows (como versiones más recientes de Windows 10) ahora prefieren la configuración UDP: 3389 para mantener la conectividad del escritorio remoto.
Windows SQL Server	TCP: 1433, 1434 UDP: 1434	El puerto predeterminado para Windows SQL Server es 1433, aunque esto se puede personalizar en sus entornos. Para obtener más información, consulteConfigurar el firewall de Windows para permitir el acceso de SQL Server (https://docs.microsoft.com/en-us/sql/sql-server/install/configure-the-windows-firewall-to-allow-sql-server-access?view=sql-server-2017).
MySQL	TCP: 3300-3306, 33060 TCP: 33062 (para conexiones específicas de administrador)	Para los casos de uso de conexión general de MySQL, solo se requiere el puerto 3306, pero algunos clientes pueden aprovechar los puertos incluidos en MySQL adicionales. Netskope recomienda utilizar un rango de puertos para las aplicaciones privadas de base de datos de MySQL. MySQL bloqueará las conexiones provenientes del editor de Netskope Private Access, ya que identifica la prueba de disponibilidad como un posible ataque. El uso de un rango en la configuración de puertos ocasionará que el editor de Netskope Private Access realice una comprobación de disponibilidad únicamente en el primer puerto del rango, lo que impedirá que MySQL vea este tráfico y así se evitará el bloqueo de puertos. Consulte la documentación de MySQL para obtener más información:Tablas de referencia de puertos de MySQL (https://dev.mysql.com/doc/mysql-port-reference/en/mysql-ports-reference-tables.html).

Nota: Los puertos predeterminados pueden diferir de los puertos de su entorno.

Sí. Netskope Private Access puede tunelizar otras aplicaciones aparte de las que se mencionan en esa lista. Netskope Private Access es compatible con los protocolos TCP y UDP y todos los puertos asociados. Sin embargo, hay una excepción importante: actualmente, Netskope no tuneliza la mayor parte del tráfico DNS, sino que tuneliza las búsquedas de servicio DNS (SRV) en el puerto 53. Esto es necesario para la detección de servicios, que se utiliza en varios casos de Windows Active Directory relacionados con LDAP, Kerberos y mucho más.

Nota: En ocasiones, las aplicaciones como VoIP pueden causan problemas. No tanto por el túnel, sino por la configuración. Por ejemplo, las aplicaciones que ejecutan la asignación dinámica de puertos cuando se establece una conexión pueden causar problemas, ya que el administrador no puede saber cuáles son los puertos que se configurarán por parte del servicio de la aplicación con anticipación, por lo que no hay manera de saber qué puertos se deben especificar.

El intervalo de sondeo es de aproximadamente un minuto.

El editor de Netskope Private Access intentará conectarse a un puerto configurado en una aplicación privada para comprobar si se puede acceder a la aplicación privada.

Se deben considerar los siguientes factores importantes:

• El editor funciona mejor cuando define aplicaciones privadas por nombre de host (por ejemplo, jira.globex.io) y puerto (por ejemplo, 8080).
• Cuando se especifica una aplicación con varios puertos o un rango de puertos, el editor utiliza solo el primer puerto de la lista o el rango para comprobar la disponibilidad.
• El editor no puede comprobar la disponibilidad de las aplicaciones privadas que se definen con un comodín (*.globex.io) o un bloque CIDR (10.0.1.0/24). Tampoco comprueba la disponibilidad de las aplicaciones con rangos de puertos definidos (3305-3306).

Si el registro falló (por ejemplo, debido a que faltó un dígito cuando ingresó el código de registro), puede aplicar el protocolo SSH en el editor y proporcionar un nuevo token de registro.

Si el registro se realizó correctamente, pero decidió registrar el editor con otro token, esta operación no se admite y no se recomienda. Tendrá que volver a instalar el editor.

No, Netskope Private Access no tuneliza el ICMP, sino que solo el TCP y UDP. No puede ejecutar ping ni traceroute en Netskope Private Access para probar las conexiones de red.

No, Netskope Private Access no es compatible con los protocolos que establecen conexiones de una aplicación privada a un cliente. Por ejemplo, no se admite el modo FTP activo.

No, el editor realiza la asignación de SSL para el proceso de registro y la autenticación de certificados en el servidor respecto a un certificado específico.

En este caso, si hay algún proxy que finalice la conexión TLS, el destino se debe agregar a lista blanca u omitir (*.newedge.io).

El host de la aplicación privada reconocerá la conexión como si se originara de la dirección IP del editor que se conecta a él. No hay un rango. Según la cantidad de editores que se utilizan para conectarse al host de la aplicación privada, deberá agregar cada una de esas direcciones IP a la lista blanca.

Si se implementa en Amazon Web Services, le asignará a la imagen de máquina de Amazon (AMI) un KeyPair.pem que ya tenga (o genere uno nuevo) durante el aprovisionamiento del editor.

En cliente SSH, escriba ssh -i [KEYPAIR.PEM] centos@[publisher] y, a continuación, presione Intro.

Nota:

• [KEYPAIR.PEM] = ruta del archivo KeyPair.pem.
• [publisher] = dirección IP externa del editor.
• El nombre de usuario predeterminado del editor es:
  • centos
• El nombre de usuario predeterminado de la AMI de Amazon Services es:
  • ec2-user

Una vez que se haya conectado correctamente mediante SSH al editor, se abrirá un menú de interfaz de línea de comandos (CLI) interactivo. Puede elegir la opción 3 para que se abra una CLI normal de UNIX a fin de realizar pasos adicionales de solución de problemas. Para obtener más información, consulte ¿Qué método es eficaz para solucionar problemas de accesibilidad en una aplicación o un servicio privado en un editor?

1. Haga clic con el botón secundario en el menú Inicio de Windows y haga clic en Ejecutar.

2. En la interfaz de usuario Run (Ejecutar), escriba cmd y luego haga clic en OK (Aceptar).

3. En el símbolo del sistema, escriba ssh centos@[publisher] y, a continuación, presione Intro.

Nota:

• [publisher] = dirección IP externa del editor.
• Las credenciales predeterminadas del editor son:
  • Nombre de usuario: centos
  • Contraseña: centos
• La contraseña se debe cambiar después del primer inicio de sesión.

Los editores funcionan en modo activo-pasivo. Todo el tráfico pasa a un editor principal si está operativo (conectado). Si deja de funcionar, cambiamos a un editor secundario.

La primera opción recomendada es utilizar el solucionador de problemas. Haga clic en Troubleshooter ubicado en la página Private Apps.

Seleccione la aplicación privada y el dispositivo a los que intenta acceder y, a continuación, haga clic en Troubleshoot.

El solucionador de problemas genera la lista de las comprobaciones ejecutadas, los problemas que es posible que afecten su configuración y las soluciones.