Denne delen gir ekstra kontekst om viktige konfigurasjonselementer som er relatert til hybridtjenester.

Disse punktene er avgjørende hvis du vil distribuere hybridsamtaler for Webex-enheter. Vi har fremhevet disse elementene av følgende årsaker:

• Vi vil forklare dem slik at du forstår deres rolle i en hybriddistribusjon og føler deg trygg.

• De er obligatoriske forutsetninger som sikrer en sikker distribusjon mellom skyen vår og ditt lokale miljø.

• De bør behandles som aktiviteter før dag null: de kan ta litt lengre tid å fullføre enn vanlig konfigurasjon i et brukergrensesnitt, så gi en tidsramme for å få disse elementene sortert.

• Når disse elementene er håndtert i miljøet ditt, vil resten av konfigurasjonen av hybridtjenester gå problemfritt.

Distribusjon av Expressway-C- og Expressway-E-par tillater anrop til og fra Internett ved hjelp av teknologier for brannmurtraversering. Denne distribusjonen tar den lokale samtalekontrollen din trygt og knytter den til Webex.

Expressway-C og Expressway-E krever ikke at noen innkommende port åpnes i den demilitariserte sonen (DMZ) på grunn av brannmurtraverseringsarkitekturen. Men TCP SIP-signalporter og UDP-medieporter må åpnes innkommende på Internett-brannmuren for å la innkommende anrop komme gjennom. Du må gi tid til å få den riktige porten åpnet på bedriftens brannmur.

Arkitekturen for brannmurtraversering er vist i følgende diagram:

For innkommende bedrift-til-bedrift-anrop (B2B) som bruker SIP-protokollen, må for eksempel TCP-portene 5060 og 5061 (5061 brukes til SIP TLS) åpnes på den eksterne brannmuren, sammen med UDP-medieportene som brukes til tjenester som tale, video, innholdsdeling, dobbel video osv. Hvilke medieporter som skal åpnes, avhenger av antall samtidige anrop og antall tjenester.

Du kan konfigurere SIP-lytteporten på Expressway til en hvilken som helst verdi mellom 1024 og 65534. Samtidig må denne verdien og protokolltypen annonseres i de offentlige DNS SRV-oppføringene, og den samme verdien må åpnes på Internett-brannmuren.

Selv om standarden for SIP TCP er 5060 og for SIP TLS 5061, er det ingenting som hindrer bruk av forskjellige porter, som eksemplet nedenfor viser.

Eksempel

I dette eksemplet forutsetter vi at port 5062 brukes for innkommende SIP TLS-anrop.

DNS SRV-oppføringen for en klynge med to Expressway-servere ser slik ut:

_sips._tcp.example.com SRV-tjenestested:

prioritet = 10

vekt = 10

port = 5062

svr vertsnavn = us-expe1.example.com

_sips._tcp.example.com SRV-tjenestested:

prioritet = 10

vekt = 10

port = 5062

svr vertsnavn = us-expe2.example.com

Disse oppføringene betyr at anrop sendes til us-expe1.example.com og us-expe2.example.com med lik belastningsdeling (prioritet og vekt) ved hjelp av TLS som transporttype og 5062 som lytteportnummer.

En enhet som er ekstern for nettverket (på Internett) og som foretar et SIP-anrop til en bruker av bedriftsdomenet (user1@example.com), må spørre DNS for å forstå hvilken type transport som skal brukes, portnummeret, hvordan trafikken skal lastes inn og hvilke SIP-servere samtalen skal sendes til.

Hvis DNS-oppføringen inneholder _sips._tcp, angir oppføringen SIP TLS.

TLS er en klient-server-protokoll og bruker i de vanligste implementeringene sertifikater til godkjenning. I et business-to-business-anropsscenario er TLS-klienten oppringingsenheten, og TLS-serveren er den oppringte enheten. Med TLS kontrollerer klienten sertifikatet til serveren, og hvis sertifikatkontrollen mislykkes, kobler den fra samtalen. Klienten trenger ikke et sertifikat.

