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

Disse punktene er avgjørende hvis du vil distribuere Hybrid Calling for Webex-enheter på en vellykket måte. Vi har spesielt fremhevet disse elementene av følgende grunner:

• Vi ønsker å forklare dem, slik at du forstår deres rolle i en hybridutrulling 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 dagens nullpunkt: De kan ta litt lengre tid å fullføre enn vanlig konfigurasjon i et brukergrensesnitt, så beregn en tidsramme for å få ordnet disse elementene.

• Etter at disse punktene er adressert i miljøet ditt, vil resten av konfigurasjonen av hybridtjenester gå knirkefritt.

Distribusjonen av Expressway-C og Expressway-E-par tillater anrop til og fra Internett ved hjelp av brannmurtraverseringsteknologier. Denne distribusjonen er det som sikkert tar din lokale samtalekontroll og kobler den til Webex.

Expressway-C og Expressway-E krever ikke at noen innkommende port åpnes i brannmuren for demilitarisert sone (DMZ) på grunn av brannmurens traverseringsarkitektur. Men TCP SIP-signalporter og UDP-medieporter må åpnes innkommende på Internett-brannmuren for å slippe innkommende anrop gjennom. Du må gi den nødvendige porten tid til å åpne den på bedriftens brannmur.

Brannmurens traverseringsarkitektur er vist i følgende diagram:

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

Du kan konfigurere SIP-lytteporten på Expressway til å være 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 antar vi at port 5062 brukes til innkommende SIP TLS-anrop.

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

_sips._tcp.example.com SRV-tjenestelokasjon:

prioritet = 10

vekt = 10

havn = 5062

svr-vertsnavn = us-expe1.example.com

_sips._tcp.example.com SRV-tjenestelokasjon:

prioritet = 10

vekt = 10

havn = 5062

svr-vertsnavn = us-expe2.example.com

Disse postene betyr at anrop blir dirigert til us-expe1.example.com og us-expe2.example.com med lik lastdeling (prioritet og vekt) ved bruk av TLS som transporttype og 5062 som lytteportnummer.

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

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

TLS er en klient-server-protokoll, og i de vanligste implementeringene bruker den sertifikater for autentisering. I et bedrift-til-bedrift-anropsscenario er TLS-klienten den anropende enheten, og TLS-serveren er den anropte enheten. Med TLS sjekker klienten serverens sertifikat, og hvis sertifikatkontrollen mislykkes, kobles anropet fra. Klienten trenger ikke et sertifikat.

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

TLS-spesifikasjonen sier imidlertid at serveren også kan sjekke klientsertifikatet ved å sende en sertifikatforespørsel 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 autentisering og er nødvendig ved integrering med Webex.

Både den anropende og den anropte parten sjekker sertifikatet til den andre motparten, som følgende diagram viser:

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

Hvis gjensidig autentisering er aktivert, ber Expressway-E alltid om klientsertifikatet. Som et resultat vil ikke mobil og fjerntilgang (MRA) fungere, fordi sertifikater i de fleste tilfeller ikke distribueres på Jabber-klienter. I et bedrift-til-bedrift-scenario, blir samtalen frakoblet hvis den anropende enheten ikke kan levere et sertifikat.

Vi anbefaler at du bruker en annen verdi enn 5061 for TLS med gjensidig autentisering, for eksempel port 5062. Webex Hybrid Services bruker den samme SIP TLS-posten som brukes for B2B. Når det gjelder port 5061, vil ikke noen andre tjenester som ikke kan tilby et TLS-klientsertifikat fungere.

Hvis en eksisterende oppføring allerede brukes til 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:

 Service and protocol: _sips._tcp.mtls.example.com 
Priority: 1 
Weight: 10 
Port number: 5062 
Target: us-expe1.example.com 

Bedrift-til-bedrift, mobil og ekstern tilgang og Webex-trafikk på samme Expressway-par

Bedrifts-til-bedrift (B2B) og mobil- og fjerntilgangsanrop (MRA) bruker port 5061 for SIP TLS, og Webex-trafikk bruker port 5062 for SIP TLS med gjensidig autentisering.

Domeneeierskapssjekken er en del av identitetsverifiseringen. Domeneverifisering er et sikkerhetstiltak og en identitetskontroll som Webex Cloud implementerer for å bevise at du er den du sier du er.

Identitetskontrollen utføres i to trinn:

1. Sjekk av domeneeierskap. Dette trinnet involverer tre typer domener og er en engangsverifiseringssjekk:

   • E-postdomene

   • Expressway-E DNS-domene

   • Katalog-URI-domene

2. Sjekk av eierskap for Expressway-E DNS-navn. Dette trinnet utføres gjennom implementering av TLS med gjensidig autentisering og involverer bruk av offentlige sertifikater både i skyen og på Expressway. I motsetning til domeneidentitetssjekken utføres dette trinnet under alle anrop som foretas til og mottas fra skyen.

Viktigheten av å sjekke eierskapet til domenet

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

Følgende historie beskriver hva som kan skje hvis en eierskapssjekk for domenet ikke utføres.

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

