Ta razdelek vsebuje dodaten kontekst o ključnih elementih 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 posebej izpostavili iz naslednjih razlogov:

• Želimo jih razložiti, da boste razumeli njihovo vlogo pri hibridni uvedbi in se počutili pomirjene.

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

• Obravnavati jih je treba kot ničelne dejavnosti pred dnevom: Njihovo dokončanje lahko traja nekoliko dlje kot običajna konfiguracija v uporabniškem vmesniku, zato si za urejanje teh elementov pustite nekaj časa.

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

Uvedba para Expressway-C in Expressway-E omogoča klice v internet in iz njega z uporabo tehnologij prečkanja požarnega zidu. Ta namestitev varno poveže vaš lokalni nadzor klicev z Webexom.

Avtocesti Expressway-C in Expressway-E zaradi arhitekture prečkanja požarnega zidu ne zahtevata odpiranja nobenih vhodnih vrat v požarnem zidu demilitarizirane cone (DMZ). Vendar pa morajo biti signalna vrata TCP SIP in medijska vrata UDP odprta na internetnem požarnem zidu, da se omogočijo dohodni klici. Počakati morate nekaj časa, da se odprejo ustrezna vrata na požarnem zidu podjetja.

Arhitektura prečkanja požarnega zidu je prikazana na naslednjem diagramu:

Na primer, za dohodne klice med podjetji (B2B) z uporabo protokola SIP morajo biti na zunanjem požarnem zidu odprta vrata TCP 5060 in 5061 (5061 se uporablja za SIP TLS), skupaj z medijskimi vrati UDP, ki se uporabljajo za storitve, kot so glas, video, deljenje vsebin, dvojni video itd. Katera medijska vrata odpreti, je odvisno od števila sočasnih klicev in števila storitev.

Vrata za poslušanje SIP na Expresswayu lahko konfigurirate na katero koli vrednost med 1024 in 65534. Hkrati morata biti ta vrednost in vrsta protokola objavljeni v javnih zapisih DNS SRV, 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 vrata 5062 uporabljajo za dohodne klice SIP TLS.

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

_sips._tcp.example.com Lokacija storitve SRV:

prednost = 10

teža = 10

pristanišče = 5062

ime gostitelja SVR = us-expe1.example.com

_sips._tcp.example.com Lokacija storitve SRV:

prednost = 10

teža = 10

pristanišče = 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 delitvijo obremenitve (prioriteta in teža) z uporabo TLS kot vrste transporta in 5062 kot številke poslušalskih vrat.

Naprava, ki je zunanja od omrežja (na internetu) in ki opravlja klic SIP z uporabnikom v domeni podjetja. (user1@example.com) mora poizvedovati pri DNS-u, da razume, katero vrsto transporta uporabiti, številko vrat, kako deliti promet in na katere SIP strežnike poslati klic.

Če vnos DNS vsebuje _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 klicna naprava, strežnik TLS pa klicana naprava. Pri TLS odjemalec preveri potrdilo strežnika in če preverjanje potrdila ne uspe, prekine klic. Stranka ne potrebuje potrdila.

Rokovanje TLS je prikazano na naslednjem diagramu:

Vendar specifikacija TLS navaja, da lahko strežnik preveri odjemalčevo potrdilo tudi tako, da odjemalcu med protokolom rokovanja TLS pošlje sporočilo z zahtevo za potrdilo. To sporočilo je koristno pri povezavi med strežnikoma, kot je na primer klic, ki je vzpostavljen med Expressway-E in oblakom Webex. Ta koncept se imenuje TLS z medsebojnim preverjanjem pristnosti in je potreben pri integraciji z Webexom.

Tako klicatelj kot klicana stran preverita potrdilo drugega vrstnika, kot prikazuje naslednji diagram:

Oblak preveri identiteto Expresswayja, Expressway pa preveri identiteto v oblaku. Če se na primer identiteta v oblaku v potrdilu (CN ali SAN) ne ujema s konfiguracijo na Expresswayu, se povezava prekine.

Če je vzajemno preverjanje pristnosti vklopljeno, Expressway-E vedno zahteva potrdilo odjemalca. Posledično mobilni in oddaljeni dostop (MRA) ne bo deloval, ker v večini primerov potrdila niso nameščena na odjemalcih Jabber. V scenariju med podjetji se klic prekine, če klicajoča entiteta ne more zagotoviti potrdila.

