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

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

• Vi ønsker å forklare dem, slik at du forstår deres rolle i en hybrid distribusjon 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 null-aktiviteter før dagen: de kan ta litt lengre tid å fullføre enn typisk konfigurasjon i et brukergrensesnitt, så tillat en tidsramme for å få disse elementene sortert.

• Etter at disse elementene er adressert i miljøet ditt, vil resten av Hybrid Services-konfigurasjonen gå greit.

Expressway-C- og Expressway-E- pardistribusjonen tillater samtaler til og fra Internett ved hjelp av brannmurkryssingsteknologier. Denne distribusjonen er det som sikkert tar den lokale samtalekontrollen din og knytter den til Webex.

Expressway-C og Expressway-E krever ikke at noen inngangsport åpnes i brannmuren demilitarisert sone (DMZ) på grunn av brannmurens traverseringsarkitektur. Men TCP SIP-signalporter og UDP- medieporter må åpnes innkommende på Internett- brannmuren for å la innkommende anrop komme gjennom. Du må gi tid til å åpne riktig port på bedriftsbrannmuren.

Brannmurkryssingsarkitekturen er vist i følgende diagram:

For eksempel, for innkommende B2B-samtaler som bruker SIP-protokoll, må TCP-portene 5060 og 5061 (5061 brukes for 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 postene, DNS SRV og den samme verdien må åpnes på Internett-brannmuren.

Selv om standarden for SIP TCP er 5060 og for SIP TLS 5061, hindrer ingenting bruk av forskjellige porter, som følgende eksempel viser.

Eksempel

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

Rek DNS SRV orden for en klynge med to Expressway-servere ser slik ut:

_slurker. _tcp.example .com SRV tjenestested:

priority = 10

weight = 10

port = 5062

svr vertsnavn = us-expe1.example.com

_slurker. _tcp.example .com SRV tjenestested:

priority = 10

weight = 10

port = 5062

svr vertsnavn = us-expe2.example.com

Disse oppføringene betyr at anrop blir rettet til us-expe1.example.com og us-expe2.example.com med lik belastnings deling (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 bedrifts domenet (user1@example.com), må spørre DNS-en for å forstå hvilken transporttype som skal brukes, port nummeret, hvordan du laster inn trafikken og hvilke SIP- servere som skal sendes anropet til.

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

TLS er en klient-serverprotokoll og bruker i de vanligste implementeringene sertifikater for autentisering. I et business-to-business-samtalescen ario er TLS-klienten den anropende enheten, og TLS-serveren er den kalte enheten. Med TLS sjekker klienten sertifikatet til serveren, og hvis sertifikatkontrollen mislykkes, kobler den fra samtalen. Kunden trenger ikke et sertifikat.

TLS-håndtrykk er vist i følgende diagram:

TLS-spesifikasjonen angir imidlertid at tjeneren også kan sjekke klientsertifikatet ved å sende en melding om sertifikatforespørsel til klienten under TLS- håndtrykksprotokollen. Denne meldingen er nyttig på en server-til-server-tilkobling, for eksempel ved samtale som er opprettet mellom Expressway-E og Webex-skyen. Dette konseptet kalles TLS med gjensidig autentisering og kreves når du integrerer med Webex.

Både de anropende og de ringte partene sjekker sertifikatet til den andre jevnaldrende, som følgende diagram viser:

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

Hvis gjensidig autentisering er slått på, ber Expressway-E alltid om klient sertifikatet. Som et resultat vil ikke Mobile og Remote Access (MRA) fungere, fordi sertifikater i de fleste tilfeller ikke distribueres på Jabber-klienter . Hvis den anropende enheten ikke kan levere et sertifikat i et business-to-business-scenario, kobles anro pet fra.

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

Hvis en eksisterende post allerede brukes til kommunikasjon mellom bedrifter, anbefaler vi at du spesifiserer et underdomene til bedriftsdomenet som SIP-destinasjon i Control Hub, og følgelig en offentlig DNS SRV post, som følger:

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

Business-to-business-, mobil- Remote Access og Webex-trafikk på samme Expressway-par

Business-to-business (B2B) og mobile og Remote Access (MRA) an rop bruker port 5061 for SIP TLS, og Webex-trafikk bruker port 5062 for SIP TLS med gjensidig godkjenning.

Kontroll av domeneeierskap er en del av identitetsbekreftelsen. Domenebekreftelse 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 engangsverifiseringskontroll:

   • E-postdomene

   • Expressway-E DNS-domene

   • Katalog URI-domene

2. Expressway-E DNS-navneeierkontroll. Dette trinnet utføres gjennom implementering av TLS med gjensidig autentisering og innebærer bruk av offentlige sertifikater på både skyen og Expressway. I motsetning til domeneidentitetskontrollen utføres dette trinnet under alle anrop til og mottatt fra skyen.

Betydningen av kontroll av domeneeierskap

Webex-skyen utfører kontrollen av domeneeierskap for å håndheve sikkerhet. Identitetstyveri er en mulig trussel hvis denne sjekken ikke utføres.

Følgende historie beskriver hva som kan skje hvis en kontroll av domeneeierskap ikke utføres.

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

Administratoren av Hacker.com-selskapet setter en av katalog-URIene hennes 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, blir bekreftelses-e-posten lest og besvart, og hun kan logge på. Til slutt ringer hun til en kollega, John Doe, ved å ringe john.doe@example.com fra Webex-appen sin. John sitter på kontoret sitt og ser en samtale på videoenheten sin som kommer fra jane.roe@example.com; det er katalog-URI tilknyttet 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 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 samtaler som kommer fra Internett, men et av ansvarene til Webex-skyen er å sørge for at identiteten til alle som ringer fra Webex er riktig og ikke forfalsket.

For å sjekke identiteten krever Webex at selskapet beviser at det eier domenene som brukes i Hybrid Calling. Hvis det ikke gjør det, fungerer ikke hybridtjenester.

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

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

   • Alle disse domenene må være rutbare 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 muligheten til å knytte vilkårlig og uformatert tekst til en vert eller et annet navn.

   • DNS-administratoren må angi den TXT-posten i sonen hvis eierskap må bevises. Etter dette trinnet utfører Webex-skyen en TXT-postspørring for det 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 Hybrid Services skal fungere på domenet hennes.

   • Gjennom https://admin.webex.com starter hun bekreftelsesprosessen ved å opprette en TXT-post for å matche tokenet som Webex-skyen genererte:

     

   • DNS-administratoren oppretter deretter en TXT-post for dette domenet med verdien satt til 123456789abcdef123456789abcdef 123456789abcdef123456789abcdef, 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 kampen at administratoren la til TXT-posten for sitt eget domene i den offentlige DNS-en, og at hun eier domenet.

2. Expressway-E DNS-navneeierkontroll.

   • Skyen må sjekke 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. For å utstede sertifikatet utfører sertifikatmyndigheten en identitetsbekreftelsesprosess, basert på en domenevalideringskontroll (for domenevaliderte sertifikater) eller organisasjonsvalideringskontroll (for organisasjonsvaliderte sertifikater).

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

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

Webex Device Connector distribueres i det interne nettverket, og måten den kommuniserer med skyen på er gjennom en utgående HTTPS-tilkobling — den samme typen som brukes for alle nettlesere som kobles til en webserver.

Kommunikasjon til Webex-skyen bruker TLS. Webex Device Connector er TLS-klienten, og Webex-skyen er TLS-serveren. Som sådan sjekker 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 levert av skyen, må den bruke den offentlige nøkkelen til sertifik atmyndigheten som signerte sertifikatet for å dekode signaturen. En offentlig nøkkel finnes i sertifikatet til sertifikatmyndigheten. For å etablere tillit med sertifikatmyndighetene som brukes av skyen, må listen over sertifikater for disse klarerte sertifikatmyndighetene være i klareringslageret Webex Device Connector.

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

Det kreves også en liste over sertifikatmyndighetssertifikater for Expressway-E i kryssparet. Expressway-E kommuniserer med Webex-skyen ved hjelp av SIP med TLS, håndhevet av gjensidig autentisering. Expressway-E stoler på an rop som kommer fra og går til skyen, bare hvis CN eller SAN for sertifikatet som presenteres av skyen under TLS-tilkoblingsoppsettet samsvarer med emnenavnet som er konfigurert for DNS-sonen på Expressway («callservice.webex.com»). Sertifikatmyndigheten utgir bare et sertifikat etter en identitetskontroll. Eierskapet til callservice.webex.com-domenet 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 jevnalderen virkelig er Webex.

kalenderkontakt integrerer Webex med Microsoft Exchange 2013, 2016, 2019 eller Office 365 gjennom en etterligningskonto. Administrasjonsrollen for applikasjonsutligning i Exchange gjør det mulig for programmer å etterligne brukere i en organisasjon for å utføre oppgaver på vegne av brukeren. Programetterligningsrollen 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 ved hjelp av samme legitimasjonskrypteringsmekanisme som andre passord på Expressway-C.

For ytterligere sikkerhet, følg trinnene i distribusjonsveiledningen for Cisco Webex hybridkalendertjeneste for å aktivere TLS for å sikre EWS-tilkoblinger på ledningen.

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