Takk for tilbakemeldingen.
Proxy-støtte for hybrid datasikkerhet og videonett
Tilbakemelding?Denne delen beskriver proxy-støttefunksjonen for hybrid datasikkerhet. Den er ment å supplere distribusjonsveiledningen for Cisco Webex hybrid datasikker het, 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 på noden, og før du registrerer noden i Cisco Webex skyen.
Hybrid datasikkerhet støtter eksplisitte, gjennomsiktige og ikke-inspiserende proxyer. Du kan knytte disse proxy-ene til distribusjonen din slik at du kan sikre og overvåke trafikk fra bedriften ut til skyen. Du kan bruke et plattformadministratorgrensesnitt på nodene for sertifikatadministrasjon og for å kontrollere den generelle tilkoblingsstatusen etter at du har konfigurert proxyen på nodene.
Hybrid Data Security-nodene støtter følgende proxy-alternativer:
-
Ingen proxy — Standard hvis du ikke bruker HDS-nodeoppsettet Klareringsbutikk og proxy-konfigurasjon til å integrere en proxy. Ingen sertifikatoppdatering er nødvendig.
-
Transparent proxy uten inspeksjon — Nodene er ikke konfigurert til å bruke en bestemt proxy-serveradresse og bør ikke kreve noen endringer for å fungere med en ikke-inspiserende proxy. Ingen sertifikatoppdatering er nødvendig.
-
Gjennomsiktig tunneling eller inspeksjon av proxy — Nodene er ikke konfigurert til å bruke en bestemt proxy-serveradresse. Ingen HTTP- eller HTTPS-konfigurasjonsendringer er nødvendige på nodene. Nodene trenger imidlertid et rotsertifikat slik at de stoler på proxyen. Inspekterende proxyer brukes vanligvis av IT til å 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. Hvis du vil 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 støtter, velger du 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.
-
-
Godkjenningsty pe — Velg blant følgende godkjenningstyper:
-
Ingen — Ingen ytterligere godkjenning er nødvendig.
Tilgjengelig hvis du velger enten HTTP eller HTTPS som proxy-protokoll.
-
Grunn leggende — Brukes for en HTTP-brukeragent for å oppgi et brukernavn og passord når du foretar en forespørsel. Bruker Base64-koding.
Tilgjengelig hvis du velger enten HTTP eller HTTPS som proxy-protokoll.
Krever at du skriver inn brukernavn og passord på hver node.
-
Sammendrag —Brukes til å bekrefte kontoen før du sender sensitiv informasjon. 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 skriver inn brukernavn og passord på hver node.
-
-
Eksempel på hybride datasikkerhetsnoder og proxy
Dette diagrammet viser et eksempel på forbindelse mellom Hybrid Data Security, nettverk og en proxy. For proxy-alternativene for gjennomsiktig 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-oppløsning for interne klienter, hvis noden ikke kan spørre DNS-serverne, går den automatisk til modus for blokkert ekstern DNS-oppløsning. I denne modusen kan noderegistrering og andre proxy-tilkoblingstester fortsette.
-
Vi støtter offisielt følgende proxy-løsninger som kan integreres med dine Hybrid Data Security-noder.
-
Gjennomsiktig proxy — Cisco Web Security Appliance (WSA).
-
Eksplisitt proxy - blekksprut.
Squid-proxyer som inspiserer HTTPS-trafikk kan forstyrre etableringen av websocket (wss:) -tilkoblinger. Hvis du vil omgå dette problemet, kan du se Konfigurere Squid-proxyer for hybrid datasikkerhet.
-
-
Vi støtter følgende godkjenningstypekombinasjoner for eksplisitte proxyer:
-
Ingen autentisering med HTTP eller HTTPS
-
Grunnleggende godkjenning med HTTP eller HTTPS
-
Fordøst-godkjenning bare med HTTPS
-
-
For en gjennomsiktig inspekterende proxy eller en HTTPS-eksplisitt proxy, må du ha en kopi av proxy-rotsertifikatet. Distribusjonsinstruksjonene i denne veiledningen forteller deg hvordan du laster opp kopien til klareringslagrene til Hybrid Data Security-nodene.
-
Nettverket som er vert for HDS-nodene, må konfigureres til å tvinge utgående TCP-trafikk på port 443 til å rute gjennom proxyen.
-
Proxyer som inspiserer netttrafikk kan forstyrre nettkontaktene. Hvis dette problemet oppstår, kan du omgå (ikke inspisere) trafikk til
wbx2.comogciscospark.comløse problemet.
Hvis nettverksmiljøet krever en proxy, bruker du denne fremgangsmåten til å angi hvilken type proxy du vil integrere med Hybrid Data Security. Hvis du velger en gjennomsiktig inspekterende proxy eller en HTTPS-eksplisitt proxy, kan du bruke nodens grensesnitt til å laste opp og installere rotsertifikatet. Du kan også sjekke proxy-tilkoblingen fra grensesnittet, og feilsøke potensielle problemer.
Før du begynner
-
Se Proxy-støtte for en oversikt over proxy-alternativene som støttes.
| 1 |
Skriv inn URL-adressen for HDS-nodeoppsett |
| 2 |
Gå til Trust Store & Proxy, og velg deretter et alternativ:
Følg de neste trinnene for en gjennomsiktig inspeksjonsproxy, en HTTP-eksplisitt proxy med grunnleggende godkjenning eller en HTTPS-eksplisitt proxy. |
| 3 |
Klikk Last opp et rotsertifikat eller sluttenhetssertifikat, og naviger deretter til et velg rotsertifikatet for proxyen. Sertifikatet er lastet opp, men ikke installert ennå fordi du må starte noden på nytt for å installere sertifikatet. Klikk på chevronpilen ved navnet på sertifikatutstederen for å få flere detaljer, eller klikk på Slett hvis du har gjort en feil og vil laste opp filen på nytt. |
| 4 |
Klikk Kontroller proxy-tilkobling for å teste nettverkstilkoblingen mellom noden og proxyen. Hvis tilkoblingstesten mislykkes, ser du en feilmelding som viser årsaken og hvordan du kan rette problemet. Hvis du ser en melding om at ekstern DNS-oppløsning ikke var vellykket, kunne ikke noden nå DNS-serveren. Denne tilstanden forventes i mange eksplisitte proxy-konfigurasjoner. Du kan fortsette med oppsettet, og noden vil fungere i blokkert ekstern DNS-oppløsningsmodus. Hvis du tror dette er en feil, fullfører du disse trinnene og ser deretter Slå av blokkert ekstern DNS-oppløsningsmodus. |
| 5 |
Etter at tilkoblingstesten er bestått, for eksplisitt proxy satt til bare https, slå bryteren på til Rute alle port 443/444 https-forespørsler fra denne noden gjennom den eksplisitte proxyen. Denne innstillingen krever 15 sekunder for å tre i kraft. |
| 6 |
Klikk Installer alle sertifikater i klareringsbutikken (vises for en eksplisitt HTTPS-proxy eller en gjennomsiktig inspeksjonsproxy) eller Start på nytt (vises for en eksplisitt HTTP-proxy), les ledeteksten og klikk deretter Installer hvis du er klar. Noden starter på nytt innen få minutter. |
| 7 |
Når noden har startet på nytt, logger du på igjen om nødvendig, og åpner deretter Oversikt- siden for å sjekke tilkoblingskontrollene for å sikre at de alle har grønn status. Proxy-tilkoblingskontrollen tester bare et underdomene til webex.com. Hvis det er tilkoblingsproblemer, er et vanlig problem at noen av skydomenene som er oppført i installasjonsinstruksjonene, blir blokkert ved proxyen. |
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 i modus for blokkert ekstern DNS-oppløsning.
Hvis nodene dine klarer å løse offentlige DNS-navn via 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 nodegrensesnittet Hybrid Data Security (IP-adresse/oppsett, for eksempel https://192.0.2.0/setup), angir administratorlegitimasjonen du konfigurerte for noden, og klikker deretter på Log g på. |
| 2 |
Gå til Oversikt (standardsiden). 
Når den er aktivert, er Blok kert ekstern DNS-oppløsning satt til Ja. |
| 3 |
Gå til Trust Store & Proxy- siden. |
| 4 |
Klikk Kontroller proxy-tilkobling. Hvis du ser en melding om at ekstern DNS-oppløsning ikke var vellykket, kunne 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 Over sikt-siden, bør blokkert ekstern DNS-oppløsning settes til nei. |
Hva du skal gjøre videre
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 på et virtuelt maskinmiljø, og før du registrerer noden i Cisco Webex skyen.
Video Mesh støtter eksplisitte, gjennomsiktige inspiserende og ikke-inspiserende proxyer. Du kan knytte disse proxy-ene til Video Mesh-distribusjonen din slik at du kan sikre og overvåke trafikk fra bedriften ut til skyen. Denne funksjonen sender signalering og administrasjon https-basert trafikk til proxyen. For gjennomsiktige proxyer videresendes nettverksforespørsler fra Video Mesh-noder til en bestemt proxy gjennom ruteregler for bedriftsnettverk. Du kan bruke administrasjonsgrensesnittet for Video Mesh for 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 (inspiserer eller ikke inspiserer) —Med eksplisitt proxy forteller du klienten (Video Mesh-noder) hvilken proxy-server du skal bruke. Dette alternativet støtter én av følgende godkjenningstyper:
-
Ingen — Ingen ytterligere godkjenning er nødvendig. (For HTTP- eller HTTPS-eksplisitt proxy.)
-
Grunnleggende — Brukes for en HTTP-brukeragent for å oppgi et brukernavn og passord når du foretar en forespørsel, og bruker Base64-koding. (For HTTP- eller HTTPS-eksplisitt proxy.)
-
Digest — Brukes til å bekrefte identiteten til kontoen før du sender sensitiv informasjon, og bruker en hash-funksjon på brukernavnet og passordet før sending over nettverket. (For HTTPS-eksplisitt proxy.)
-
NTLM — I likhet med Digest brukes NTLM til å bekrefte identiteten til kontoen før sensitiv informasjon sendes. Bruker Windows-legitimasjon i stedet for brukernavn og passord. Denne godkjenningsordningen krever flere utvekslinger for å fullføre. (For HTTP-eksplisitt proxy.)
-
-
Transparent proxy (ikke-inspiserende) —Video Mesh-noder er ikke konfigurert til å bruke en bestemt proxy-serveradresse og bør 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 http (s) -konfigurasjonsendringer er nødvendig på Video Mesh, men Video Mesh-nodene trenger et rotsertifikat slik at de stoler på proxyen. Inspekterende proxyer brukes vanligvis av IT til å 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 gjennomsiktig proxy
-
Blekksprut for eksplisitt proxy
-
-
For en eksplisitt proxy eller gjennomsiktig inspekterende proxy som inspiserer (dekrypterer trafikk), må du ha en kopi av proxy-rotsertifikatet som du må laste opp til klareringslageret for Video Mesh-noden på webgrensesnittet.
-
Vi støtter følgende eksplisitte proxy- og autentiseringstypekombinasjoner:
-
Ingen autentisering med http og https
-
Grunnleggende autentisering med http og https
-
Fordøst-godkjenning bare med https
-
NTLM-godkjenning med bare http
-
-
For gjennomsiktige proxyer må du bruke ruteren/bryteren for å tvinge HTTPS/443-trafikk til å gå til proxyen. Du kan også tvinge Web Socket til å gå til proxy. (Web Socket bruker https.)
Video Mesh krever nettstikkontakter til skytjenester, slik at nodene fungerer riktig. Ved eksplisitt inspeksjon og gjennomsiktig inspeksjon av proxyer kreves http-overskrifter for en riktig websocket-tilkobling. Hvis de endres, vil websocket-tilkoblingen mislykkes.
Når nettsocket-tilkoblingsfeilen oppstår på port 443 (med gjennomsiktig inspeksjonsproxy aktivert), fører det til en advarsel etter registrering i Control Hub: «Webex Video Mesh SIP-anrop fungerer ikke riktig.» Den samme alarmen kan oppstå av andre grunner 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-trafikken fra noden over port 443 svikter:
-
Port 443-trafikk er tillatt av proxyen, men det er en inspekterende proxy og bryter nettsokkelen.
For å rette opp disse problemene må du kanskje «omgå» eller «spleise» (deaktivere inspeksjon) på port 443 til: *.wbx2.com og*.ciscospark.com.
-
Bruk denne fremgangsmåten til å angi hvilken type proxy du vil integrere med et videonett. Hvis du velger en gjennomsiktig inspekterende proxy eller en eksplisitt proxy, kan du bruke nodens grensesnitt til å laste opp og installere rotsertifikatet, kontrollere proxy-tilkoblingen og feilsøke eventuelle problemer.
Før du begynner
-
Se Proxy-støtte for Video Mesh for en oversikt over proxy-alternativene som støttes.
| 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 gjennomsiktig inspeksjon eller eksplisitt proxy. | ||||||||||
| 3 |
Klikk Last opp et rotsertifikat eller sluttenhetssertifikat, og finn og velg deretter rotsertifikatet for den eksplisitte eller gjennomsiktige inspeksjonsproxyen. Sertifikatet er lastet opp, men ikke installert ennå fordi noden må startes på nytt for å installere sertifikatet. Klikk pilen ved navnet på sertifikatutstederen for å få mer informasjon, eller klikk på Slett hvis du har gjort en feil og vil laste opp filen på nytt. | ||||||||||
| 4 |
Hvis du vil ha gjennomsiktig inspeksjon eller eksplisitte proxyer, klikker du Kontroller proxy-tilkobling for å teste nettverkstilkoblingen mellom Video Mesh-noden og proxyen. Hvis tilkoblingstesten mislykkes, ser du en feilmelding som viser årsaken og hvordan du kan rette problemet. | ||||||||||
| 5 |
Etter at tilkoblingstesten har bestått, for eksplisitt proxy, slår du bryteren på til Rute alle port 443 https-forespørsler fra denne noden gjennom den eksplisitte proxyen. Denne innstillingen krever 15 sekunder for å tre i kraft. | ||||||||||
| 6 |
Klikk Installer alle sertifikater i klareringsbutikken (vises når et rotsertifikat ble lagt til under proxy-oppsettet) eller Start på nytt (vises hvis ikke noe rotsertifikat ble lagt til), les ledeteksten, og klikk deretter Installer hvis du er klar. Noden starter på nytt innen få minutter. | ||||||||||
| 7 |
Når noden har startet på nytt, logger du på igjen om nødvendig, og åpner deretter Oversikt- siden for å sjekke tilkoblingskontrollene for å sikre at de alle har grønn status. Proxy-tilkoblingskontrollen tester bare et underdomene til webex.com. Hvis det er tilkoblingsproblemer, er et vanlig problem at noen av skydomenene som er oppført i installasjonsinstruksjonene, blir blokkert ved proxyen. |
Hvilken trafikk går gjennom proxy
For Video Mesh krysser ikke media proxyen. Denne funksjonen sender signalering og administrasjon https-basert 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. Det må gjøres et proxy-unntak for denne porten og ALLE som dokumentert i Video Mesh-distribusjonsveiledningen og nettverkskravene for Webex Teams Services.
Filtrering av signaltrafikk etter IP-adresse støttes ikke, da IP-adressene som brukes av våre løsninger er dynamiske og kan endres når som helst.
Ingen rotsertifikat installert
Når nodene dine snakker med en eksplisitt proxy, må du installere rotsertifikatet og angi et unntak for den URL-adressen på brannmuren.
Tilkoblingskontroll mislykkes
Hvis proxy-tilkoblingskontrollen bestått og proxy-installasjonen ble fullført, kan tilkoblingskontrollene på oversiktssiden fortsatt mislykkes av følgende grunner:
-
Proxyen inspiserer trafikk som ikke går til webex.com.
-
Proxyen blokkerer andre domener enn webex.com.
Autentiseringsdetaljene er feil
For proxyer som bruker en godkjenningsmekanisme, må du sørge for at du legger til de riktige godkjenningsdetaljene i noden.
Overbelastning på proxyen
Overbelastning på proxyen din kan føre til forsinkelser og fall med trafikk til skyen. Sjekk proxy-miljøet ditt for å se om trafikkbegrensning er nødvendig.
Websocket kan ikke koble til via Squid Proxy
Squid-proxyer som inspiserer HTTPS-trafikk kan forstyrre etableringen av websocket (wss:) -tilkoblinger som Hybrid Data Security krever. Disse seksjonene gir veiledning om hvordan du konfigurerer forskjellige versjoner av Squid for å ignorere wss:trafikk for riktig drift av tjenestene.
Blekksprut 4 og 5
Legg til on_unsupported_protocoldirektivet til squid.conf:
on_unsupported_protocol tunnel allBlekksprut 3.5.27
Vi testet vellykket Hybrid Data Security med følgende regler lagt til squid.conf. Disse reglene kan endres når 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