TLS-håndtrykk vises i følgende diagram:

TLS-spesifikasjonen angir imidlertid at serveren også kan sjekke klientsertifikatet ved å sende en sertifikatforespørselsmelding til klienten under TLS-håndtrykkprotokollen. Denne meldingen er nyttig på en server-til-server-tilkobling, for eksempel på en samtale som opprettes mellom Expressway-E og Webex-skyen. Dette konseptet kalles TLS med gjensidig godkjenning og kreves ved integrering med Webex.

Både de som ringer og de som ringer, kontrollerer sertifikatet til den andre motparten, som følgende diagram viser:

Skyen kontrollerer Expressway-identiteten, og Expressway kontrollerer skyidentiteten. Hvis for eksempel skyidentiteten i sertifikatet (CN eller SAN) ikke samsvarer med det som er konfigurert på Expressway, blir tilkoblingen avbrutt.

Hvis gjensidig godkjenning er slått på, ber Expressway-E alltid om klientsertifikatet. Som et resultat vil ikke Mobile and Remote Access (MRA) fungere, fordi sertifikater i de fleste tilfeller ikke distribueres på Jabber-klienter. I et bedrift-til-bedrift-scenario, hvis den oppringende enheten ikke kan oppgi et sertifikat, kobles samtalen fra.

Vi anbefaler at du bruker en annen verdi enn 5061 for TLS med gjensidig godkjenning, for eksempel port 5062. Webex-hybridtjenester bruker den samme SIP TLS-posten som brukes for B2B. I tilfelle port 5061, vil noen andre tjenester som ikke kan tilby et TLS-klientsertifikat, ikke fungere.

Hvis en eksisterende oppføring allerede brukes for bedrift-til-bedrift-kommunikasjon, anbefaler vi at du angir et underdomene av bedriftsdomenet som SIP-destinasjon i Control Hub, og dermed en offentlig DNS SRV-oppføring, som følger:

 Tjeneste og protokoll: _sips._tcp.mtls.example.com Prioritet: 1 Vekt: 10 Portnummer: 5062 Mål: us-expe1.example.com 

Bedrift-til-bedrift, Mobile and Remote Access og Webex-trafikk på samme Expressway-par

Bedrift-til-bedrift-anrop (B2B) og Mobile and Remote Access (MRA) bruker port 5061 for SIP TLS, og Webex-trafikk bruker port 5062 for SIP TLS med gjensidig godkjenning.

Domeneeierskapet er en del av identitetsbekreftelsen. Domeneverifisering er et sikkerhetstiltak og identitetskontroll som Webex-skyen implementerer for å bevise at du er den du sier du er.

Identitetskontrollen utføres i to trinn:

1. Kontroll av domeneeierskap. Dette trinnet involverer tre typer domener og er en engangsbekreftelseskontroll:

   • E-postdomene

   • Expressway-E DNS-domene

   • Katalog-URI-domene

2. Kontroll av eierskap av DNS-navn for Expressway-E. Dette trinnet utføres gjennom implementering av TLS med gjensidig godkjenning og involverer bruk av offentlige sertifikater på både skyen og Expressway. I motsetning til domeneidentitetskontrollen utføres dette trinnet under alle samtaler som gjøres til og mottas fra skyen.

Viktigheten av domeneeierskap

Webex-skyen utfører domeneeierskapskontrollen for å håndheve sikkerheten. Identitetstyveri er en mulig trussel hvis denne kontrollen ikke utføres.

Følgende historie beskriver hva som kan skje hvis en domeneeierkontroll ikke utføres.

Et selskap med DNS-domene satt til «hacker.com» kjøper Webex-hybridtjenester. Et annet selskap, med sitt eget domene satt til "example.com", bruker også hybridtjenester. En av de overordnede lederne i selskapet Example.com heter Jane Roe og har katalog-URI-en jane.roe@example.com.

