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 med Cisco Webex-skyen.

Proxy-støtte

Hybriddatasikkerhet støtter eksplisitte, gjennomsiktige proxyer for inspeksjon og ikke-inspeksjon. 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 grensesnitt for plattformadministrasjon på nodene for sertifikatadministrasjon og 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 Klareringslager og proxy-konfigurasjon 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 trenge 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-konfigurasjon er nødvendig på nodene. Nodene trenger imidlertid et rotsertifikat slik at de klarerer proxyen. Inspeksjons-proxyer brukes vanligvis av IT til å håndheve retningslinjer 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).

  • Eksplisitt proxy – Med eksplisitt proxy forteller du HDS-nodene hvilken proxy-server og hvilken godkjenningsplan som skal brukes. Hvis du vil konfigurere en eksplisitt proxy, må du angi følgende informasjon for hver node:

    1. Proxy IP/FQDN – Adresse som kan brukes til å nå proxy-maskinen.

    2. Proxy-port – Et portnummer som proxyen bruker til å lytte etter proxy-trafikk.

    3. 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 godkjenner serverens sertifikat.

    4. 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 å angi 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 HTTPS eksplisitt inspeksjons-proxy-alternativer, må det samme rotsertifikatet være installert på proxyen og på nodene for hybriddatasikkerhet.

Blokkert ekstern DNS-oppløsningsmodus (eksplisitt proxy-konfigurasjoner)

Når du registrerer en node eller kontrollerer 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øsningsmodus hvis noden ikke kan spørre DNS-serverne. I denne modusen kan noderegistrering og andre proxy-tilkoblingstester fortsette.

Krav til proxy-server

  • Vi støtter offisielt følgende proxy-løsninger som kan integreres med nodene dine for hybriddatasikkerhet.

    • Gjennomsiktig proxy – Cisco Web Security Appliance (WSA).

    • Eksplisitt proxy – Squid.

      Squid-proxyer som inspiserer HTTPS-trafikk kan forstyrre etableringen av WebSocket (wss:) tilkoblinger. Hvis du vil omgå dette problemet, kan du se «WebSocket kan ikke kobles til via Squid-proxy» i Proxy-problemer.

  • Vi støtter følgende kombinasjoner av godkjenningstyper for eksplisitte proxyer:

    • Ingen godkjenning med HTTP eller HTTPS

    • Enkel godkjenning med HTTP eller HTTPS

    • Sammendragsgodkjenning kun med HTTPS

  • Hvis du vil ha en gjennomsiktig inspeksjons-proxy eller en eksplisitt HTTPS-proxy, må du ha en kopi av proxyens rotsertifikat. Distribusjonsinstruksjonene i denne håndboken beskriver hvordan du laster opp kopien til klareringslagrene for hybriddatasikkerhetsnoder.

  • 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 nettrafikk, kan forstyrre WebSocket-tilkoblinger. Hvis dette problemet oppstår, vil det å omdirigere (ikke inspisere) trafikk til wbx2.com, og ciscospark.com vil løse problemet.

Konfigurere HDS-noden for proxy-integrasjon

Hvis nettverksmiljøet krever en proxy, bruker du denne fremgangsmåten til å angi hvilken type proxy du vil integrere med hybriddatasikkerhet. Hvis du velger en gjennomsiktig 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 starter

1

Skriv inn URL-adressen for HDS-nodeoppsett https://[HDS Node IP or FQDN]/setup i en nettleser, angi administratorlegitimasjonen du har konfigurert for noden, og klikk deretter på Logg på.
2

