Vad är Netskope Private Access?

Systemkraven för Netskope Private Access skiljer sig åt mellan olika distributionsmiljöer. Mer information finns i: Systemkrav för en Netskope Private Access-utgivare.

För att kunna ansluta användare till program och tjänster måste en Netskope Private Access-administratör konfigurera policyer för privata program i Netskope-gränssnittet på några platser. Här är konfigurationsalternativen och information om några kända program/tjänster.

Indicator	Protokoll och port	Faktorer
Webbtrafik	TCP: 80, 443 (anpassade portar: 8080, så vidare) UDP: 80, 443	Google Chrome använder QUIC-protokollet (HTTP/S över UDP) för vissa webbappar. Om du duplicerar webbsurfportarna för både TCP och UDP kan du få bättre prestanda.
SSH	TCP: 22
Fjärrskrivbord (RDP)	TCP: 3389 UDP: 3389	Vissa klientprogram för Windows Remote Desktop Protocol (RDP) (t.ex. nyare Windows 10-versioner) föredrar att använda UDP:3389 för att utföra fjärrskrivbordsanslutning.
Windows SQL Server	TCP: 1433 och 1434 UDP: 1434	Standardporten för Windows SQL Server är 1433, men det kan anpassas i dina miljöer. Mer information finns i Konfigurera Windows-brandväggen så att SQL Server-åtkomst (https://docs.microsoft.com/sql/sql-server/install/configure-the-windows-firewall-to-allow-sql-server-access?view=sql-server-2017)tillåts.
MySQL	TCP: 3300-3306, 33060 TCP: 33062 (för administratörsspecifika anslutningar)	För allmän MySQL-anslutning behövs bara port 3306, men vissa kunder kan ha användning för de ytterligare MySQL-funktionsportarna. Netskope rekommenderar att du använder ett portintervall för privata MySQL-databasappar. MySQL blockerar anslutningar från Netskope Private Access-utgivaren eftersom det detekterar nåbarhetstestet som en potentiell attack. Om du använder ett intervall i portkonfigurationen så kan Netskope Private Access-utgivaren bara utföra nåbarhetstest på den första porten i intervallet. Då ser inte MySQL den här trafiken och du undviker portblockeringen. Mer information finns i MySQL-portreferenstabeller (https://dev.mysql.com/doc/mysql-port-reference/en/mysql-ports-reference-tables.html).

Ja. Netskope Private Access kan tunnelansluta andra program än de i listan. Netskope Private Access har stöd för både TCP- och UDP-protokoll och alla associerade portar, med ett viktigt undantag: Netskope tunnlar inte merparten av all DNS-trafik, men vi har dock stöd för att tunnla DNS-tjänstsökningar (SRV) över port 53. Detta krävs för tjänstidentifiering, vilket används i olika Windows Active Directory-scenarier som omfattar LDAP, Kerberos m.m.

Kontrollintervallet är cirka en minut.

Netskope Private Access-utgivaren försöker ansluta till en konfigurerad port i en privat app för att kontrollera om den privata appen kan nås.

Viktiga faktorer att ha i åtanke:

• Utgivaren fungerar bäst när du definierar privata appar med värdnamn (till exempel jira.globex.io) och port (till exempel 8080).
• När du anger en app med flera portar eller ett portintervall använder bara utgivaren den första porten i listan eller intervallet för att kontrollera tillgängligheten.
• Utgivaren kan inte kontrollera nåbarheten för privata program som definieras med ett jokertecken (*.globex.io) eller CIDR-block (10.0.1.0/24). Den kontrollerar inte heller nåbarheten för program med definierade portintervall (3305–3306).

Om det inte gick att genomföra registreringen (till exempel på grund av att en siffra missades när registreringskoden angavs) kan du SSH-ansluta till utgivaren och ange en ny registreringstoken.

Om registreringen genomfördes men du valde att registrera utgivaren med en annan token är det något som inte stöds och inte rekommenderas. I det här scenariot installerar du om utgivaren.

Nej. Netskope Private Access tunnelansluter inte ICMP, endast TCP och UDP. Du kan inte köra ping eller traceroute via Netskope Private Access för att testa nätverksanslutningar.

Nej. Netskope Private Access har inte stöd för protokoll som upprättar anslutningar från ett privat program till en klient. FTP Active-läge stöds till exempel inte.

Nej. Utgivaren gör en SSL-associering för registreringsprocessen och certifikatautentisering på serversidan mot ett specifikt certifikat.

Om det finns en proxy som avbryter TLS-anslutningen måste destinationen vitlistas eller kringgås (*.newedge.io).

Värden för den privata appen uppfattar det som att anslutningen kommer från IP-adressen för den utgivare som ansluter till den. Det finns inget intervall. Beroende på hur många utgivare som används för att ansluta till värden för det privata programmet tillåter du att var och en av dessa IP-adresser listas.

Om den distribueras till Amazon Web Services tilldelar du Amazon Machine Image (AMI) en KeyPair.pem som du redan har (eller genererar en ny KeyPair.pem) under provisioneringen av utgivaren.

Skriv in och tryck sedan på Retur från en SSH-klient ssh -i [KEYPAIR.PEM] centos@[PUBLISHER] .

När du har anslutit till utgivaren via SSH hamnar du i en CLI-meny (interaktivt kommandoradsgränssnitt). Du kan välja alternativ 3 för att placeras i en vanlig UNIX-CLI-meny för vidare felsökning. Mer information finns i Vad är en bra metod för att felsöka problem med åtkomst till ett privat program/en privat tjänst bakom en utgivare?

1. Högerklicka på Windows-startmenyn och klicka sedan på Kör.

2. Skriv cmd och tryck sedan på OK i körgränssnittet.

3. Skriv ssh centos@[publisher] och tryck sedan på Retur i kommandotolken.

Utgivare jobbar i aktiv/passiv-läge. All trafik går till en första utgivare om den är i drift (ansluten). Om den stängs ner växlar vi till en sekundär utgivare.

Det första bästa alternativet är att använda felsökaren. Klicka på Felsökaren på sidan Private Apps.

Välj det privata program och den enhet som du försöker komma åt och klicka sedan på Felsök.

Felsökaren skapar en lista med utförda kontroller, problem som kan påverka konfigurationen och lösningar.