Priporočamo, da za TLS z medsebojnim preverjanjem pristnosti uporabite vrednost, ki ni 5061, na primer vrata 5062. Hibridne storitve Webex uporabljajo isti zapis SIP TLS kot za B2B. V primeru vrat 5061 nekatere druge storitve, ki ne morejo zagotoviti odjemalskega potrdila TLS, ne bodo delovale.

Če se za komunikacijo med podjetji že uporablja obstoječi zapis, priporočamo, da v Control Hub kot cilj SIP določite poddomeno korporativne domene in posledično javni zapis DNS SRV, kot sledi:

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

Dostop med podjetji, mobilni in oddaljeni dostop ter promet Webex na istem paru avtocest

Klici med podjetji (B2B) in mobilni ter oddaljeni dostop (MRA) uporabljajo vrata 5061 za SIP TLS, promet Webex pa uporablja vrata 5062 za SIP TLS z medsebojnim preverjanjem pristnosti.

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 resnično tisti, za katerega se izdajate.

Preverjanje identitete se izvaja v dveh fazah:

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

   • E-poštna domena

   • DNS domena Expressway-E

   • Domena URI imenika

2. Preverjanje lastništva imena DNS Expressway-E. Ta korak se izvede z implementacijo TLS z medsebojnim preverjanjem pristnosti in vključuje uporabo javnih potrdil tako v oblaku kot na avtocesti. Za razliko od preverjanja identitete domene se ta korak izvede med vsakim klicem, ki je vzpostavljen v oblak in prejet iz oblaka.

Pomen preverjanja lastništva domene

Oblak Webex izvaja preverjanje lastništva domene za uveljavljanje varnosti. Kraja identitete je ena od možnih groženj, če se to preverjanje ne izvede.

Naslednja zgodba podrobno opisuje, kaj se lahko zgodi, če se preverjanje lastništva domene ne izvede.

Podjetje z domeno DNS, nastavljeno na »hacker.com«, kupi Webex Hybrid Services. Tudi drugo podjetje, ki ima svojo domeno nastavljeno na »example.com«, uporablja hibridne storitve. Ena od generalnih direktoric podjetja Example.com se imenuje Jane Roe in ima URI imenika jane.roe@example.com.

Skrbnica podjetja Hacker.com nastavi enega od svojih URI-jev imenika na jane.roe@example.com in e-poštni naslov za jane.roe@hacker.com. To lahko stori, ker oblak v tem primeru ne preveri domene SIP URI.

Nato se prijavi v aplikacijo Webex z jane.roe@hacker.com. Ker je lastnica domene, je potrditveno e-poštno sporočilo prebrano in nanj je odgovorjeno, ona pa se lahko prijavi. Končno pokliče kolega, Johna Doeja, tako da vtipka john.doe@example.com iz njene aplikacije Webex. Janez sedi v svoji pisarni in na videokameri vidi klic, ki prihaja od jane.roe@example.com; to je URI imenika, povezan s tem e-poštnim računom.

„V tujini je,“ si misli. "Morda potrebuje nekaj pomembnega." Javi se na telefon, lažna Jane Roe pa ga prosi za pomembne dokumente. Pojasni, da je njena naprava pokvarjena, in ker je na potovanju, ga prosi, naj ji dokumente pošlje na njen zasebni e-poštni naslov, jane.roe@hacker.com. Na ta način podjetje šele po vrnitvi Jane Roe v pisarno ugotovi, da so pomembne informacije uhajale iz 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 zagotoviti, da je identiteta vsakogar, ki kliče iz Webexa, pravilna in ne ponarejena.

Za preverjanje identitete Webex zahteva, da podjetje dokaže, da je lastnik domen, ki se uporabljajo pri hibridnih klicih. Če ne, hibridne storitve ne bodo delovale.

Za zagotovitev 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 jih morajo poznati javni strežniki DNS.

   • Za dokazovanje lastništva mora skrbnik DNS vnesti besedilni zapis DNS (TXT). Zapis TXT je vrsta zapisa vira v DNS, ki se uporablja za povezovanje poljubnega in neoblikovanega besedila z gostiteljem ali drugim imenom.

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

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

   • Na primer, skrbnik mora dokazati, da je lastnik domene »example.com«, če želi, da storitve Webex Hybrid Services delujejo na njegovi domeni.

   • Z https://admin.webex.comzačne postopek preverjanja z ustvarjanjem zapisa TXT, ki se ujema z žetonom, ki ga je ustvaril oblak Webex:

     

   • Skrbnik DNS nato za to domeno ustvari zapis TXT z vrednostjo, nastavljeno na 123456789abcdef123456789abcdef123456789abcdef123456789abcdef, 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 DNS v obliki TXT:

     

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

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

   • Oblak mora preveriti, ali ima Expressway-E potrjeno identiteto s strani enega od overiteljev potrdil, ki jim oblak zaupa. Skrbnik Expressway-E mora za svoj Expressway-E zahtevati javno potrdilo pri enem od teh overiteljev potrdil. Za izdajo potrdila overitelj izvede postopek preverjanja identitete na podlagi preverjanja domene (za potrdila, potrjena s strani domene) ali preverjanja organizacije (za potrdila, potrjena s strani organizacije).

   • Klici v oblak in iz njega so odvisni od potrdila, ki je bilo izdano za Expressway-E. Če potrdilo ni veljavno, se klic prekine.