Gå til Klareringslager og proxy, og velg deretter et alternativ:

  • Ingen proxy – Standardalternativet før du integrerer 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 trenge endringer for å fungere med en ikke-inspeksjons-proxy. Ingen sertifikatoppdatering er nødvendig.
  • Gjennomsiktig inspeksjons-proxy – Nodene er ikke konfigurert til å bruke en bestemt proxy-serveradresse. Ingen endringer i HTTPS-konfigurasjon er nødvendig for distribusjonen av hybriddatasikkerhet, men HDS-nodene trenger et rotsertifikat slik at de klarerer proxyen. Inspeksjons-proxyer brukes vanligvis av IT til å håndheve retningslinjer 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).
  • Eksplisitt proxy – Med eksplisitt proxy forteller du klienten (HDS-noder) hvilken proxy-server som skal brukes, og dette alternativet støtter flere godkjenningstyper. Når du har valgt dette alternativet, må du angi følgende informasjon:

    1. Proxy IP/FQDN – Adresse som kan brukes til å nå proxy-maskinen.

    2. Proxy-port – Et portnummer som proxyen bruker til å lytte etter proxy-trafikk.

    3. Proxy-protokoll – Velg http (viser og kontrollerer alle forespørsler som mottas fra klienten) eller https (gir en kanal til serveren, og klienten mottar og validerer serverens sertifikat). Velg et alternativ basert på hva proxy-serveren støtter.

    4. Godkjenningstype – Velg blant følgende godkjenningstyper:

      • Ingen – Ingen ytterligere godkjenning er nødvendig.

        Tilgjengelig for HTTP- eller HTTPS-proxyer.

      • Grunnleggende – Brukes for en HTTP-brukeragent til å angi brukernavn og passord når du foretar en forespørsel. Bruker Base64-koding.

        Tilgjengelig for HTTP- eller HTTPS-proxyer.

        Hvis du velger dette alternativet, må du også skrive inn brukernavn og passord.

      • 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 for HTTPS-proxyer.

        Hvis du velger dette alternativet, må du også skrive inn brukernavn og passord.

Følg de neste trinnene for en gjennomsiktig inspeksjons-proxy, en HTTP-eksplisitt proxy med enkel 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å vinkeltegnpilen 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 på Kontroller proxy-tilkobling for å teste nettverkstilkoblingen mellom noden og proxyen.

Hvis tilkoblingstesten mislykkes, ser du en feilmelding som viser årsaken og hvordan du kan løse problemet.

Hvis du får en melding om at den eksterne DNS-oppløsningen ikke var vellykket, kunne ikke noden nå DNS-serveren. Denne betingelsen forventes i mange eksplisitte proxy-konfigurasjoner. Du kan fortsette med oppsettet, og noden vil fungere. Hvis du tror dette er en feil, fullfører du disse trinnene. Deretter kan du slå av modusen. (Se Deaktiver blokkert modus for ekstern DNS-oppløsning.)
5

Etter at tilkoblingstesten blir bestått, kun for eksplisitt proxy satt til https, setter du veksleknappen til Rute alle port 443/444 https-forespørsler fra denne noden gjennom den eksplisitte proxyen. Denne innstillingen trer i kraft etter 15 sekunder.
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 HTTP-eksplisitt proxy), les ledeteksten, og klikk deretter på Installer hvis du er klar.

Noden starter på nytt i løpet av noen få minutter.
7

Når noden har startet på nytt, logger du på igjen om nødvendig, og deretter åpner du Oversikt-siden for å kontrollere tilkoblingskontrollene for å sikre at alle har 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 nå?

Gjenta proxy-konfigurasjonen for hver node i klyngen for hybriddatasikkerhet.

Deaktiver blokkert ekstern DNS-oppløsningsmodus

Når du registrerer en node eller kontrollerer 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 modusen blokkert ekstern DNS-oppløsning.

Hvis nodene kan løse offentlige DNS-navn via interne DNS-servere, kan du deaktivere denne modusen ved å kjøre proxy-tilkoblingstesten på nytt på hver node.

Før du starter

Kontroller at de interne DNS-serverne kan løse offentlige DNS-navn, og at nodene kan kommunisere med dem.

1

Åpne nodegrensesnittet for hybriddatasikkerhet i en nettleser (IP-adresse/-oppsett, for eksempel https://192.0.2.0/setup),angi administratorlegitimasjonen du konfigurerte 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 får en melding om at den eksterne DNS-oppløsningen ikke var vellykket, kunne ikke noden nå DNS-serveren og den vil forbli i denne modusen. Ellers, etter at du har startet noden på nytt og gått tilbake til Oversikt-siden, bør Blokkert ekstern DNS-oppløsning settes til Nei.

Hva nå?

Gjenta proxy-tilkoblingstesten for hver node i klyngen for hybriddatasikkerhet.

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 med Cisco Webex-skyen.

Proxy-støtte for Cisco Webex-videonett

Cisco Webex-videonett støtter eksplisitte, gjennomsiktige inspeksjons- og ikke-inspeksjons-proxyer. Du kan knytte disse proxyene til distribusjonen av Webex-videonett 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 Webex-videonett til sertifikatadministrasjon og den generelle tilkoblingsstatusen etter at du har implementert proxyen med nodene.

Medier beveger seg ikke gjennom proxyen. Du må fremdeles åpne de nødvendige portene for mediestrømmer for å nå skyen direkte.

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 å angi 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. Denne godkjenningsplanen krever flere utvekslinger for å fullføre. (For eksplisitt HTTP-proxy.)

  • Gjennomsiktig proxy (ikke-inspeksjon) – Noder for videonett er ikke konfigurert til å bruke en bestemt proxy-serveradresse, og bør ikke trenge 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 for å kunne klarere proxyen. Inspeksjons-proxyer brukes vanligvis av IT til å håndheve retningslinjer 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).

