Hvad er Netskope Private Access?

Systemkravene til Netskope Private Access varierer i de forskellige implementeringsmiljøer. Du kan finde flere oplysninger i: Systemkrav til en Netskope Private Access-udgiver.

Hvis du vil oprette forbindelse til brugere med programmer og tjenester, skal en Netskope Private Access-administrator konfigurere private app-politikker et par steder i Netskope-brugergrænsefladen. Her er konfigurationsmulighederne og oplysninger om kendte typer af programmer og tjenester.

Program	Protokol og port	Faktorer
Webtrafik	TCP: 80, 443 (brugerdefinerede porte: 8080 osv.) UDP: 80, 443	Google Chrome bruger QUIC-protokollen (HTTP/S over UDP) til visse webprogrammer. Kopiering af webbrowserportene til både TCP og UDP kan forbedre ydeevnen.
SSH	TCP: 22
Fjernskrivebord (RDP)	TCP: 3389 UDP: 3389	Nogle RDP-klientapps (Windows Remote Desktop Protocol) (f.eks. nyere Windows 10-versioner) foretrækker at bruge UDP:3389 til at oprette forbindelse til fjernskrivebord.
Windows SQL Server	TCP: 1433, 1434 UDP: 1434	Standardporten til Windows SQL Server er 1433, men dette kan tilpasses i dine miljøer. Du kan finde flere oplysninger under Konfigurer Windows Firewall til Allow SQL Server Access (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 (for administratorspecifikke forbindelser)	Til generelle brugstilfælde af MySQL-forbindelse kræves der kun port 3306, men nogle brugere kan drage fordel af de ekstra MySQL-funktionsporte. Netskope anbefaler at bruge et portinterval til MySQL-databasens private apps. MySQL blokerer forbindelser fra Netskope Private Access-udgiveren, fordi det registrerer en adgangstest som et potentielt angreb. Brug af et interval i portkonfigurationen medfører, at Netskope Private Access-udgiveren kun udfører et tilgængelighedscheck på den første port i serien. Dette forhindrer MySQL i at se denne trafik og undgå portblokeringen. Du finder flere oplysninger i MySQL Port Reference Tables (https://dev.mysql.com/doc/mysql-port-reference/en/mysql-ports-reference-tables.html).

Ja. Netskope Private Access kan arbejde sig igennem apps uden for listen. Netskope private Access understøtter både TCP- og UDP-protokoller og alle tilknyttede porte med én vigtig undtagelse: Netskope gennemarbejder ikke det meste DNS-trafik, men vi understøtter gennemarbejdning af DNS-tjenesteopslag (SRV) via port 53. Dette er nødvendigt for at udføre tjenesteregistrering, som bruges i forskellige Windows Active Directory-scenarier, der involverer LDAP, Kerberos og meget mere.

Forespørgselsintervallet er ca. ét minut.

Netskope Private Access-udgiveren forsøger at oprette forbindelse til en konfigureret port på en privat app for at kontrollere, om den private app kan nås.

Vigtige faktorer, der skal overvejes:

• Udgiveren fungerer bedst, når du definerer private apps ud fra værtsnavn (f.eks. jira.globex.io) og port (f.eks. 8080).
• Når en app er angivet med flere porte eller et portinterval, bruger udgiveren den første port på listen eller i området til at kontrollere tilgængeligheden.
• Udgiveren kan ikke kontrollere tilgængeligheden for private apps, der er defineret med et jokertegn (*.globex.io) eller CIDR-blok (10.0.1.0/24). Det kontrollerer heller ikke tilgængelighed af apps med portintervaller defineret (3305-3306).

Hvis registreringen mislykkes (f.eks. fordi der mangler et ciffer under indtastning af registreringskoden), kan du bruge SSH på udgiveren og angive et nyt registreringstoken.

Hvis registreringen lykkedes, men du har besluttet at registrere udgiveren med et andet token, er dette ikke understøttet og kan ikke anbefales. I dette scenarie skal du geninstallere udgiveren.

Nej. Netskope Private Access gennemarbejder ikke ICMP, kun TCP og UDP. Du kan ikke køre ping eller traceroute via Netskope Private Access for at teste netværksforbindelser.

Nej. Netskope Private Access understøtter ikke protokoller, der etablerer forbindelser fra en privat app til en klient. F.eks. understøttes aktiv tilstand for FTP ikke.

Nej. Udgiveren udfører SSL-fastgørelse til registreringsprocessen og certifikatautentificering på serversiden i henhold til et bestemt certifikat.

Hvis der er en proxy, der afslutter TLS-forbindelsen, skal destinationen på tilladt-listen/omgås (*.newedge.io).

Den private appvært viser forbindelsen som udgående fra IP-adressen på den udgiver, der opretter forbindelse til den. Der er ingen afgrænsning. Afhængigt af antallet af udgivere, der bruges til at oprette forbindelse til den private appvært, skal du tillade hver af disse IP-adresser.

Hvis den implementeres i Amazon Web Services, skal du tildele Amazon Machine Image (AMI), KeyPair.pem som du allerede har (eller genererer en ny KeyPair.pem) under klargøring af udgiveren.

Fra en SSH-klient skal du skrive ssh -i [KEYPAIR.PEM] centos@[PUBLISHER] og derefter trykke på Enter.

Når du har oprettet forbindelse via SSH til udgiveren, placeres du i en interaktiv kommandolinjegrænseflademenu (CLI). Du kan vælge valgmulighed 3 for at blive placeret i en normal UNIX CLI for yderligere fejlfinding. Du kan finde flere oplysninger i Hvad er en god metode til fejlfinding af adgangsproblemer for en privat app/tjeneste bag en udgiver?

1. Højreklik på startmenuen i Windows, og klik herefter på Kør.

2. I brugergrænsefladen Kør skal du skrive cmd og derefter trykke på OK.

3. I kommandoprompten skal du skrive ssh centos@[publisher] og derefter trykke på Enter.

Udgivere arbejder i aktiv/passiv tilstand. Al trafik går til den første udgiver, hvis den er operationel (tilsluttet). Hvis den går ned, skiftes der til en sekundær udgiver.

Den første og bedste mulighed er at bruge fejlfindingsfunktionen. Klik på Fejlfinding på siden Private Apps.

Vælg den private app og enhed, som du forsøger at få adgang til, og klik derefter på Fejlfinding.

Fejlfindingen viser listen over udførte kontroller, problemer, som kan påvirke din konfiguration, og løsninger.