Dette afsnit indeholder yderligere kontekst om vigtige konfigurationselementer, der er relateret til hybridtjenester.

Disse punkter er afgørende, hvis du vil implementere Hybrid Calling til Webex-enheder med succes. Vi har fremhævet disse elementer af følgende grunde:

• Vi vil forklare dem, så du forstår deres rolle i en hybridudrulning og føler dig forsikret.

• Det er obligatoriske forudsætninger, der giver en sikker udrulning mellem vores sky og dit lokale miljø.

• De skal behandles som før-dag-nul-aktiviteter: Det kan tage lidt længere tid at gennemføre dem end typiske konfigurationer på en brugergrænseflade, så planlæg tid til at få disse elementer ordnet.

• Når disse punkter er adresseret i dit miljø, vil resten af din Hybrid Services-konfiguration forløbe problemfrit.

Expressway-C- og Expressway-E-parinstallationen tillader opkald til og fra internettet ved hjælp af firewall-traversalteknologier. Denne implementering er det, der sikkert forbinder din lokale opkaldskontrol med Webex.

Expressway-C og Expressway-E kræver ingen åbning af den indgående port i den demilitariserede zone-firewall (DMZ) på grund af arkitekturen for passage gennem firewall. TCP SIP-signalporte og UDP-medieporte skal dog være åbne for indgående på internetfirewallen, så indgående opkald kan gå igennem. Du skal give tid til, at de korrekte porte kan blive åbnet i din virksomheds firewall.

Arkitekturen for passage gennem firewall er vist i følgende diagram:

For eksempel i forbindelse med indgående business-to-business-opkald (B2B) med SIP-protokol skal TCP-portene 5060 og 5061 (5061 bruges til SIP TLS) åbnes på den eksterne firewall sammen med UDP-medieporte, der bruges til tjenester som tale, video, deling af indhold, dobbelt video og så videre. Hvilke medieporte, der skal åbnes, afhænger af antallet af samtidige opkald og antallet af tjenester.

Du kan konfigurere SIP-lytteporten på Expressway til en værdi mellem 1024 til 65534. Samtidig skal denne værdi og protokoltypen være annonceret i den offentlige DNS SRV-post, og den samme værdi skal være åbnet på internetfirewallen.

Selv om standarden for SIP TCP er 5060 og for SIP TLS er 5061, er der intet, der forhindrer brugen af forskellige porte, hvilket følgende eksempel viser.

Eksempel

I dette eksempel antager vi, at port 5062 bruges til indgående SIP TLS-opkald.

DNS SRV-posten for en klynge med to Expressway-servere ser således ud:

_sips._tcp.example.com SRV-tjenesteplacering:

prioritet = 10

vægtning = 10

port = 5062

svr-hostnavn = us-expe1.example.com

_sips._tcp.example.com SRV-tjenesteplacering:

prioritet = 10

vægtning = 10

port = 5062

svr-hostnavn = us-expe2.example.com

Disse poster betyder, at opkald sendes til us-expe1.example.com og us-expe2.example.com med samme belastningsdeling (prioritet og vægtning) med TLS som transporttype og 5062 som lytteport.

En enhed, der er ekstern for netværket (på internettet), og som foretager et SIP-opkald til en bruger af virksomhedens domæne (user1@example.com), skal spørge DNS for at finde ud af, hvilken transporttype der skal bruges, portnummeret, hvordan den skal belastningsdele trafikken, og hvilke SIP-servere opkaldet skal sendes til.

Hvis DNS-posten indeholder _sips._tcp, angiver posten SIP TLS.

TLS er en klientserverprotokol og bruger certifikater til godkendelse i forbindelse med de fleste almindelige implementeringer. I et business-to-business-opkaldsscenarie er TLS-klienten den enhed, der ringes fra, og TLS-serveren er den enhed, der ringes til. Med TLS kontrollerer klienten serverens certifikat, og, hvis certifikatkontrollen mislykkes, afbryder den opkaldet. Klienten behøver ikke et certifikat.

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

TLS-specifikationen angiver dog, at serveren også kan kontrollere klientcertifikatet ved at sende en certifikatanmodningsbesked til klienten under TLS-håndtryksprotokollen. Denne besked er nyttig ved en server-til-server-forbindelse, f.eks. ved et opkald, der etableres mellem Expressway-E og Webex Cloud. Dette koncept kaldes TLS med gensidig godkendelse og er påkrævet ved integration med Webex.

Både den, der ringer, og den modtagende part kontrollerer certifikatet fra den anden person, som det følgende diagram viser det:

Skyen kontrollerer Expressway-identiteten, og Expressway kontrollerer skyens identitet. Hvis skyidentiteten i certifikatet (CN eller SAN) for eksempel ikke matcher med konfigurationen på Expressway, afbrydes forbindelsen.

Hvis gensidig godkendelse er aktiveret, anmoder Expressway-E altid om klientcertifikatet. Som et resultat deraf vil Mobil- og Fjernadgang (MRA) ikke fungere, da certifikater i de fleste tilfælde ikke er udrullet på Jabber-klienter. I et business-to-business-scenarie, hvor enheden, der ringes fra, ikke er i stand til at levere et certifikat, afbrydes opkaldet.