Administratoren til Hacker.com-selskapet setter 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 seg på Webex-appen med jane.roe@hacker.com. Fordi hun eier domenet, blir bekreftelses-e-posten lest og besvart, og hun kan logge inn. Til slutt ringer hun til en kollega, John Doe, ved å taste inn john.doe@example.com fra Webex-appen hennes. John sitter på kontoret sitt og ser en samtale på videoenheten sin komme 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 er på reise, ber hun ham om å sende dokumentene til hennes 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 har blitt lekket utenfor selskapet.

Selskapet Example.com har mange måter å beskytte seg mot uredelige anrop som kommer fra Internett, men en av Webex-skyens oppgaver er å sørge for at identiteten til alle som ringer fra Webex er korrekt og ikke forfalsket.

For å sjekke identiteten krever Webex at selskapet beviser at det eier domenene som brukes i Hybrid Calling. Hvis ikke, vil ikke hybridtjenester fungere.

For å sikre dette eierskapet kreves to domeneverifiseringstrinn:

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

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

   • For å bevise eierskapet må DNS-administratoren legge inn en DNS-tekstoppføring (TXT). En TXT-post er en type ressurspost i DNS som brukes til å gi muligheten til å knytte vilkårlig og uformatert tekst til en vert eller et annet navn.

   • DNS-administratoren må legge inn den TXT-oppføringen i sonen hvis eierskap må bevises. Etter dette trinnet utfører Webex-skyen en TXT-postforespørsel for det domenet.

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

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

   • Gjennom https://admin.webex.comstarter hun bekreftelsesprosessen ved å opprette en TXT-oppføring 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 denne treffingen at administratoren la til TXT-posten for sitt eget domene i den offentlige DNS-en, og at hun eier domenet.

2. Sjekk av eierskap for Expressway-E DNS-navn.

   • Skyen må sjekke at Expressway-E har en bekreftet identitet fra en av sertifiseringsinstansene som skyen stoler på. Expressway-E-administratoren må be om et offentlig sertifikat for sin Expressway-E til en av disse sertifiseringsinstansene. For å utstede sertifikatet utfører sertifikatmyndigheten en identitetsverifiseringsprosess, basert på en domenevalideringssjekk (for domenevaliderte sertifikater) eller organisasjonsvalideringssjekk (for organisasjonsvaliderte sertifikater).

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

Webex-enhetskoblingen må kommunisere med Webex for at hybridanrop skal fungere.

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

Kommunikasjon til Webex-skyen bruker TLS. Webex Device Connector er TLS-klienten, og Webex Cloud er TLS-serveren. Som sådan sjekker Webex Device Connector serversertifikatet.

Sertifiseringsinstansen signerer et serversertifikat med sin egen private nøkkel. Alle med den offentlige nøkkelen kan dekode signaturen og bevise at den samme sertifiseringsinstansen signerte sertifikatet.

Hvis Webex Device Connector må validere sertifikatet levert av skyen, må den bruke den offentlige nøkkelen til sertifiseringsinstansen som signerte sertifikatet for å dekode signaturen. En offentlig nøkkel finnes i sertifikatet til sertifiseringsinstansen. For å etablere tillit med sertifikatmyndighetene som brukes av skyen, må listen over sertifikater for disse klarerte sertifikatmyndighetene være i Webex Device Connector-tillitslageret.

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

En liste over sertifikatutstedersertifikater er også nødvendig for Expressway-E i traversalparet. Expressway-E kommuniserer med Webex-skyen ved hjelp av SIP med TLS, håndhevet av gjensidig autentisering. Expressway-E stoler bare på anrop som kommer fra og går til skyen hvis CN- eller SAN-navnet til 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 utsteder kun et sertifikat etter en identitetskontroll. Eierskapet til domenet callservice.webex.com må bevises for å få et sertifikat signert. Fordi vi (Cisco) eier det domenet, er DNS-navnet «callservice.webex.com» et direkte bevis på at den eksterne motparten virkelig er Webex.

Kalenderkoblingen integrerer Webex med Microsoft Exchange 2013, 2016, 2019 eller Office 365 gjennom en representasjonskonto. Rollen for administrasjon av programrepresentasjon i Exchange lar programmer representere brukere i en organisasjon for å utføre oppgaver på vegne av brukeren. Programrepresentasjonsrollen må konfigureres i Exchange og brukes i kalenderkoblingen som en del av Exchange-konfigurasjonen på Expressway-C-grensesnittet.

Exchange-etterligningskontoen 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 root-tilgang til Expressway-C-boksen. Passordet lagres kryptert med samme krypteringsmekanisme for påloggingsinformasjon som andre passord på Expressway-C.

For ekstra sikkerhet, følg trinnene i distribusjonsveiledningen for Cisco Webex Hybrid Calendar Service for å aktivere TLS for å sikre EWS-tilkoblinger på ledningen.

For ekstra sikkerhet, følg trinnene i Distribuer Expressway Calendar Connector for Microsoft Exchange for å aktivere TLS for å sikre EWS-tilkoblinger på kabelen.