Administratoren for selskapet Hacker.com angir en av katalog-URI-ene sine til jane.roe@example.com og e-postadressen til jane.roe@hacker.com. Hun kan gjøre det fordi skyen ikke sjekker SIP URI-domenet i dette eksemplet.

Deretter logger hun på Webex-appen med jane.roe@hacker.com. Fordi hun eier domenet, leses og besvares bekreftelses-e-posten, og hun kan logge på. Til slutt ringer hun en kollega, John Doe, ved å ringe john.doe@example.com fra Webex-appen. John sitter på kontoret sitt og ser en samtale på videoenheten sin fra jane.roe@example.com. Det er katalog-URI-en som er knyttet til den e-postkontoen.

"Hun er i utlandet," tenker han. "Hun trenger kanskje noe viktig." Han svarer på telefonen, og den falske Jane Roe ber om viktige dokumenter. Hun forklarer at enheten hennes er ødelagt, og fordi hun reiser, ber hun ham om å sende dokumentene til sin private e-postadresse, jane.roe@hacker.com. På denne måten innser selskapet først etter at Jane Roe kommer tilbake til kontoret at viktig informasjon ble lekket utenfor selskapet.

Selskapet Example.com har mange måter å beskytte mot falske anrop som kommer fra Internett, men et av Webex-skyens ansvar er å sørge for at identiteten til alle som ringer fra Webex, er riktig og ikke forfalsket.

For å kontrollere identiteten krever Webex at selskapet beviser at det eier domenene som brukes i Hybrid Calling. Hvis den ikke gjør det, vil ikke hybridtjenestene fungere.

For å sikre dette eierskapet kreves de to trinnene for domeneverifisering:

1. Bevis at selskapet eier e-postdomenet, Expressway-E-domenet, katalog-URI-domenet.

   • Alle disse domenene må være ruterbare og kjent av offentlige DNS-servere.

   • DNS-administratoren må angi en DNS-tekstpost (TXT) for å bevise eierskapet. En TXT-post er en type ressurspost i DNS som brukes til å gi mulighet til å knytte vilkårlig og uformatert tekst til en vert eller et annet navn.

   • DNS-administratoren må angi TXT-posten i sonen der eierskapet må bevises. Etter dette trinnet utfører Webex-skyen en TXT-registreringsforespørsel for dette domenet.

   • Hvis TXT-spørringen er vellykket og resultatet samsvarer med tokenet som ble generert fra Webex-skyen, bekreftes domenet.

   • Som et eksempel må administratoren bevise at hun eier domenet «example.com», hvis hun vil at Webex-hybridtjenester skal fungere på domenet sitt.

   • Gjennom https://admin.webex.com starter hun verifiseringsprosessen ved å opprette en TXT-post som samsvarer med tokenet som Webex-skyen genererte:

     

   • DNS-administratoren oppretter deretter en TXT-post for dette domenet med verdien satt til 123456789abcdef123456789abcdef123456789abcdef123456789abcdef, som i følgende eksempel:

     

   • På dette tidspunktet kan skyen bekrefte at TXT-posten for domenet example.com samsvarer med tokenet.

   • Skyen utfører et TXT DNS-oppslag:

     

   • Fordi TXT-verdien samsvarer med tokenverdien, beviser dette samsvaret at administratoren har lagt til TXT-posten for sitt eget domene i den offentlige DNS-en, og at hun eier domenet.

2. Kontroll av eierskap av Expressway-E DNS-navn.

   • Skyen må kontrollere at Expressway-E har en bekreftet identitet fra en av sertifikatmyndighetene som skyen stoler på. Expressway-E-administratoren må be om et offentlig sertifikat for sin Expressway-E til en av disse sertifikatmyndighetene. Sertifikatmyndigheten utfører en identitetsbekreftelsesprosess basert på domenevalideringskontroll (for domenevaliderte sertifikater) eller organisasjonsvalideringskontroll (for organisasjonsvaliderte sertifikater) for å utstede sertifikatet.

   • Anrop til og fra skyen avhenger av sertifikatet som ble utstedt til Expressway-E. Hvis sertifikatet ikke er gyldig, blir samtalen avbrutt.

