¿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	Protocolo y puerto	Factor
Tráfico web	TCP: 80, 443 (puertos personalizados: 8080, así sucesivamente) UDP: 80, 443	Google Chrome utiliza el protocolo QUIC (HTTP/S en UDP) para algunas aplicaciones web. La duplicación de los puertos de navegación web para TCP y UDP puede proporcionar una mejora del rendimiento.
SSH	TCP: 22
Escritorio remoto (RDP)	TCP: UDP 3389 : 3389	Algunas aplicaciones del cliente del protocolo de escritorio remoto (RDP) de Windows (como versiones más recientes de Windows 10) prefieren la configuración UDP: 3389 para realizar 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, consulte Configurar el firewall de Windows para permitir el acceso de 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 (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 usuarios 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 bloquea 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 da lugar a que el editor de Netskope Private Access realice una comprobación de disponibilidad únicamente en el primer puerto del rango. Esto impide que MySQL vea este tráfico y evite el bloqueo de puertos. Para obtener más información, consulte Tablas de referencia de puertos (https://dev.mysql.com/doc/mysql-port-reference/en/mysql-ports-reference-tables.html) de MySQL.

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, con una excepción notable: Netskope no realiza tunelización de la mayor parte del tráfico DNS, pero se soportan las búsquedas de servicio de tunelización de 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.

El intervalo de sondeo es de aproximadamente un minuto.

El editor de Netskope Private Access intenta 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 falla (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. En este caso, reinstale 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 reconoce 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 el número de editores que se utilizan para conectarse al host de la aplicación privada, agregue cada una de esas direcciones IP a la lista blanca.

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

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

Después de utilizar correctamente SSH para conectarse al publicador, queda en un menú interactivo de la interfaz de la línea de comandos (CLI). 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 Ejecutar, escriba cmd y luego haga clic en Aceptar

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

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 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 Troubleshooter genera la lista de las comprobaciones ejecutadas, los problemas que es posible que afecten su configuración y las soluciones.