Vi anbefaler, at du bruger en anden værdi end 5061 til TLS med gensidig godkendelse, f.eks. port 5062. Webex Hybrid-tjenester bruger den samme SIP TLS-post, der bruges til B2B. Med hensyn til port 5061 vil nogle andre tjenester, der ikke kan levere et TLS-klientcertifikat, ikke virke.

Hvis en eksisterende post allerede bruges til virksomhed-til-virksomhed-kommunikation, anbefaler vi at angive et underdomæne af virksomhedsdomænet som SIP-destination i Control Hub og dermed 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 og fjernadgang og Webex-trafik på det samme Expressway-par

Business-to-business (B2B) og Mobile and Remote Access (MRA)-opkald bruger port 5061 til SIP TLS, og Webex-trafik bruger port 5062 til SIP TLS med gensidig godkendelse.

Domæneejerskabskontrollen er en del af identitetsbekræftelsen. Domænebekræftelse er en sikkerhedsforanstaltning og identitetskontrol, som Webex Cloud implementerer for at bevise, at du er den, du siger, du er.

Identitetskontrollen udføres i to trin:

1. Kontrol af domæneejerskab. Dette trin omfatter tre typer af domæner og er en enkeltstående bekræftelseskontrol:

   • Gør krav på domæne

   • Expressway-E DNS-domæne

   • Register-URI-domæne

2. Expressway-E DNS-navneejerskabskontrol. Dette trin udføres igennem implementering af TLS med gensidig godkendelse og involverer brug af offentlige certifikater for både skyen og Expresswayen. I modsætning til domæneidentitetskontrollen udføres dette trin under alle opkald til og fra skyen.

Vigtigheden af domæneejerskabstjek

Webex Cloud udfører domæneejerskabskontrollen for at håndhæve sikkerheden. Identitetstyveri er blot én mulig trussel, hvis denne kontrol ikke udføres.

Denne historie beskriver, hvad der kan ske, hvis der ikke udføres en domæneejerskabskontrol.

En virksomhed med DNS-domænet indstillet til "hacker.com" køber Webex Hybrid Services. En anden virksomhed, hvis eget domæne er indstillet til "example.com", bruger også hybridtjenester. Én af virksomheden Example.com's direktører hedder Jane Roe og har register-URI'en jane.roe@example.com.

Administratoren fra virksomheden Hacker.com angiver én af sine register-URI'er som jane.roe@example.com og e-mailadressen som jane.roe@hacker.com. Det er hun i stand til at gøre, fordi skyen i dette eksempel ikke kontrollerer SIP URI-domænet.

Dernæst logger hun ind på Webex-appen med jane.roe@hacker.com. Da hun ejer domænet, læses og besvares bekræftelses-e-mailen, og hun kan logge ind. Til sidst ringer hun til en kollega, John Doe, ved at taste john.doe@example.com fra hendes Webex-app. John sidder på sit kontor og ser et opkald på sin videoenhed komme fra jane.roe@example.com; Det er den mappe-URI, der er knyttet til den e-mailkonto.

"Hun er i udlandet," tænker han. "Det kan være, hun har brug for noget vigtigt." Han tager telefonen, og den falske Jane Roe beder om vigtige dokumenter. Hun fortæller, at hendes enhed er gået i stykker, og fordi hun er på rejse, beder hun ham om at sende dokumenterne til hendes personlige e-mailadresse jane.roe@hacker.com. På den måde opdager virksomheden kun, at der er blevet lækket vigtige oplysninger til uden for virksomheden, efter at Jane Roe kommer tilbage til kontoret.

Virksomheden Example.com har mange måder at beskytte sig mod svigagtige opkald fra internettet, men en af Webex-cloudens ansvarsområder er at sikre, at identiteten på alle, der ringer fra Webex, er korrekt og ikke forfalsket.

For at kontrollere identiteten kræver Webex, at virksomheden beviser, at den ejer de domæner, der bruges i Hybrid Calling. Hvis det ikke gør det, vil hybridtjenester ikke fungere.

For at sikre dette ejerskab kræves der to domænebekræftelsestrin:

1. Bevis, at virksomheden ejer e-maildomænet, Expressway-E-domænet og register-URI-domænet.

   • Alle disse domæner skal kunne routes og være kendt af offentlige DNS-servere.

   • For at bevise ejerskabet skal DNS-administratoren indtaste en DNS-txt-post (TXT). En TXT-post er en type ressourcepost i DNS'en, der bruges til at gøre det muligt at knytte vilkårlig, uformateret tekst til en host eller et andet navn.

   • DNS-administratoren skal indtaste denne TXT-post i den zone, hvis ejerskab skal bevises. Efter dette trin udfører Webex Cloud en TXT-postforespørgsel for det pågældende domæne.

   • Hvis TXT-forespørgslen lykkes, og resultatet matcher det token, der blev genereret fra Webex Cloud, verificeres domænet.

   • Som et eksempel skal administratoren bevise, at hun ejer domænet "example.com", hvis hun ønsker, at Webex Hybrid Services skal fungere på hendes domæne.

   • Gennem https://admin.webex.comstarter hun bekræftelsesprocessen ved at oprette en TXT-post, der matcher det token, som Webex-clouden genererede:

     

   • DNS-administratoren opretter derefter en TXT-post for dette domæne med værdien indstillet til 123456789abcdef123456789abcdef123456789abcdef123456789abcdef, som i følgende eksempel:

     

   • På dette tidspunkt kan skyen bekræfte, at TXT-posten for domænet example.com matcher med denne token.

   • Skyen udfører et TXT DNS-opslag:

     

   • Da TXT-værdien matcher tokenværdien, beviser dette match, at administratoren føjede TXT-posten for sit eget domæne til den offentlige DNS, og at hun ejer domænet.