Webex Device Connector må kommunisere med Webex for at hybridsamtaler skal fungere.

Webex Enhetskobler distribueres i det interne nettverket, og måten den kommuniserer med skyen på, er gjennom en utgående HTTPS-tilkobling – samme type som brukes for alle nettlesere som kobler til en webserver.

Kommunikasjon til Webex-skyen bruker TLS. Webex Enhetskobler er TLS-klienten, og Webex-skyen er TLS-serveren. Dermed kontrollerer Webex Device Connector serversertifikatet.

Sertifikatmyndigheten signerer et serversertifikat ved hjelp av sin egen private nøkkel. Alle med den offentlige nøkkelen kan dekode signaturen og bevise at den samme sertifikatmyndigheten signerte sertifikatet.

Hvis Webex Device Connector må validere sertifikatet som ble levert av skyen, må den offentlige nøkkelen til sertifikatmyndigheten som signerte sertifikatet, brukes til å dekode signaturen. Sertifikatet til sertifiseringsinstansen inneholder en offentlig nøkkel. For å etablere klarering med sertifikatmyndighetene som brukes av skyen, må listen over sertifikater for disse klarerte sertifikatmyndighetene være i klareringslageret for Webex Device Connector.

Når verktøyet kommuniserer med enheter, bruker det klarerte sertifikater du oppgir. For øyeblikket er måten å gjøre det på ved å plassere dem i [home folder]/.devicestool/certs.

En liste over sertifikater fra sertifikatmyndigheter kreves også for Expressway-E i traverseringsparet. Expressway-E kommuniserer med Webex-skyen ved hjelp av SIP med TLS, håndhevet ved gjensidig godkjenning. Expressway-E klarerer samtaler som kommer fra og går til skyen, bare hvis CN eller SAN for sertifikatet som presenteres av skyen under oppsettet av TLS-tilkoblingen samsvarer med emnenavnet som er konfigurert for DNS-sonen på Expressway («callservice.webex.com»). Sertifiseringsinstansen frigir bare et sertifikat etter en identitetskontroll. Eierskapet til domenet callservice.webex.com må bevises for å få et sertifikat signert. Fordi vi (Cisco) eier dette domenet, er DNS-navnet «callservice.webex.com» direkte bevis på at den eksterne motparten virkelig er Webex.

kalendertilkobling integrerer Webex med Microsoft Exchange 2013, 2016, 2019 eller Office 365 gjennom en representasjonskonto. Administrasjonsrollen for programrepresentasjon i Exchange gjør det mulig for programmer å representere brukere i en organisasjon for å utføre oppgaver på vegne av brukeren. Programrepresentasjonsrollen må konfigureres i Exchange og brukes i kalendertilkoblingen som en del av Exchange-konfigurasjonen på Expressway-C-grensesnittet.

Exchange-representasjonskontoen er Microsofts anbefalte metode for denne oppgaven. Expressway-C-administratorer trenger ikke å vite passordet, fordi verdien kan angis i Expressway-C-grensesnittet av en Exchange-administrator. Passordet vises ikke tydelig, selv om Expressway-C-administratoren har rottilgang til Expressway-C-boksen. Passordet lagres kryptert ved hjelp av samme krypteringsmekanisme som andre passord på Expressway-C.

Hvis du vil ha mer sikkerhet, følger du fremgangsmåten i distribusjonsveiledningen for Cisco Webex-hybridkalendertjeneste for å aktivere TLS for å sikre EWS-tilkoblinger på ledningen.

Hvis du vil ha mer sikkerhet, følger du fremgangsmåten i Distribuer Expressway-kalendertilkobling for Microsoft Exchange for å aktivere TLS for å sikre EWS-tilkoblinger på ledningen.