V tem razdelku je dodan kontekst ključnih elementov konfiguracije, ki se nanašajo na hibridne storitve.

Te točke so ključne, če želite uspešno uvesti hibridno klicanje za naprave Webex. Te elemente smo izpostavili predvsem iz naslednjih razlogov:

• Želimo vam jih pojasniti, da boste razumeli njihovo vlogo pri hibridni namestitvi in se počutili varne.

• To so obvezni predpogoji, ki zagotavljajo varno namestitev med našim oblakom in vašim lokalnim okoljem.

• Obravnavati jih je treba kot dejavnosti pred začetkom ničelnega dne: lahko traja nekoliko dlje kot običajna konfiguracija v uporabniškem vmesniku, zato za urejanje teh elementov določite časovni okvir.

• Ko bodo ti elementi v vašem okolju odpravljeni, bo preostala konfiguracija hibridnih storitev potekala nemoteno.

Namestitev para Expressway-C in Expressway-E omogoča klice v internet in iz njega z uporabo tehnologij za prečkanje požarnega zidu . S to namestitvijo varno prevzamete nadzor klicev v lokalnem okolju in ga povežete s storitvijo Webex.

Pri Expressway-C in Expressway-E zaradi arhitekture prehoda čez požarni zid ni treba odpreti nobenih vhodnih vrat v požarnem zidu demilitariziranega območja (DMZ). Vendar je treba na internetnem požarnem zidu odpreti vhodna vrata za signalizacijo TCP SIP in medijska vrata UDP, da se omogoči prehod dohodnih klicev. Za odprtje ustreznih vrat na požarnem zidu podjetja morate predvideti dovolj časa.

Arhitektura prehoda požarnega zidu je prikazana v naslednjem diagramu:

Na primer za dohodne klice med podjetji (B2B) s protokolom SIP je treba na zunanjem požarnem zidu odpreti vrata TCP 5060 in 5061 (5061 se uporablja za SIP TLS) ter medijska vrata UDP, ki se uporabljajo za storitve, kot so glas, video, izmenjava vsebine, dvojni video itd. Katera medijska vrata odprete, je odvisno od števila sočasnih klicev in števila storitev.

Vrata za poslušanje SIP v omrežju Expressway lahko nastavite na katero koli vrednost med 1024 in 65534. Hkrati morata biti ta vrednost in vrsta protokola objavljena v javnih zapisih SRV DNS, ista vrednost pa mora biti odprta na internetnem požarnem zidu.

Čeprav je standard za SIP TCP 5060 in za SIP TLS 5061, nič ne preprečuje uporabe različnih vrat, kot kaže naslednji primer.

Primer

V tem primeru predpostavljamo, da se za dohodne klice SIP TLS uporabljajo vrata 5062.

Zapis SRV DNS za gručo dveh strežnikov Expressway je videti takole:

_sips._tcp.example.com Lokacija storitve SRV:

prioriteta = 10

teža = 10

vrata = 5062

ime gostitelja svr = us-expe1.example.com

_sips._tcp.example.com Lokacija storitve SRV:

prioriteta = 10

teža = 10

vrata = 5062

ime gostitelja svr = us-expe2.example.com

Ti zapisi pomenijo, da so klici usmerjeni na us-expe1.example.com in us-expe2.example.com z enako porazdelitvijo obremenitve (prioriteta in teža) z uporabo TLS kot vrste prenosa in 5062 kot številke vrat za poslušanje.

Naprava, ki je zunaj omrežja (v internetu) in opravlja klic SIP uporabniku v domeni podjetja (user1@example.com), mora poizvedovati po DNS, da ugotovi, katero vrsto prenosa je treba uporabiti, številko vrat, kako porazdeliti promet in katerim strežnikom SIP poslati klic.

Če vnos DNS vključuje _sips._tcp, vnos določa SIP TLS.

TLS je protokol odjemalec-strežnik in v najpogostejših izvedbah za preverjanje pristnosti uporablja potrdila. V scenariju klica med podjetji je odjemalec TLS kličoča naprava, strežnik TLS pa klicana naprava. Pri protokolu TLS odjemalec preveri potrdilo strežnika in če preverjanje potrdila ni uspešno, prekine klic. Odjemalec ne potrebuje potrdila.