Figur 1. Eksempel på noder og proxyer for Webex-videonett.

Dette diagrammet viser en eksempelkobling mellom Webex-videonett, nettverk og en proxy. For gjennomsiktig inspeksjons- og eksplisitt inspeksjons-proxy-alternativer, må det samme rotsertifikatet være installert på proxyen og på nodene for videonett.

Krav til proxy-støtte for Webex-videonett

  • Vi støtter offisielt følgende proxy-løsninger som kan integreres med nodene dine for Webex-videonett.

    • 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 nodeklareringslageret for Webex-videonett på nettgrensesnittet.

  • Vi støtter følgende eksplisitte kombinasjoner av proxy- og godkjenningstyper:

    • Ingen godkjenning med http og https

    • Enkel godkjenning med http og https

    • Sammendragsgodkjenning kun med https

    • NTLM-godkjenning kun med http

  • For gjennomsiktige proxyer må du bruke ruteren/bryteren til å tvinge HTTPS/443-trafikk til å gå til proxyen. Du kan også tvinge Web Socket/444 til å gå til proxy. (Web Socket bruker https.) Port 444 avhenger av nettverksoppsettet. Hvis port 444 ikke rutes gjennom proxyen, må den være åpen direkte fra noden til skyen.

    Webex-videonett krever websocket-tilkoblinger til skytjenester for at nodene skal fungere som de skal. Ved eksplisitte inspeksjons- og gjennomsiktige inspeksjons-proxyer endres HTTP-overskrifter som kreves for en riktig websocket-tilkobling, og websocket-tilkoblinger mislykkes.

    Symptomet når dette skjer på port 443 (med gjennomsiktig inspeksjons-proxy aktivert) er en advarsel etter registrering i Control Hub: «SIP-anrop for Webex-videonett fungerer ikke som det skal.» Den samme alarmen kan oppstå av andre årsaker når proxy ikke er aktivert. Når websocket-overskrifter 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 444 eller port 443 mislykkes:

    • Proxy inspiserer ikke, men port 444-trafikk er ikke tillatt av proxyen.

    • Trafikk over port 443 eller port 444 er tillatt av proxyen, men det er en inspeksjons-proxy og bryter websocket.

    For å løse disse problemene, kan det hende du må omgå eller skjøte (deaktivere inspeksjon) på portene 444 og 443 til: *.wbx2.com og *.ciscospark.com.

Konfigurere node for Webex-videonett for proxy-integrasjon

Bruk denne fremgangsmåten til å angi hvilken type proxy du vil integrere med et Webex-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 potensielle problemer.

Før du starter

1

Skriv inn URL-adressen for oppsett av Webex-videonetthttps://[IP eller FQDN/setup i en nettleser, angi administratorlegitimasjonen du har konfigurert for noden, og klikk på Logg på.
2

