Hva er Netskope Private Access?

Systemkravene for Netskope Private Access varierer mellom ulike implementeringsmiljøer. Hvis du vil ha mer informasjon, kan du se: Systemkrav for en Netskope Private Access-utgiver.

Når en Netskope Private Access-administrator skal koble brukere til applikasjoner og tjenester, må han/hun konfigurere retningslinjer for private apper på et par steder i Netskope-brukergrensesnittet. Her er konfigurasjonsalternativer og -informasjon for kjente typer applikasjoner og tjenester.

Applikasjon	Protokoll og port	Faktorer
Nettrafikk	TCP: 80, 443 (egendefinerte porter: 8080, så videre) UDP: 80, 443	Google Chrome bruker QUIC-protokollen (HTTP/S over UDP) for enkelte nettapplikasjoner. Duplisering av nettleserportene for både TCP og UDP kan gi bedre ytelse.
SSH	TCP: 22
Eksternt skrivebord (RDP)	TCP: 3389 UDP: 3389	Enkelte RDP-klientapper (Remote Desktop Protocol) for Windows (for eksempel nyere Windows 10-versjoner) foretrekker å bruke UDP:3389 til å utføre tilkobling til eksternt skrivebord.
Windows SQL Server	TCP: 1433, 1434 UDP: 1434	Standardporten for Windows SQL Server er 1433, men dette kan tilpasses i miljøet ditt. Hvis du vil ha mer informasjon, kan du se Konfigurere Windows-brannmuren for å tillate SQL Server-tilgang (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 administratorspesifikke tilkoblinger)	For generelle brukstilfeller med MySQL-tilkobling trengs bare én 3306-port, men noen brukere kan dra nytte av de ekstra MySQL-funksjonsportene. Netskope anbefaler å bruke et portintervall for private apper for MySQL-databasen. MySQL blokkerer tilkoblinger fra Netskope Private Access-utgiveren fordi det registrerer tilgjengelighetstesten som et potensielt angrep. Hvis du bruker et område i portkonfigurasjonen, vil det føre til at Netskope Private Access-utgiveren bare utfører en tilgjengelighetstest på den første porten i området. Dette hindrer MySQL i å se denne trafikken og unngå portblokkeringen. Hvis du vil ha mer informasjon, kan du se Referansetabeller for MySQL-port (https://dev.mysql.com/doc/mysql-port-reference/en/mysql-ports-reference-tables.html).)

Ja. Netskope Private Access kan utføre tunnelering av apper som ikke står på listen. Netskope Private Access støtter både TCP- og UDP-protokollene og alle tilhørende porter, med ett unntak: Netskope utfører for øyeblikket ikke tunnelering av det meste av DNS-trafikk, men vi støtter tunnelering av DNS-tjenesteoppslag (SRV) over port 53. Dette er nødvendig for tjenestesøk som benyttes i en rekke Windows Active Directory-scenarier med blant andre LDAP og Kerberos.

Avspørringsintervallet er på ca. ett minutt.

Netskope Private Access-utgiveren prøver å koble til en konfigurert port på en privat app for å sjekke om den private appen er tilgjengelig.

Viktige faktorer som må vurderes:

• Utgiveren fungerer best når du definerer private apper med vertsnavn (for eksempel jira.globex.io) og port (for eksempel 8080).
• Når en app er spesifisert med flere porter eller et portintervall, bruker utgiveren den første porten fra listen eller området for å kontrollere tilgjengeligheten.
• Utgiveren kan ikke sjekke tilgjengeligheten for private apper som er definert med et jokertegn (*.globex.io) eller en CIDR-blokk (10.0.1.0/24). Den kan heller ikke sjekke tilgjengeligheten til apper med definerte portintervaller (3305–3306).

Hvis registreringen mislyktes (for eksempel fordi et tall ble hoppet over når registreringskoden ble angitt), kan du implementere SSH i utgiveren og oppgi et nytt registreringstoken.

Hvis registreringen var vellykket, men du bestemte deg for å registrere utgiveren med et annet token, er dette noe som hverken støttes eller anbefales. I dette scenariet installerer du utgiveren på nytt.

Nei. Netskope Private Access utfører ikke tunnelering av ICMP, bare TCP og UDP. Du kan ikke kjøre ping eller søkerute over Netskope Private Access for å teste nettverkstilkoblinger.

Nei. Netskope Private Access støtter ikke protokoller som etablerer tilkoblinger fra en privat app til en klient. FTP Active-modus støttes for eksempel ikke.

Nei. Utgiveren utfører SSL-låsing for registreringsprosessen og godkjenning av sertifikat på serversiden mot et bestemt sertifikat.

I dette tilfellet, hvis det finnes en proxy som avslutter TLS-tilkoblingen, må målet legges til i tillatelseslisten / omgås (*.newedge.io).

Verten for den private appen ser at tilkoblingen stammer fra IP-adressen til utgiveren som er koblet til den. Det er ikke noe område. Avhengig av hvor mange utgivere som brukes til å koble til verten for den private appen, kan du tillate at hver av disse IP-adressene blir oppført.

Hvis det implementeres i Amazon Web Services, må du tilordne Amazon Machine Image (AMI) som KeyPair.pem du allerede har (eller generere en ny KeyPair.pem) under klargjøringen av utgiveren.

Skriv inn ssh -i [KEYPAIR.PEM] centos@[PUBLISHER] og trykk på Enter fra en SSH-klient.

Når du har koblet til utgiveren via SSH, blir du plassert i en interaktiv CLI-meny (kommandolinjegrensesnitt). Du kan velge alternativ 3 for å bli plassert i et normalt UNIX-CLI for ytterligere feilsøking. Hvis du vil ha mer informasjon, kan du se Hva er en god metode for å feilsøke tilgjengelighetsproblemer med en privat app/tjeneste bak en utgiver?

1. Høyreklikk på Start-menyen i Windows, og klikk deretter på Kjør.

2. Skriv inn cmd og trykk deretter på OK i Kjør-grensesnittet.

3. Skriv inn ssh centos@[publisher] og trykk på Enter i ledeteksten.

Utgivere fungerer i aktiv/passiv-modus. All trafikk går til en første utgiver hvis den er i drift (tilkoblet). Hvis den svikter, bytter vi til en sekundær utgiver.

Det første beste alternativet er å bruke feilsøkingsverktøyet. Klikk på Troubleshooter (Feilsøking) på siden Private Apps (Private Apper).

Velg den private appen og enheten du prøver å få tilgang til, og klikk deretter på Feilsøk.

Feilsøkingsverktøyet viser en liste over utførte kontroller, problemer som kan ha innvirkning på konfigurasjonen, og løsninger.