Takk for tilbakemeldingen.
Proxy-støtte for hybrid datasikkerhet og videonett
Tilbakemelding?Denne delen beskriver proxy-støttefunksjonen for Hybrid Data Security. Den er ment å supplere distribusjonsveiledningen for Cisco Webex Hybrid Data Security, tilgjengelig på https://www.cisco.com/go/hybrid-data-security. I en ny distribusjon konfigurerer du proxy-oppsettet på hver node etter at du har lastet opp og montert HDS-konfigurasjons-ISO-en på noden, og før du registrerer noden i Cisco Webex-skyen.
Hybrid datasikkerhet støtter eksplisitte, transparente inspiserende og ikke-inspiserende proxyer. Du kan knytte disse proxy-tjenerne til distribusjonen din, slik at du kan sikre og overvåke trafikk fra bedriften og ut til skyen. Du kan bruke et plattformadministratorgrensesnitt på nodene for sertifikatadministrasjon og for å sjekke den generelle tilkoblingsstatusen etter at du har konfigurert proxyen på nodene.
Hybrid Data Security-nodene støtter følgende proxy-alternativer:
-
Ingen proxy– Standardinnstillingen hvis du ikke bruker HDS-nodeoppsettet Trust Store & Proxy-konfigurasjon for å integrere en proxy. Ingen sertifikatoppdatering er nødvendig.
-
Transparent ikke-inspiserende proxy– Nodene er ikke konfigurert til å bruke en spesifikk proxy-serveradresse og skal ikke kreve noen endringer for å fungere med en ikke-inspiserende proxy. Ingen sertifikatoppdatering er nødvendig.
-
Transparent tunnelering eller inspeksjon av proxy– Nodene er ikke konfigurert til å bruke en spesifikk proxy-serveradresse. Ingen endringer i HTTP- eller HTTPS-konfigurasjonen er nødvendige på nodene. Nodene trenger imidlertid et rotsertifikat slik at de stoler på proxyen. Inspeksjon av proxyer brukes vanligvis av IT for å håndheve retningslinjer for hvilke nettsteder som kan besøkes og hvilke typer innhold som ikke er tillatt. Denne typen proxy dekrypterer all trafikken din (til og med HTTPS).
-
Eksplisitt proxy– Med eksplisitt proxy forteller du HDS-nodene hvilken proxy-server og autentiseringsskjema de skal bruke. For å konfigurere en eksplisitt proxy, må du angi følgende informasjon på hver node:
-
Proxy IP/FQDN– Adresse som kan brukes til å nå proxy-maskinen.
-
Proxy-port– Et portnummer som proxyen bruker til å lytte etter proxy-trafikk.
-
Proxy-protokoll– Avhengig av hva proxy-serveren din støtter, kan du velge mellom følgende protokoller:
-
HTTP – Viser og kontrollerer alle forespørsler som klienten sender.
-
HTTPS – Gir en kanal til serveren. Klienten mottar og validerer serverens sertifikat.
-
-
Autentiseringstype– Velg blant følgende autentiseringstyper:
-
Ingen– Ingen ytterligere autentisering er nødvendig.
Tilgjengelig hvis du velger enten HTTP eller HTTPS som proxy-protokoll.
-
Grunnleggende– Brukes av en HTTP-brukeragent for å oppgi brukernavn og passord når en forespørsel sendes. Bruker Base64-koding.
Tilgjengelig hvis du velger enten HTTP eller HTTPS som proxy-protokoll.
Krever at du oppgir brukernavn og passord på hver node.
-
Sammendrag– Brukes til å bekrefte kontoen før sensitiv informasjon sendes. Bruker en hash-funksjon på brukernavnet og passordet før sending over nettverket.
Bare tilgjengelig hvis du velger HTTPS som proxy-protokoll.
Krever at du oppgir brukernavn og passord på hver node.
-
-
Eksempel på hybride datasikkerhetsnoder og proxy
Dette diagrammet viser et eksempel på en tilkobling mellom Hybrid Data Security, nettverket og en proxy. For proxy-alternativene for transparent inspeksjon og HTTPS-eksplisitt inspeksjon må det samme rotsertifikatet installeres på proxyen og på Hybrid Data Security-nodene.
Blokkert ekstern DNS-oppløsningsmodus (eksplisitte proxy-konfigurasjoner)
Når du registrerer en node eller sjekker nodens proxy-konfigurasjon, tester prosessen DNS-oppslag og tilkobling til Cisco Webex-skyen. I distribusjoner med eksplisitte proxy-konfigurasjoner som ikke tillater ekstern DNS-løsning for interne klienter, går noden automatisk inn i modus for blokkert ekstern DNS-løsning hvis den ikke kan spørre DNS-serverne. I denne modusen kan noderegistrering og andre proxy-tilkoblingstester fortsette.
-
Vi støtter offisielt følgende proxy-løsninger som kan integreres med dine hybride datasikkerhetsnoder.
-
Gjennomsiktig proxy – Cisco Web Security Appliance (WSA).
-
Eksplisitt proxy – blekksprut.
Squid-proxyer som inspiserer HTTPS-trafikk kan forstyrre etableringen av websocket (wss:) forbindelser. For å omgå dette problemet, se Konfigurer Squid-proxyer for hybrid datasikkerhet.
-
-
Vi støtter følgende autentiseringstypekombinasjoner for eksplisitte proxyer:
-
Ingen autentisering med HTTP eller HTTPS
-
Grunnleggende autentisering med HTTP eller HTTPS
-
Digest-autentisering kun med HTTPS
-
-
For en transparent inspiserende proxy eller en eksplisitt HTTPS-proxy må du ha en kopi av proxyens rotsertifikat. Distribusjonsinstruksjonene i denne veiledningen forteller deg hvordan du laster opp kopien til Hybrid Data Security-nodenes klareringslagre.
-
Nettverket som er vert for HDS-nodene må konfigureres til å tvinge utgående TCP-trafikk på port 443 til å rutes gjennom proxyen.
-
Proxyer som inspiserer webtrafikk kan forstyrre web socket-tilkoblinger. Hvis dette problemet oppstår, vil det å omgå (ikke inspisere) trafikk til
wbx2.comogciscospark.comløse problemet.
Hvis nettverksmiljøet krever en proxy, bruk denne prosedyren for å angi typen proxy du vil integrere med Hybrid Data Security. Hvis du velger en transparent inspeksjonsproxy eller en eksplisitt HTTPS-proxy, kan du bruke nodens grensesnitt til å laste opp og installere rotsertifikatet. Du kan også sjekke proxy-tilkoblingen fra grensesnittet og feilsøke eventuelle problemer.
Før du begynner
-
Se Proxy-støtte for en oversikt over de støttede proxy-alternativene.
| 1 |
Skriv inn URL-adressen for oppsett av HDS-noden |
| 2 |
Gå til Trust Store & Proxy, og velg deretter et alternativ:
Følg de neste trinnene for en transparent inspeksjonsproxy, en eksplisitt HTTP-proxy med grunnleggende autentisering eller en eksplisitt HTTPS-proxy. |
| 3 |
Klikk på Last opp et rotsertifikat eller et sluttenhetssertifikat, og naviger deretter til og velg rotsertifikatet for proxyen. Sertifikatet er lastet opp, men ikke installert ennå, fordi du må starte noden på nytt for å installere sertifikatet. Klikk på vinkelpilen ved siden av sertifikatutstederens navn for å få mer informasjon, eller klikk på Slett hvis du har gjort en feil og vil laste opp filen på nytt. |
| 4 |
Klikk på Sjekk proxy-tilkobling for å teste nettverkstilkoblingen mellom noden og proxyen. Hvis tilkoblingstesten mislykkes, vil du se en feilmelding som viser årsaken og hvordan du kan løse problemet. Hvis du ser en melding som sier at ekstern DNS-løsning ikke var vellykket, klarte ikke noden å nå DNS-serveren. Denne betingelsen er forventet i mange eksplisitte proxy-konfigurasjoner. Du kan fortsette med oppsettet, og noden vil fungere i modus for blokkert ekstern DNS-løsning. Hvis du tror dette er en feil, fullfør disse trinnene, og se deretter Slå av blokkert ekstern DNS-oppløsningsmodus. |
| 5 |
Etter at tilkoblingstesten er bestått, for eksplisitt proxy satt til kun https, slå veksleknappen på Rut alle porter 443/444 https-forespørsler fra denne noden gjennom den eksplisitte proxyen. Denne innstillingen krever 15 sekunder for å tre i kraft. |
| 6 |
Klikk på Installer alle sertifikater i klareringslageret (vises for en eksplisitt HTTPS-proxy eller en transparent inspiserende proxy) eller Start på nytt (vises for en eksplisitt HTTP-proxy), les ledeteksten, og klikk deretter på Installer hvis du er klar. Noden starter på nytt innen få minutter. |
| 7 |
Etter at noden har startet på nytt, logg inn igjen om nødvendig, og åpne deretter siden Oversikt for å sjekke tilkoblingskontrollene og sørge for at de alle har grønn status. Proxy-tilkoblingskontrollen tester bare et underdomene av webex.com. Hvis det er tilkoblingsproblemer, er et vanlig problem at noen av skydomenene som er oppført i installasjonsinstruksjonene, blokkeres av proxy-tjeneren. |
Når du registrerer en node eller sjekker nodens proxy-konfigurasjon, tester prosessen DNS-oppslag og tilkobling til Cisco Webex-skyen. Hvis nodens DNS-server ikke kan løse offentlige DNS-navn, går noden automatisk inn i modus for blokkert ekstern DNS-løsning.
Hvis nodene dine kan løse offentlige DNS-navn gjennom interne DNS-servere, kan du slå av denne modusen ved å kjøre proxy-tilkoblingstesten på nytt på hver node.
Før du begynner
| 1 |
I en nettleser åpner du Hybrid Data Security-nodegrensesnittet (IP address/setup, For eksempel, https://192.0.2.0/setup), skriv inn administratorlegitimasjonen du har satt opp for noden, og klikk deretter på Logg på. |
| 2 |
Gå til Oversikt (standardsiden).  Når den er aktivert, er Blokkert ekstern DNS-oppløsning satt til Ja. |
| 3 |
Gå til Trust Store & Proxy -side. |
| 4 |
Klikk på Sjekk proxy-tilkobling. Hvis du ser en melding som sier at ekstern DNS-løsning ikke var vellykket, klarte ikke noden å nå DNS-serveren og vil forbli i denne modusen. Ellers, etter at du har startet noden på nytt og går tilbake til siden Oversikt, bør Blokkert ekstern DNS-oppløsning settes til nei. |
Hva du skal gjøre nå
Denne delen beskriver proxy-støttefunksjonen for Webex Video Mesh. Den er ment å supplere distribusjonsveiledningen for Cisco Webex Video Mesh, tilgjengelig på https://www.cisco.com/go/video-mesh. I en ny distribusjon konfigurerer du proxy-oppsettet på hver node etter at du har distribuert Video Mesh-programvaren i et virtuelt maskinmiljø, og før du registrerer noden i Cisco Webex-skyen.
Video Mesh støtter eksplisitte, transparente inspeksjons- og ikke-inspeksjonsproxyer. Du kan knytte disse proxyene til Video Mesh-distribusjonen din, slik at du kan sikre og overvåke trafikk fra bedriften og ut til skyen. Denne funksjonen sender signal- og administrasjonsbasert https-trafikk til proxyen. For transparente proxyer videresendes nettverksforespørsler fra Video Mesh-noder til en spesifikk proxy gjennom rutingsregler for bedriftsnettverk. Du kan bruke administrasjonsgrensesnittet for Video Mesh til sertifikatadministrasjon og den generelle tilkoblingsstatusen etter at du har implementert proxyen med nodene.
Media reiser ikke gjennom proxyen. Du må fortsatt åpne de nødvendige portene for at mediestrømmer skal nå skyen direkte. Se Porter og protokoller for administrasjon.
Følgende proxy-typer støttes av Video Mesh:
-
Eksplisitt proxy (inspiserende eller ikke-inspiserende) – Med eksplisitt proxy forteller du klienten (Video Mesh-noder) hvilken proxy-server som skal brukes. Dette alternativet støtter én av følgende autentiseringstyper:
-
Ingen – Ingen ytterligere autentisering er nødvendig. (For eksplisitt HTTP- eller HTTPS-proxy.)
-
Grunnleggende – Brukes av en HTTP-brukeragent for å oppgi brukernavn og passord når en forespørsel sendes, og bruker Base64-koding. (For eksplisitt HTTP- eller HTTPS-proxy.)
-
Digest – Brukes til å bekrefte kontoens identitet før sensitiv informasjon sendes, og bruker en hash-funksjon på brukernavnet og passordet før sending over nettverket. (For eksplisitt HTTPS-proxy.)
-
NTLM – I likhet med Digest brukes NTLM til å bekrefte kontoens identitet før sensitiv informasjon sendes. Bruker Windows-legitimasjon i stedet for brukernavn og passord. Denne autentiseringsordningen krever flere utvekslinger for å fullføres. (For eksplisitt HTTP-proxy.)
-
-
Transparent proxy (ikke-inspiserende) – Video Mesh-noder er ikke konfigurert til å bruke en spesifikk proxy-serveradresse og skal ikke kreve noen endringer for å fungere med en ikke-inspiserende proxy.
-
Transparent proxy (inspeksjon) – Video Mesh-noder er ikke konfigurert til å bruke en bestemt proxy-serveradresse. Ingen endringer i http(s)-konfigurasjonen er nødvendige på Video Mesh, men Video Mesh-nodene trenger et rotsertifikat slik at de stoler på proxyen. Inspeksjon av proxyer brukes vanligvis av IT for å håndheve retningslinjer for hvilke nettsteder som kan besøkes og typer innhold som ikke er tillatt. Denne typen proxy dekrypterer all trafikken din (til og med https).
-
Vi støtter offisielt følgende proxy-løsninger som kan integreres med Video Mesh-nodene dine.
-
Cisco Web Security Appliance (WSA) for transparent proxy
-
Blekksprut for eksplisitt proxy
-
-
For en eksplisitt proxy eller transparent inspiserende proxy som inspiserer (dekrypterer trafikk), må du ha en kopi av proxyens rotsertifikat som du må laste opp til Video Mesh-nodens tillitslager på webgrensesnittet.
-
Vi støtter følgende eksplisitte proxy- og autentiseringstypekombinasjoner:
-
Ingen autentisering med http og https
-
Grunnleggende autentisering med http og https
-
Digest-autentisering kun med https
-
NTLM-autentisering kun med http
-
-
For transparente proxyer må du bruke router/switch å tvinge HTTPS/443 trafikk for å gå til proxyen. Du kan også tvinge Web Socket til å gå til proxy. (Web Socket bruker https.)
Video Mesh krever web socket-tilkoblinger til skytjenester, slik at nodene fungerer som de skal. På eksplisitte inspeksjonsproxyer og transparente inspeksjonsproxyer kreves http-overskrifter for en riktig websocket-tilkobling. Hvis de endres, vil websocket-tilkoblingen mislykkes.
Når det oppstår en feil med websocket-tilkoblingen på port 443 (med transparent inspeksjonsproxy aktivert), fører det til en advarsel etter registrering i Control Hub: «Webex Video Mesh SIP-anrop fungerer ikke som de skal.» Den samme alarmen kan oppstå av andre årsaker når proxy ikke er aktivert. Når websocket-overskrifter er blokkert på port 443, flyter ikke media mellom apper og SIP-klienter.
Hvis media ikke flyter, skjer dette ofte når https-trafikk fra noden over port 443 svikter:
-
Port 443-trafikk er tillatt av proxyen, men det er en inspiserende proxy og ødelegger websocketen.
For å rette opp disse problemene må du kanskje «bypass» eller «spleise» (deaktivere inspeksjon) på port 443 for å: *.wbx2.com og *.ciscospark.com.
-
Bruk denne prosedyren til å angi typen proxy du vil integrere med et videonett. Hvis du velger en transparent inspiserende proxy eller en eksplisitt proxy, kan du bruke nodens grensesnitt til å laste opp og installere rotsertifikatet, sjekke proxy-tilkoblingen og feilsøke eventuelle problemer.
Før du begynner
-
Se Proxy-støtte for Video Mesh for en oversikt over de støttede proxy-alternativene.
| 1 |
Skriv inn URL-adressen for oppsett av Video Mesh | ||||||||||
| 2 |
Gå til Trust Store & Proxy, og velg deretter et alternativ:
Følg de neste trinnene for en transparent inspeksjon eller eksplisitt proxy. | ||||||||||
| 3 |
Klikk på Last opp et rotsertifikat eller sluttenthetssertifikat, og finn og velg deretter rotsertifikatet for den eksplisitte eller transparente inspeksjonsproxyen. Sertifikatet er lastet opp, men ikke installert ennå, fordi noden må startes på nytt for å installere sertifikatet. Klikk på pilen ved siden av sertifikatutstederens navn for å få mer informasjon, eller klikk på Slett hvis du har gjort en feil og vil laste opp filen på nytt. | ||||||||||
| 4 |
For transparent inspeksjon eller eksplisitte proxyer, klikk på Sjekk proxytilkobling for å teste nettverkstilkoblingen mellom Video Mesh-noden og proxyen. Hvis tilkoblingstesten mislykkes, vil du se en feilmelding som viser årsaken og hvordan du kan løse problemet. | ||||||||||
| 5 |
Etter at tilkoblingstesten er bestått, for eksplisitt proxy, slå veksleknappen på Rut alle port 443 https-forespørsler fra denne noden gjennom den eksplisitte proxyen. Denne innstillingen krever 15 sekunder for å tre i kraft. | ||||||||||
| 6 |
Klikk på Installer alle sertifikater i klareringslageret (vises hver gang et rotsertifikat ble lagt til under proxy-oppsettet) eller Start på nytt (vises hvis det ikke ble lagt til noe rotsertifikat), les ledeteksten, og klikk deretter på Installer hvis du er klar. Noden starter på nytt innen få minutter. | ||||||||||
| 7 |
Etter at noden har startet på nytt, logg inn igjen om nødvendig, og åpne deretter siden Oversikt for å sjekke tilkoblingskontrollene og sørge for at de alle har grønn status. Proxy-tilkoblingskontrollen tester bare et underdomene av webex.com. Hvis det er tilkoblingsproblemer, er et vanlig problem at noen av skydomenene som er oppført i installasjonsinstruksjonene, blokkeres av proxy-tjeneren. |
Hvilken trafikk går gjennom proxy
For Video Mesh går ikke media gjennom proxyen. Denne funksjonen sender signal- og administrasjonsbasert https-trafikk til proxyen. Du må fortsatt åpne de nødvendige portene for at mediestrømmer skal nå skyen direkte.
TCP-port 444 er ikke aktivert på proxy
Denne porten er et krav for Video Mesh, fordi Video Mesh bruker denne porten til å få tilgang til skybaserte tjenester som den må bruke for å fungere riktig. Et proxy-unntak må gjøres for denne porten og ALLE som dokumentert i Video Mesh-distribusjonsveiledningen og Nettverkskrav for Webex Teams-tjenester.
Filtrering av signaltrafikk etter IP-adresse støttes ikke, ettersom IP-adressene som brukes av løsningene våre er dynamiske og kan endres når som helst.
Ingen rotsertifikat installert
Når nodene dine kommuniserer med en eksplisitt proxy, må du installere rotsertifikatet og angi et unntak for den URL-en i brannmuren.
Tilkoblingssjekken mislykkes
Hvis proxy-tilkoblingskontrollen ble bestått og proxy-installasjonen ble fullført, kan det hende at tilkoblingskontrollene på oversiktssiden fortsatt mislykkes av disse årsakene:
-
Proxy-tjeneren inspiserer trafikk som ikke går til webex.com.
-
Proxy-tjeneren blokkerer andre domener enn webex.com.
Autentiseringsdetaljene er feil
For proxyer som bruker en autentiseringsmekanisme, sørg for at du legger til riktig autentiseringsdetalj i noden.
Overbelastning på proxyen
Overbelastning på proxy-serveren din kan forårsake forsinkelser og fall i trafikken til skyen. Sjekk proxy-miljøet ditt for å se om trafikkbegrensning er nødvendig.
Websocket kan ikke koble til via Squid-proxyen
Squid-proxyer som inspiserer HTTPS-trafikk kan forstyrre etableringen av websocket (wss:)-tilkoblinger som Hybrid Data Security krever. Disse avsnittene gir veiledning om hvordan du konfigurerer ulike versjoner av Squid til å ignorere wss: -trafikk for at tjenestene skal fungere som de skal.
Blekksprut 4 og 5
Legg til on_unsupported_protocol -direktivet i squid.conf:
on_unsupported_protocol tunnel allBlekksprut 3.5.27
Vi testet hybrid datasikkerhet med følgende regler lagt til i squid.conf. Disse reglene kan endres etter hvert som vi utvikler funksjoner og oppdaterer Webex-skyen.
acl wssMercuryConnection ssl::server_name_regex mercury-connection
ssl_bump splice wssMercuryConnection
acl step1 at_step SslBump1
acl step2 at_step SslBump2
acl step3 at_step SslBump3
ssl_bump peek step1 all
ssl_bump stare step2 all
ssl_bump bump step3 all