Gå til Klareringslager og proxy, og velg deretter et alternativ:

  • Ingen proxy – Standardalternativet før du integrerer en proxy. Ingen sertifikatoppdatering er nødvendig.
  • Gjennomsiktig ikke-inspeksjons-proxy – Nodene for videonett er ikke konfigurert til å bruke en bestemt proxy-serveradresse, og bør ikke trenge endringer for å fungere med en ikke-inspeksjons-proxy. Ingen sertifikatoppdatering er nødvendig.
  • Gjennomsiktig inspeksjons-proxy – Nodene 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 for å kunne klarere proxyen. Inspeksjons-proxyer brukes vanligvis av IT til å håndheve retningslinjer 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).
  • Eksplisitt proxy – Med eksplisitt proxy forteller du klienten (videonett-noder) hvilken proxy-server som skal brukes, og dette alternativet støtter flere godkjenningstyper. Når du har valgt dette alternativet, må du angi følgende informasjon:

    1. Proxy IP/FQDN – Adresse som kan brukes til å nå proxy-maskinen.

    2. Proxy-port – Et portnummer som proxyen bruker til å lytte etter proxy-trafikk.

    3. Proxy-protokoll – Velg http (videonett tunnelerer https-trafikken gjennom http-proxyen) eller https (trafikk fra videonettnoden til proxyen bruker https-protokollen). Velg et alternativ basert på hva proxy-serveren støtter.

    4. Velg mellom følgende godkjenningstyper, avhengig av proxy-miljøet:

      Alternativ

      Bruk

      Ingen

      Velg for eksplisitte HTTP- eller HTTPS-proxyer der det ikke finnes noen godkjenningsmetode.

      Grunnleggende

      Tilgjengelig for eksplisitte HTTP- eller HTTPS-proxyer.

      Brukes for en HTTP-brukeragent til å angi brukernavn og passord når du foretar en forespørsel, og bruker Base64-koding.

      Sammendrag

      Kun tilgjengelig for eksplisitte HTTPS-proxyer.

      Brukes til å bekrefte kontoen før sensitiv informasjon sendes, og bruker en hash-funksjon på brukernavnet og passordet før det sendes over nettverket.

      NTLM

      Kun tilgjengelig for eksplisitte HTTP-proxyer.

      Det brukes på samme måte som sammendrag til å bekrefte kontoen før sensitiv informasjon sendes. Bruker Windows-legitimasjon i stedet for brukernavn og passord.

      Hvis du velger dette alternativet, angir du Active Directory-domenet som proxyen bruker til godkjenning, i NTLM-domenefeltet. Skriv inn navnet på proxy-arbeidsstasjonen (også kalt en arbeidsstasjonskonto eller maskinkonto) i det angitte NTLM-domenet i feltet NTLM-arbeidsstasjon.

Følg de neste trinnene for en gjennomsiktig inspeksjons-proxy eller eksplisitt proxy.
3

Klikk på Last opp et rotsertifikat eller sluttenhetssertifikat, og deretter 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å flere detaljer, eller klikk på Slett hvis du har gjort en feil og vil laste opp filen på nytt.
4

Hvis du vil ha gjennomsiktige inspeksjons-proxyer eller eksplisitte proxyer, klikker du på Kontroller proxy-tilkobling for å teste nettverkstilkoblingen mellom videonettnoden og proxyen.

Hvis tilkoblingstesten mislykkes, ser du en feilmelding som viser årsaken og hvordan du kan løse problemet.
5

Etter at tilkoblingstesten blir bestått, for eksplisitt proxy, setter du veksleknappen til Rute alle port 443/444 https-forespørsler fra denne noden gjennom den eksplisitte proxyen. Denne innstillingen trer i kraft etter 15 sekunder.
6

Klikk på Installer alle sertifikater i klareringslageret (vises hver gang et rotsertifikat ble lagt til under proxy-installasjonen) 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 i løpet av noen få minutter.
7

Når noden har startet på nytt, logger du på igjen om nødvendig, og deretter åpner du Oversikt-siden for å kontrollere tilkoblingskontrollene for å sikre at alle har 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.

Proxy-problemer

Hva trafikken 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 som den skal. Det må gjøres et proxy-unntak for denne porten som dokumentert i distribusjonsveiledningen for videonett og nettverkskravene 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 kommuniserer med en eksplisitt proxy, må du installere rotsertifikatet og angi et unntak for denne URL-adressen i brannmuren.

Feil med tilkoblingskontroll

Hvis proxy-tilkoblingskontrollen ble godkjent og proxy-installasjonen ble fullført, kan det hende at det fremdeles oppstod feil med tilkoblingskontrollene på oversiktssiden 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 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 nedgang for trafikk til skyen. Kontroller 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 (wss:) tilkoblinger som hybriddatasikkerhet og Webex-videonett krever. Det kan hende du ser en rekke advarsler i loggene, for eksempel «Kobler til WebSocket på nytt …» når en node prøver å nå Webex-skyen. Prøv følgende Squid-konfigurasjon, avhengig av din versjon av Squid, for å få proxyen til å ignorere wss: trafikk for riktig drift.

Squid 4 og 5

Legg til on_unsupported_protocol direktivet til squid.conf:

on_unsupported_protocol tunnel all

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-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

Vi testet videonett med følgende regler lagt til i squid.conf. (Videonett krever to ekstra tilgangskontrollister sammenlignet med hybriddatasikkerhet.) Disse reglene kan endres etter hvert som vi utvikler funksjoner og oppdaterer Webex-skyen.

acl wssMercuryConnection ssl::server_name_regex mercury-connection
acl ciscoCloud1 ssl::server_name .wbx2.com
acl ciscoCloud2 ssl::server_name .ciscospark.com

ssl_bump splice wssMercuryConnection
ssl_bump splice ciscoCloud1
ssl_bump splice ciscoCloud2

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