V naslednjem diagramu je prikazano rokovanje TLS:

Vendar specifikacija TLS navaja, da lahko strežnik preveri potrdilo odjemalca tudi tako, da mu med protokolom TLS handshake pošlje sporočilo Certificate Request. To sporočilo je uporabno pri povezavi med strežniki, kot je klic, ki je vzpostavljen med Expressway-E in oblakom Webex. Ta koncept se imenuje TLS z vzajemnim preverjanjem pristnosti in je potreben pri povezovanju z Webexom.

Tako kličoča kot klicana stran preverita certifikat drugega kolega, kot je prikazano na naslednjem diagramu:

Oblak preveri identiteto Expresswaya, Expressway pa identiteto oblaka. Če se na primer identiteta oblaka v potrdilu (CN ali SAN) ne ujema z identiteto, ki je konfigurirana v omrežju Expressway, se povezava prekine.

Če je vklopljeno vzajemno preverjanje pristnosti, Expressway-E vedno zahteva potrdilo odjemalca. Mobilni in oddaljeni dostop (MRA) zato ne bo deloval, ker v večini primerov certifikati niso nameščeni v odjemalcih Jabber. Če kličoči subjekt ne more zagotoviti potrdila, se v scenariju med podjetji klic prekine.

Priporočamo, da za TLS z vzajemno avtentikacijo uporabite drugo vrednost kot 5061, na primer vrata 5062. Hibridne storitve Webex uporabljajo enak zapis SIP TLS, ki se uporablja za B2B. V primeru vrat 5061 nekatere druge storitve, ki ne morejo zagotoviti potrdila TLS odjemalca, ne bodo delovale.

Če se obstoječi zapis že uporablja za komunikacije med podjetji, priporočamo, da kot ciljni strežnik SIP v vozlišču Control Hub določite poddomeno domene podjetja in posledično javni zapis SRV DNS, kot sledi:

 Storitev in protokol: _sips._tcp.mtls.example.com Prednost: 1 Teža: 10 Številka pristanišča: 5062 Cilj: us-expe1.example.com 

Promet med podjetji, mobilni in oddaljeni dostop ter Webex na istem paru hitrih cest

Klici med podjetji (B2B) in klici za mobilni in oddaljeni dostop (MRA) uporabljajo vrata 5061 za SIP TLS, promet Webex pa vrata 5062 za SIP TLS z vzajemno avtentikacijo.

Preverjanje lastništva domene je del preverjanja identitete. Preverjanje domene je varnostni ukrep in preverjanje identitete, ki ga izvaja oblak Webex, da dokaže, da ste tisti, za katerega se izdajate.

Preverjanje identitete poteka v dveh stopnjah:

1. Preverjanje lastništva domene. Ta korak vključuje tri vrste domen in je enkratno preverjanje:

   • E-poštna domena

   • Domena DNS Expressway-E

   • Domena URI imenika

2. Preverjanje lastništva imena Expressway-E DNS. Ta korak se izvede z implementacijo protokola TLS z vzajemno avtentikacijo in vključuje uporabo javnih potrdil tako v oblaku kot v omrežju Expressway. Za razliko od preverjanja identitete domene se ta korak izvede med vsakim klicem v oblak in prejetim iz njega.

Pomen preverjanja lastništva domene

Oblak Webex preveri lastništvo domene, da zagotovi varnost. Če tega preverjanja ne opravite, lahko pride do kraje identitete.

Naslednja zgodba opisuje, kaj se lahko zgodi, če preverjanje lastništva domene ni izvedeno.

Podjetje z domeno DNS, nastavljeno na "hacker.com", kupi hibridne storitve Webex. Hibridne storitve uporablja tudi drugo podjetje, ki ima svojo domeno nastavljeno na "example.com". Enemu od generalnih direktorjev podjetja Example.com je ime Jane Roe in ima imenik URI jane.roe@example.com.

