Proxy-støtte for hybriddatasikkerhet og videonett
Denne delen beskriver proxy-støttefunksjonen for hybriddatasikkerhet. Den er ment som et tillegg til distribusjonsveiledningen for Cisco Webex hybriddatasikkerhet, som er 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 Data Security støtter eksplisitte, gjennomsiktige inspeksjons- og ikke-inspeksjons-proxyer. Du kan knytte disse proxyene til distribusjonen 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 å kontrollere den generelle tilkoblingsstatusen etter at du har konfigurert proxyen på nodene.
Nodene for hybriddatasikkerhet støtter følgende proxy-alternativer:
-
Ingen proxy – Standard hvis du ikke bruker HDS-nodeoppsettet Trust Store & Proxy-konfigurasjonen til å integrere en proxy. Ingen sertifikatoppdatering er nødvendig.
-
Gjennomsiktig ikke-inspeksjons-proxy– Nodene er ikke konfigurert til å bruke en bestemt proxy-serveradresse og bør ikke kreve endringer for å fungere med en ikke-inspeksjons-proxy. Ingen sertifikatoppdatering er nødvendig.
-
Gjennomsiktig tunnelering eller inspeksjons-proxy– Nodene er ikke konfigurert til å bruke en bestemt proxy-serveradresse. Ingen endringer i HTTP- eller HTTPS-konfigurasjonen er nødvendig på nodene. Nodene trenger imidlertid et rotsertifikat slik at de stoler på proxyen. Inspeksjons-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 godkjenningsskjema som skal brukes. 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.
-
-
Godkjenningstype– velg blant følgende godkjenningstyper:
-
Ingen – ingen ytterligere godkjenning er nødvendig.
Tilgjengelig hvis du velger enten HTTP eller HTTPS som proxy-protokoll.
-
Grunnleggende – Brukes for en HTTP-brukeragent til å oppgi 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 for hver node.
-
Sammendrag – Brukes til å bekrefte kontoen før sensitiv informasjon sendes. Bruker en hash-funksjon på brukernavnet og passordet før det sendes over nettverket.
Bare tilgjengelig hvis du velger HTTPS som proxy-protokoll.
Krever at du skriver inn brukernavn og passord for hver node.
-
-
Eksempel på noder og proxy for hybriddatasikkerhet
Dette diagrammet viser en eksempelkobling mellom hybriddatasikkerhet, nettverk og en proxy. For gjennomsiktig inspeksjon og eksplisitt HTTPS-inspeksjons-proxy-alternativer, må det samme rotsertifikatet være installert på proxyen og på nodene for hybriddatasikkerhet.
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, går den automatisk inn i blokkert ekstern DNS-oppløsning-modus hvis noden 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 nodene for hybriddatasikkerhet.
-
Gjennomsiktig proxy – Cisco Web Security Appliance (WSA).
-
Eksplisitt proxy – Squid.
Squid-proxyer som inspiserer HTTPS-trafikk kan forstyrre opprettelsen av websocket-tilkoblinger (wss:). Hvis du vil omgå dette problemet, kan du se Konfigurere Squid-proxyer for hybriddatasikkerhet.
-
-
Vi støtter følgende kombinasjoner av godkjenningstyper for eksplisitte proxyer:
-
Ingen godkjenning med HTTP eller HTTPS
-
Grunnleggende godkjenning med HTTP eller HTTPS
-
Digest-godkjenning kun med HTTPS
-
-
For en gjennomsiktig inspeksjons-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 klareringslagrene for hybriddatasikkerhetsnodene.
-
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 webtrafikk kan forstyrre Web Socket-tilkoblinger. Hvis dette problemet oppstår, vil det å omgå (ikke inspisere) trafikk til
wbx2.com
, ogciscospark.com
vil løse problemet.
Hvis nettverksmiljøet krever en proxy, bruker du denne fremgangsmåten til å angi hvilken type proxy du vil integrere med hybrid datasikkerhet. Hvis du velger en gjennomsiktig inspeksjons-proxy 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 proxy-alternativene som støttes.
1 |
Skriv inn URL-adressen for HDS-nodeoppsett |
2 |
Gå til Klareringslager og proxy, og velg deretter et alternativ:
Følg de neste trinnene for en gjennomsiktig inspeksjons-proxy, en eksplisitt HTTP-proxy med grunnleggende godkjenning eller en eksplisitt HTTPS-proxy. |
3 |
Klikk på Last opp et rotsertifikat eller sluttenhetssertifikat, og gå deretter til å velge rotsertifikatet for proxyen. Sertifikatet er lastet opp, men er ennå ikke installert fordi du må starte noden på nytt for å installere sertifikatet. Klikk på chevron-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 |
Klikk på Kontroller proxy-tilkobling for å teste nettverkstilkoblingen mellom noden og proxyen. Hvis tilkoblingstesten mislykkes, får du en feilmelding som viser årsaken og hvordan du kan løse problemet. Hvis du ser en melding om at den eksterne DNS-oppløsningen 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 modus for blokkert ekstern DNS-oppløsning. Hvis du tror dette er en feil, fullfører du disse trinnene og ser Slå av blokkert ekstern DNS-oppløsningsmodus. |
5 |
Etter at tilkoblingstesten er bestått, bare for eksplisitt proxy satt til https, slår du veksleknappen til Rute alle port 443/444 https-forespørsler fra denne noden gjennom den eksplisitte proxyen. Denne innstillingen tar 15 sekunder før den trer i kraft. |
6 |
Klikk på Installer alle sertifikater i klareringslageret (vises for en eksplisitt HTTPS-proxy eller en gjennomsiktig inspeksjons-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 noen få minutter. |
7 |
Etter at noden har startet på nytt, logger du på igjen om nødvendig og åpner deretter Oversikt -siden for å sjekke tilkoblingskontrollene for å sikre at alle er i grønn status. Proxy-tilkoblingskontrollen tester bare et underdomene av webex.com. Hvis det oppstår tilkoblingsproblemer, er et vanlig problem at noen av skydomenene som er oppført i installasjonsinstruksjonene, blokkeres 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 inn i modus for blokkert ekstern DNS-opplø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 |
Åpne nodegrensesnittet for hybriddatasikkerhet i en nettleser (IP-adresse/oppsett, for eksempel https://192.0.2.0/setup), angi administratorlegitimasjonen du har konfigurert for noden, og klikk deretter på Logg på. |
2 |
Gå til Oversikt (standardsiden). Når den er aktivert, settes Blokkert ekstern DNS-oppløsning til Ja. |
3 |
Gå til siden Klareringslager og proxy . |
4 |
Klikk på Kontroller proxy-tilkobling. Hvis du ser en melding om at den eksterne DNS-oppløsningen ikke var vellykket, kunne ikke noden nå DNS-serveren og vil forbli i denne modusen. Hvis ikke, etter at du har startet noden på nytt og gått tilbake til Oversikt -siden, skal Blokkert ekstern DNS-oppløsning settes til Nei. |
Hva du skal gjøre nå
Denne delen beskriver proxy-støttefunksjonen for Webex-videonett. Den er ment som et tillegg til distribusjonsveiledningen for Cisco Webex-videonett, som er 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 programvaren for videonett i et virtuelt maskinmiljø, og før du registrerer noden i Cisco Webex-skyen.
Videonett støtter eksplisitte, gjennomsiktige inspeksjons- og ikke-inspeksjons-proxyer. Du kan knytte disse proxyer til videonett-distribusjonen 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 gjennomsiktige proxyer videresendes nettverksforespørsler fra videonettnoder til en bestemt proxy gjennom rutingsregler for bedriftsnettverk. Du kan bruke administrasjonsgrensesnittet for videonett til sertifikatadministrasjon og den generelle tilkoblingsstatusen etter at du har implementert proxyen med nodene.
Media går ikke gjennom proxyen. Du må fortsatt åpne de nødvendige portene for mediestrømmer for å nå skyen direkte. Se Porter og protokoller for administrasjon.
Følgende proxy-typer støttes av videonett:
-
Eksplisitt proxy (inspeksjons- eller ikke-inspeksjons-) – Med eksplisitt proxy forteller du klienten (videonettnoder) hvilken proxy-server som skal brukes. Dette alternativet støtter én av følgende godkjenningstyper:
-
Ingen – ingen ytterligere godkjenning er nødvendig. (For eksplisitt proxy for HTTP eller HTTPS.)
-
Grunnleggende – Brukes for en HTTP-brukeragent til å oppgi brukernavn og passord når du foretar en forespørsel, og bruker Base64-koding. (For eksplisitt proxy for HTTP eller HTTPS.)
-
Sammendrag – Brukes til å bekrefte identiteten til kontoen før sensitiv informasjon sendes, og bruker en hash-funksjon på brukernavnet og passordet før det sendes over nettverket. (For eksplisitt HTTPS-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. Dette godkjenningsskjemaet krever flere utvekslinger for å fullføre. (For eksplisitt HTTP-proxy.)
-
-
Gjennomsiktig proxy (ikke-inspeksjons) – Noder for videonett er ikke konfigurert til å bruke en bestemt proxy-serveradresse og bør ikke kreve endringer for å fungere med en ikke-inspeksjons-proxy.
-
Gjennomsiktig proxy (inspeksjon) – Noder for videonett er ikke konfigurert til å bruke en bestemt proxy-serveradresse. Ingen konfigurasjonsendringer for http(s) er nødvendige på videonett, men nodene for videonett trenger et rotsertifikat slik at de klarerer proxyen. Inspeksjons-proxyer brukes vanligvis av IT til å håndheve policyer om 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).
-
Vi støtter offisielt følgende proxy-løsninger som kan integreres med dine videonettnoder.
-
Cisco Web Security Appliance (WSA) for gjennomsiktig proxy
-
Squid for eksplisitt proxy
-
-
For en eksplisitt proxy eller gjennomsiktig inspeksjons-proxy som inspiserer (dekrypterer trafikk), må du ha en kopi av proxyens rotsertifikat som du må laste opp til klareringslageret for videonettnoder på webgrensesnittet.
-
Vi støtter følgende eksplisitte kombinasjoner av proxy- og godkjenningstyper:
-
Ingen godkjenning med http og https
-
Grunnleggende godkjenning med http og https
-
Sammendragsgodkjenning kun med https
-
NTLM-godkjenning kun med http
-
-
For gjennomsiktige proxyer må du bruke ruteren/svitsjen til å tvinge HTTPS/443-trafikk til å gå til proxyen. Du kan også tvinge websocket til å gå til proxy. (Web Socket bruker https.)
Videonett krever websocket-tilkoblinger til skytjenester, slik at nodene fungerer som de skal. Ved eksplisitte inspeksjons- og gjennomsiktige inspeksjons-proxyer kreves http-topptekster for en riktig websocket-tilkobling. Hvis de endres, vil websocket-tilkoblingen mislykkes.
Når websocket-tilkoblingsfeilen oppstår på port 443 (med gjennomsiktig inspeksjons-proxy aktivert), fører det til en advarsel etter registrering i Control Hub: «Webex-videonett SIP-anrop fungerer ikke som det skal.» Den samme alarmen kan oppstå av andre årsaker når proxy ikke er aktivert. Når websocket-topptekster blokkeres på port 443, flyter ikke medier mellom apper og SIP-klienter.
Hvis medier ikke flyter, skjer dette ofte når https-trafikk fra noden over port 443 mislykkes:
-
Port 443-trafikk er tillatt av proxyen, men det er en inspeksjons-proxy og bryter websocket.
For å løse disse problemene må du kanskje "omgå" eller "splitte" (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 inspeksjons-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 videonett for en oversikt over proxy-alternativene som støttes.
1 |
Skriv inn URL-adressen for oppsett av videonett | ||||||||||
2 |
Gå til Klareringslager og proxy, og velg deretter et alternativ:
Følg de neste trinnene for en gjennomsiktig inspeksjons- eller eksplisitt proxy. | ||||||||||
3 |
Klikk på Last opp et rotsertifikat eller sluttenhetssertifikat, og finn og velg rotsertifikatet for den eksplisitte eller gjennomsiktige inspeksjons-proxyen. Sertifikatet er lastet opp, men er ennå ikke installert fordi noden må startes på nytt for å installere sertifikatet. Klikk på 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 gjennomsiktige inspeksjons- eller eksplisitte proxyer, klikker du på Kontroller proxy-tilkobling for å teste nettverkstilkoblingen mellom videonettnoden og proxyen. Hvis tilkoblingstesten mislykkes, får du en feilmelding som viser årsaken og hvordan du kan løse problemet. | ||||||||||
5 |
Etter at tilkoblingstesten er bestått, for eksplisitt proxy, slår du veksleknappen til Rute alle port 443 https-forespørsler fra denne noden gjennom den eksplisitte proxyen. Denne innstillingen tar 15 sekunder før den trer i kraft. | ||||||||||
6 |
Klikk på Installer alle sertifikater i klareringslageret (vises når 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 noen få minutter. | ||||||||||
7 |
Etter at noden har startet på nytt, logger du på igjen om nødvendig og åpner deretter Oversikt -siden for å sjekke tilkoblingskontrollene for å sikre at alle er i grønn status. Proxy-tilkoblingskontrollen tester bare et underdomene av webex.com. Hvis det oppstår tilkoblingsproblemer, er et vanlig problem at noen av skydomenene som er oppført i installasjonsinstruksjonene, blokkeres ved proxyen. |
Hva trafikk går gjennom proxy
For videonett går ikke medier gjennom proxyen. Denne funksjonen sender signal- og administrasjonsbasert https-trafikk til proxyen. Du må fremdeles åpne de nødvendige portene for mediestrømmer for å nå skyen direkte.
TCP-port 444 er ikke aktivert på proxy
Denne porten er et krav for videonett, fordi videonett 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 distribusjonsveiledningen for videonett og nettverkskrav for Webex Teams-tjenester.
Filtrering av signaltrafikk via IP-adresse støttes ikke, da IP-adressene som brukes av løsningene våre er dynamiske og kan endres når som helst.
Ingen rotsertifikat er installert
Når nodene dine snakker med en eksplisitt proxy, må du installere rotsertifikatet og angi et unntak for URL-adressen på brannmuren.
Tilkoblingskontroll mislyktes
Hvis proxy-tilkoblingskontrollen er bestått og proxy-installasjonen er fullført, kan det hende at tilkoblingskontrollene på oversiktssiden fortsatt mislykkes av disse årsakene:
-
Proxyen inspiserer trafikk som ikke går til webex.com.
-
Proxyen blokkerer andre domener enn webex.com.
Godkjenningsdetaljene er feil
For proxyer som bruker en autentiseringsmekanisme, må du sørge for at du legger til de riktige autentiseringsdetaljene i noden.
Overbelastning på proxy
Overbelastning på proxyen din kan føre til forsinkelser og nedgang i trafikken til skyen. Sjekk proxy-miljøet 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-tilkoblinger (wss:
) som hybriddatasikkerhet krever. Disse delene gir veiledning om hvordan du konfigurerer forskjellige versjoner av Squid til å ignorere wss:
trafikk for riktig drift av tjenestene.
Squid 4 og 5
Legg til on_unsupported_protocol
direktivet i squid.conf
:
on_unsupported_protocol tunnel alle
Squid 3.5.27
Vi testet hybriddatasikkerhet 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-tilkobling ssl_bump splice wssMercuryConnection acl step1 at_step SslBump1 acl step2 at_step SslBump2 acl step3 at_step SslBump3 ssl_bump titte step1 alle ssl_bump stirre step2 alle ssl_bump bump step3 alle