Was ist Netskope Private Access?

Die Systemanforderungen für Netskope Private Access unterscheiden sich je nach Bereitstellungsumgebung. Weitere Informationen finden Sie unter: Systemanforderungen für einen Netskope Private Access Publisher.

Um Nutzer mit Anwendungen und Services zu verbinden, muss ein Netskope Private Access-Administrator an einigen Stellen Policys für private Apps in der Netskope-Benutzeroberfläche konfigurieren. Hier finden Sie die Konfigurationsoptionen und Details für bekannte Anwendungs- und Servicetypen.

Anwendung	Protokoll und Port	Faktoren
Webdatenverkehr	TCP: 80, 443 (angepasste Ports: 8080 usw.) UDP: 80, 443	Google Chrome verwendet das QUIC-Protokoll (HTTP/S über UDP) für einige Webanwendungen. Die Duplizierung von Webbrowsing-Ports für TCP und UDP kann eine Performanceverbesserung bieten.
SSH	TCP: 22
Remote Desktop (RDP)	TCP: 3389 UDP: 3389	Einige RDP-Client-Apps (Windows Remote Desktop Protocol) (z. B. neuere Windows 10-Versionen) bevorzugen die Verwendung von UDP:3389, um die Remotedesktop-Konnektivität herzustellen.
Windows SQL Server	TCP: 1433, 1434 UDP: 1434	Der Standardport für Windows SQL Server ist 1433, kann jedoch in Ihren Umgebungen angepasst werden. Weitere Informationen finden Sie unter Konfigurieren der Windows-Firewall zum Zulassen von SQL Server-Zugriff (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 (für adminspezifische Verbindungen)	Für allgemeine Anwendungsfälle mit MySQL-Verbindungen ist nur Port 3306 erforderlich. Einige Kunden können jedoch die zusätzlichen MySQL-Funktionsports nutzen. Netskope empfiehlt die Verwendung eines Portbereichs für private Apps der MySQL-Datenbank. MySQL sperrt Verbindungen vom Netskope Private Access Publisher, da der Erreichbarkeitstest als potenzieller Angriff erkannt wird. Die Verwendung eines Bereichs in der Port-Konfiguration führt dazu, dass der Netskope Private-Access-Herausgeber nur auf dem ersten Port im Bereich eine Erreichbarkeitsprüfung ausführt. Dies verhindert, dass MySQL diesen Datenverkehr sehen und den Port Block vermeiden. Weitere Informationen finden Sie unter MySQL Port Reference Tables (https://dev.mysql.com/doc/mysql-port-reference/en/mysql-ports-reference-tables.html).

Ja. Netskope Private Access kann Apps außerhalb dieser Liste als Tunnel verwenden. Netskope Private Access unterstützt sowohl das TCP- als auch das UDP-Protokoll und alle zugehörigen Ports, mit einer bemerkenswerten Ausnahme: Netskope tunnelt den meisten DNS-Datenverkehr nicht, aber wir unterstützen Tunneling DNS Service (SRV)-Lookups über Port 53. Dies wird für die Diensterkennung benötigt, die in verschiedenen Windows Active Directory-Szenarien mit LDAP, Kerberos und weiteren verwendet wird.

Das Abfrageintervall beträgt ca. eine Minute.

Der Netskope Private Access Publisher versucht, eine Verbindung zu einem konfigurierten Port einer privaten App herzustellen, um zu überprüfen, ob die private App erreichbar ist.

Wichtige zu berücksichtigende Faktoren:

• Der Publisher funktioniert am besten, wenn Sie private Apps nach Hostname (z. B. jira.globex.io) und Port (z. B. 8080) definieren.
• Wenn eine App mit mehreren Ports oder einem Portbereich angegeben wird, verwendet der Publisher nur den ersten Port aus der Liste oder dem Bereich, um die Verfügbarkeit zu überprüfen.
• Der Publisher kann die Erreichbarkeit für private Apps, die mit einem Platzhalter (*.globex.io) oder einem CIDR-Block (10.0.1.0/24) definiert sind, nicht überprüfen. Die Erreichbarkeit von Apps mit definierten Portbereichen (3305–3306) wird ebenfalls nicht überprüft.

Wenn die Registrierung fehlgeschlagen ist (z. B. weil bei der Eingabe des Registrierungscodes eine Ziffer übersehen wurde), können Sie sich über SSH mit dem Publisher verbinden und ein neues Registrierungstoken bereitstellen.

Wenn die Registrierung erfolgreich war, Sie sich jedoch entschieden haben, den Publisher mit einem anderen Token zu registrieren, wird dies nicht unterstützt und nicht empfohlen. Installieren Sie in diesem Szenario den Publisher neu.

Nein. Netskope Private Access bietet keinen Tunnel für ICMP, nur TCP und UDP. Sie können weder „ping“ noch „traceroute“ über Netskope Private Access ausführen, um Netzwerkverbindungen zu testen.

Nein. Netskope Private Access unterstützt keine Protokolle, die Verbindungen von einer privaten App zu einem Client herstellen. Beispielsweise wird der aktive FTP-Modus nicht unterstützt.

Nein. Der Publisher führt SSL-Pinning für den Registrierungsprozess und die serverseitige Zertifikatauthentifizierung für ein bestimmtes Zertifikat durch.

Wenn in diesem Fall ein Proxy vorhanden ist, der die TLS-Verbindung beendet, muss das Ziel auf die Whitelist gesetzt/umgangen werden (*.newedge.io).

Der private App-Host sieht die Verbindung als von der IP-Adresse des Publishers stammend an, der eine Verbindung zu ihm herstellt. Es gibt keinen Bereich. Je nach Anzahl der Publisher, die für die Verbindung mit dem privaten Anwendungshost verwendet werden, müssen Sie die einzelnen IP-Adressen in die Allowlist eintragen.

Bei der Bereitstellung in Amazon Web Services weisen Sie dem Amazon Machine Image (AMI) eine KeyPair.pem zu, die Sie während der Bereitstellung des Publishers bereits haben (oder generieren eine neue KeyPair.pem).

Geben Sie von einem SSH-Client ssh -i [KEYPAIR.PEM] centos@[PUBLISHER] ein und drücken Sie die Eingabetaste.

Nachdem Sie die SSH für die Verbindung mit dem Publisher erfolgreich verwendet haben, werden Sie an ein interaktives Menü der Befehlszeilenoberfläche (CLI) verwiesen. Sie können Option 3 auswählen, die zur zusätzlichen Fehlerbehebung in eine normale UNIX-CLI eingefügt werden soll. Weitere Informationen finden Sie unter Was ist eine gute Methode zur Behebung von Problemen mit dem Zugriff auf eine private App/einen privaten Dienst hinter einem Publisher?.

1. Klicken Sie mit der rechten Maustaste auf das Startmenü von Windows und klicken Sie auf Ausführen.

2. Geben Sie in das Dialogfeld „Ausführen“ cmd ein und klicken Sie auf OK.

3. Geben Sie in die Eingabeaufforderung ssh centos@[publisher] ein und drücken Sie anschließend die Eingabetaste.

Publisher arbeiten im Aktiv-Passiv-Modus. Der gesamte Datenverkehr geht an den ersten Publisher, wenn dieser betriebsbereit (verbunden) ist. Wenn er ausfällt, wird zu einem sekundären Publisher gewechselt.

Die beste Option ist die Verwendung des Troubleshooters. Klicken Sie auf der Private Apps Seite auf Troubleshooter.

Wählen Sie die private App und das Gerät aus, auf die Sie zugreifen möchten, und klicken Sie dann auf Troubleshoot.

Der Troubleshooter stellt die Liste der ausgeführten Prüfungen, Probleme, die sich möglicherweise auf die Konfiguration auswirken, und Lösungen dar.