Upravitelj podjetja Hacker.com nastavi enega od imeniških URI na jane.roe@example.com, e-poštni naslov pa na jane.roe@hacker.com. To lahko stori, ker oblak v tem primeru ne preverja domene URI SIP.

Nato se prijavi v aplikacijo Webex s spletnim mestom jane.roe@hacker.com. Ker je lastnica domene, se potrditveno e-poštno sporočilo prebere in odgovori nanj ter se lahko prijavi. Nazadnje pokliče sodelavca Johna Doe, tako da iz aplikacije Webex pokliče john.doe@example.com. John sedi v pisarni in na svoji video napravi vidi klic, ki prihaja iz jane.roe@example.com; to je imeniški URI, povezan s tem e-poštnim računom.

"Je v tujini," pomisli. "Morda potrebuje nekaj pomembnega." Odgovori na telefonski klic in lažna Jane Roe ga prosi za pomembne dokumente. Pojasni mu, da je njena naprava pokvarjena in da je na potovanju, zato ga prosi, naj dokumente pošlje na njen zasebni e-poštni naslov jane.roe@hacker.com. Tako podjetje šele po vrnitvi Jane Roe v pisarno ugotovi, da so pomembne informacije pricurljale izven podjetja.

Podjetje Example.com ima veliko načinov za zaščito pred goljufivimi klici, ki prihajajo iz interneta, vendar je ena od odgovornosti oblaka Webex, da poskrbi, da je identiteta klicočega iz Webexa pravilna in da ni ponarejena.

Webex za preverjanje identitete zahteva, da podjetje dokaže, da je lastnik domen, ki se uporabljajo v hibridnem klicanju. V nasprotnem primeru hibridne storitve ne bodo delovale.

Za zagotovitev tega lastništva sta potrebna dva koraka preverjanja domene:

1. Dokažite, da je podjetje lastnik e-poštne domene, domene Expressway-E in domene Directory URI.

   • Vse te domene morajo biti usmerljive in znane javnim strežnikom DNS.

   • Za dokazovanje lastništva mora skrbnik DNS vnesti besedilni zapis DNS (TXT). Zapis TXT je vrsta zapisa vira v sistemu DNS, ki se uporablja za zagotavljanje možnosti povezovanja poljubnega in neformatiranega besedila z gostiteljevim ali drugim imenom.

   • Skrbnik DNS mora ta zapis TXT vnesti v območje, katerega lastništvo je treba dokazati. Po tem koraku oblak Webex opravi poizvedbo po zapisu TXT za to domeno.

   • Če je poizvedba TXT uspešna in se rezultat ujema z žetonom, ki je bil ustvarjen v oblaku Webex, je domena preverjena.

   • Če želi, da hibridne storitve Webex delujejo v njeni domeni, mora na primer skrbnik dokazati, da je lastnik domene example.com.

   • Prek spletne strani https://admin.webex.com začne postopek preverjanja z ustvarjanjem zapisa TXT, ki ustreza žetonu, ki ga je ustvaril oblak Webex:

     

   • Administrator DNS nato ustvari zapis TXT za to domeno z vrednostjo, nastavljeno na 123456789abcdef123456789abcdef123456789abcdef123456789abcdef123456789abcdef, kot v naslednjem primeru:

     

   • Na tej točki lahko oblak preveri, ali se zapis TXT za domeno example.com ujema z žetonom.

   • Oblak izvede iskanje TXT DNS:

     

   • Ker se vrednost TXT ujema z vrednostjo žetona, to ujemanje dokazuje, da je skrbnica v javni DNS dodala zapis TXT za svojo domeno in da je lastnica domene.

2. Preverjanje lastništva imena DNS Expressway-E.

   • Oblak mora preveriti, ali ima Expressway-E potrjeno identiteto od enega od overiteljev, ki mu oblak zaupa. Skrbnik Expressway-E mora pri enem od teh overiteljev zahtevati javno potrdilo za svoj Expressway-E. Za izdajo potrdila organ za potrjevanje izvede postopek preverjanja identitete na podlagi preverjanja veljavnosti domene (za potrdila, potrjena v domeni) ali preverjanja veljavnosti organizacije (za potrdila, potrjena v organizaciji).

   • Klici v oblak in iz njega so odvisni od certifikata, ki je bil izdan napravi Expressway-E. Če potrdilo ni veljavno, se klic prekine.