Za delovanje hibridnega klicanja mora povezovalnik naprav Webex komunicirati z Webexom.

Webex Device Connector je nameščen v notranjem omrežju, z oblakom pa komunicira prek odhodne povezave HTTPS – iste vrste, kot se uporablja za kateri koli brskalnik, ki se povezuje s spletnim strežnikom.

Komunikacija z oblakom Webex uporablja TLS. Webex Device Connector je odjemalec TLS, Webex Cloud pa strežnik TLS. Zato Webex Device Connector preveri potrdilo strežnika.

Certifikacijski organ podpiše strežniško potrdilo z lastnim zasebnim ključem. Vsakdo z javnim ključem lahko dešifrira ta podpis in dokaže, da je isti overitelj potrdil podpisal to potrdilo.

Če mora Webex Device Connector preveriti potrdilo, ki ga zagotavlja oblak, mora za dekodiranje podpisa uporabiti javni ključ overitelja potrdil, ki je podpisal to potrdilo. Javni ključ je vsebovan v potrdilu overitelja potrdil. Za vzpostavitev zaupanja s overitelji potrdil, ki jih uporablja oblak, mora biti seznam potrdil teh zaupanja vrednih overiteljev potrdil v shrambi zaupanja vgrajenih podatkov Webex Device Connector.

Pri komunikaciji z napravami orodje uporablja zaupanja vredna potrdila, ki jih posredujete. Trenutno je to mogoče storiti tako, da jih postavite v [home folder]/.devicestool/certs.

Za Expressway-E v prečnem paru je potreben tudi seznam potrdil overitelja potrdil. Expressway-E komunicira z oblakom Webex prek protokola SIP s TLS, ki ga uveljavlja medsebojna avtentikacija. Expressway-E zaupa klicem, ki prihajajo iz oblaka in odhajajo vanj, le če se CN ali SAN potrdila, ki ga oblak predloži med nastavitvijo povezave TLS, ujema z imenom subjekta, konfiguriranim za območje DNS na Expresswayu ("callservice.webex.com"). Certifikacijski organ izda potrdilo šele po preverjanju identitete. Za podpis potrdila je treba dokazati lastništvo domene callservice.webex.com. Ker smo mi (Cisco) lastniki te domene, je ime DNS »callservice.webex.com« neposreden dokaz, da je oddaljeni vrstnik resnično Webex.

Priključek za koledar integrira Webex z Microsoft Exchange 2013, 2016, 2019 ali Office 365 prek računa za poosebljanje. Vloga upravljanja poosebljanja aplikacij v storitvi Exchange omogoča aplikacijam, da poosebijo uporabnike v organizaciji in tako izvajajo naloge v imenu uporabnika. Vloga poosebitve aplikacije mora biti konfigurirana v storitvi Exchange in se uporablja v povezovalniku koledarja kot del konfiguracije storitve Exchange v vmesniku Expressway-C.

Microsoftova priporočena metoda za to nalogo je uporaba računa za poosebljanje Exchange. Skrbniki Expressway-C ne potrebujejo gesla, ker lahko vrednost v vmesnik Expressway-C vnese skrbnik Exchange. Geslo ni jasno prikazano, tudi če ima skrbnik Expressway-C root dostop do naprave Expressway-C. Geslo je shranjeno šifrirano z istim mehanizmom šifriranja poverilnic kot druga gesla na avtocesti Expressway-C.

Za dodatno varnost sledite korakom v Vodniku za uvajanje storitve Cisco Webex Hybrid Calendar, da omogočite TLS in tako zavarujete povezave EWS na omrežju.

Za dodatno varnost sledite korakom v Uvajanje priključka za koledar Expressway za Microsoft Exchange, da omogočite TLS in zavarujete povezave EWS na omrežju.