2. Expressway-E DNS-navneejerskabskontrol.

   • Skyen skal kontrollere, at Expressway-E har en bekræftet identitet fra en af de certifikatudstedere, som skyen har tillid til. Expressway-E-administratoren skal anmode om et offentligt certifikat til sin Expressway-E ved én af disse certifikatudstedere. For at udstede certifikatet udfører certifikatudstederen en identitetsbekræftelsesproces baseret på en domænebekræftelseskontrol (for domænevaliderede certifikater) eller organisationsgodkendelseskontrol (for organisationsvaliderede certifikater).

   • Opkald til og fra skyen afhænger af det certifikat, der blev udstedt til Expressway-E. Hvis certifikatet ikke er gyldigt, stoppes opkaldet.

Webex-enhedsforbindelsen skal kommunikere med Webex for at hybridopkald kan fungere.

Webex-enhedsforbindelsen er implementeret i det interne netværk, og den måde, den kommunikerer med skyen på, er via en udgående HTTPS-forbindelse – den samme type, der bruges til enhver browser, der opretter forbindelse til en webserver.

Kommunikation til Webex Cloud bruger TLS. Webex Device Connector er TLS-klienten, og Webex Cloud er TLS-serveren. Som sådan kontrollerer Webex Device Connector servercertifikatet.

Certifikatudstederen signerer et servercertifikat ved brug af sin egen private nøgle. Alle, der har den offentlige nøgle, kan afkode signaturen og bevise, at den samme certifikatudsteder har signeret den.

Hvis Webex Device Connector skal validere det certifikat, der leveres af skyen, skal den bruge den offentlige nøgle fra den certifikatmyndighed, der signerede certifikatet, til at afkode signaturen. Der findes en offentlig nøgle i certifikatet fra certifikatudstederen. For at etablere tillid til de certifikatmyndigheder, der bruges af skyen, skal listen over certifikater fra disse betroede certifikatmyndigheder være i Webex Device Connector-tillidslageret.

Når værktøjet kommunikerer med enheder, bruger det betroede certifikater, som du angiver. Måden at gøre det på er i øjeblikket ved at placere dem i [home folder]/.devicestool/certs.

Der kræves også en liste over certifikatudstedercertifikater for Expressway-E i passageparret. Expressway-E kommunikerer med Webex-clouden ved hjælp af SIP med TLS, hvilket håndhæves af gensidig godkendelse. Expressway-E stoler kun på opkald, der kommer fra og går til skyen, hvis CN eller SAN for det certifikat, der præsenteres af skyen under opsætningen af TLS-forbindelsen, matcher det emnenavn, der er konfigureret for DNS-zonen på Expressway ("callservice.webex.com"). Certifikatudstederen frigiver kun et certifikat efter en identitetskontrol. Ejerskabet af domænet callservice.webex.com skal bevises for at få et certifikat underskrevet. Fordi vi (Cisco) ejer domænet, er DNS-navnet "callservice.webex.com" et direkte bevis på, at den eksterne peer virkelig er Webex.

kalendertilslutter integrerer Webex med Microsoft Exchange 2013, 2016, 2019 eller Office 365 igennem en personefterligningskonto. Programpersonifikationsstyringsrollen i Exchange giver programmer mulighed for at udgive sig for at være brugere i en organisation, så de kan udføre opgaver på vegne af brugeren. Programpersoningsrollen skal konfigureres i Exchange og bruges i kalendertilslutningen som en del af Exchange-konfigurationen på Expressway-C-grænsefladen.

Exchange-efterligningskontoen er Microsofts anbefalede metode til denne opgave. Expressway-C-administratorer behøver ikke at kende adgangskoden, da værdien kan indtastes i Expressway-C-grænsefladen af en Exchange-administrator. Adgangskoden vises ikke tydeligt, selv hvis -Expressway-C-administratoren har rodadgang til Expressway-C-boksen. Adgangskoden gemmes krypteret ved hjælp af den samme mekanisme til kryptering af legitimationsoplysninger som andre adgangskoder Expressway-C.

For yderligere sikkerhed skal du følge trinnene i Installationsvejledning til Cisco Webex-hybrid-kalendertjeneste for at aktivere TLS med henblik på at sikre EWS-forbindelser på ledningen.

For yderligere sikkerhed skal du følge trinnene i Implementer Expressway til Microsoft Exchange for at aktivere TLS med henblik på at sikre EWS-forbindelser på ledningen.