Za delovanje hibridnega klicanja mora priključek za naprave Webex komunicirati s storitvijo Webex.

Webex Device Connector je nameščen v notranjem omrežju, z oblakom pa komunicira prek izhodne povezave HTTPS - enake vrste, kot jo uporablja vsak brskalnik, ki se povezuje s spletnim strežnikom.

Pri komunikaciji z oblakom Webex se uporablja protokol TLS. Webex Device Connector je odjemalec TLS, Webexov oblak pa strežnik TLS. Zato program Webex Device Connector preveri potrdilo strežnika.

Overitelj podpiše strežniško potrdilo s svojim zasebnim ključem. Vsakdo, ki ima javni ključ, lahko dekodira ta podpis in dokaže, da je potrdilo podpisala ista overiteljica.

Če mora program Webex Device Connector potrditi potrdilo, ki ga zagotovi oblak, mora za dekodiranje podpisa uporabiti javni ključ overitelja, ki je podpisal to potrdilo. Javni ključ je vsebovan v potrdilu organa za potrjevanje. Če želite vzpostaviti zaupanje z overitelji potrdil, ki jih uporablja oblak, mora biti seznam potrdil teh zaupanja vrednih overiteljev potrdil v shrambi zaupanja programa Webex Device Connector.

Pri komunikaciji z napravami orodje uporablja zaupanja vredna potrdila, ki jih zagotovite. Trenutno to lahko storite tako, da jih namestite v [domača mapa]/.devicestool/certs.

Seznam potrdil overiteljev potrdil je potreben tudi za Expressway-E v prehodnem paru. Expressway-E komunicira z oblakom Webex z uporabo protokola SIP s protokolom TLS, ki se izvaja z vzajemnim preverjanjem pristnosti. Expressway-E zaupa klicem, ki prihajajo iz oblaka in odhajajo v oblak, samo če se CN ali SAN certifikata, ki ga oblak predstavi med vzpostavitvijo povezave TLS, ujema z imenom subjekta, ki je konfigurirano za območje DNS v sistemu Expressway ("callservice.webex.com"). Organ za potrjevanje izda potrdilo šele po preverjanju identitete. Za podpis potrdila je treba dokazati lastništvo domene callservice.webex.com. Ker je ta domena v naši lasti (Cisco), je ime DNS "callservice.webex.com" neposreden dokaz, da je oddaljeni partner resnično Webex.

koledarski povezovalnik integrira Webex z Microsoft Exchange 2013, 2016, 2019 ali Office 365 prek osebnega računa. Vloga za upravljanje poosebljanja aplikacij v Exchangeu omogoča aplikacijam, da se poosebijo uporabnikom v organizaciji in izvajajo naloge v imenu uporabnika. Vloga impersoniranja aplikacije mora biti konfigurirana v Exchangeu in se uporablja v koledarskem priključku kot del konfiguracije Exchangea na vmesniku Expressway-C.

Microsoftova priporočena metoda za to nalogo je račun za poosebljanje Exchange. Skrbnikom sistema Expressway-C gesla ni treba poznati, saj lahko vrednost v vmesnik Expressway-C vnese skrbnik Exchange. Geslo ni jasno prikazano, tudi če ima skrbnik Expressway-C korenski dostop do polja Expressway-C. Geslo je shranjeno šifrirano z uporabo istega mehanizma za šifriranje poverilnic kot druga gesla v omrežju Expressway-C.

Za dodatno varnost sledite korakom v Deployment Guide for Cisco Webex Hybrid Calendar Service , da omogočite TLS in tako zaščitite povezave EWS po žici.

Za dodatno varnost sledite korakom v razdelku Deploy Expressway Calendar Connector for Microsoft Exchange , da omogočite TLS in tako zaščitite povezave EWS na žici.