Ta razdelek vsebuje dodan kontekst o ključnih postavkah konfiguracije, ki se nanašajo na hibridne storitve.

Te točke so ključnega pomena, če želite uspešno uvajati hibridno klicanje za naprave Webex. Te elemente smo poudarili zlasti iz naslednjih razlogov:

• Želimo jih razložiti, tako da boste razumeli njihovo vlogo pri hibridnem uvajanju in se počutili pomirjeni.

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

• Treba jih je obravnavati kot preddnevne ničelne dejavnosti: dokončanje lahko traja nekoliko dlje kot običajna konfiguracija v uporabniškem vmesniku, zato omogočite časovni okvir za razvrščanje teh elementov.

• Ko so ti elementi obravnavani v vašem okolju, bo preostala konfiguracija hibridnih storitev potekala brez težav.

Uvajanje parov Expressway-C in Expressway-E omogoča klice v internet in z njega z uporabo tehnologij za prehod požarnega zi du. Ta uvajanje je tisto, kar varno prevzame nadzor nad vašim krajevnim klicem in ga poveže z Webexom.

Expressway-C in Expressway-E ne zahtevata odpiranja vhodnih vrat v požarnem zi du demilitarizirane cone (DMZ) zaradi arhitekture prehoda požarnega zidu. Toda signalna vrata TCP SIP in medijska vrata UDP morajo biti odprta vhodno v internetnem požarnem zidu, da se omogoči prehod dohodnih klicev. Dovol iti morate čas, da se v požarnem zidu podjetja odprejo ustrezna vrata.

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

Na primer, za dohodne klice med podjetji (B2B), ki uporabljajo protokol SIP, je treba na zun anjem požarnem zidu odpreti 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, skupna raba vsebine, dvojni video itd. Katera medijska vrata je treba odpre ti, je odvisno od števila sočasnih klicev in števila storitev.

Vrata za poslušanje SIP na hitri cesti lahko konfigurirate tako, da imajo polju bno vrednost med 1024 in 65534. Hkrati je treba to vrednost in vrsto protokola oglaševati v javnih DNS SRV evidencah, isto vrednost pa je treba odpreti v 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 predvidevamo, da se vrata 5062 uporabljajo za dohodne klice SIP TLS.

Zap DNS SRV is za skupino dveh strežnikov Expressway izgleda takole:

_požirki. _tcp.example .com SRV lokacija storitve:

priority = 10

weight = 10

port = 5062

ime gostitelja svr = us-expe1.example.com

_požirki. _tcp.example .com SRV lokacija storitve:

priority = 10

weight = 10

port = 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 (prednost in teža) z uporabo TLS kot vrste prevoza in 5062 kot številke poslušalnih vrat.

Naprava, ki je zunaj omrežja (v internetu) in ki kliče SIP uporabniku poslovne domene (user1@example.com), mora poiskati DNS, da bi razumela, katero vrsto prevoza uporabiti, številko vrat, kako naložiti in deliti promet in na katere strežnike SIP pošiljati klic.

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

TLS je protokol odjemalca in strežnika in v najpogostejših izvedbah uporablja potrdila za preverjanje pristnosti. V scenariju klica med podjetji je odjemalec TLS klicna naprava, strežnik TLS pa klicana naprava. S programom TLS odjemalec preveri potrdilo strežnika in če preverjanje potr dila ne uspe, klic prekine . Naročnik ne potrebuje potrdila.

TLS stiskanje roke je prikazano na naslednjem diagramu:

Vendar pa specifikacija TLS navaja, da lahko strež nik potrdilo odjemalca preveri tudi tako, da med protokolom TLS stiskanja roke odjemalcu pošlje sporočilo o zahtevi za potrdilo. To sporočilo je koristno pri povezavi med strež nikom med strežnikom, na primer ob klicu, ki je vz postavljena med Expressway-E in oblakom Webex. Ta koncept se imenuje TLS z medsebojno preverjanjem pri stnosti in je potreben pri integraciji z Webexom.

Tako klicajoče kot poklicane stranke preverjajo potrdilo drugega vrstnika, kot kaže naslednji diagram:

Oblak preveri identiteto hitre ceste, Expressway pa identiteto v oblaku. Če se na primer identiteta v oblaku v certifikatu (CN ali SAN) ne ujema s konfiguracijo na avtocesti, povezava prekine.

Če je medsebojno preverjanje pristnosti vklopljeno, Expressway-E vedno zahteva potrdilo odjemalca. Posledično Mobile in Remote Access (MRA) ne bosta delovala, ker v večini primerov certifikati niso nameščeni na odjemalcih Jabber . Če klicajoči subjekt ne more predložiti potrdila v scenariju med podjetji, je kli c prekinjen.

Priporočamo, da za TLS z medsebojno preverjanjem pristnosti uporabite vrednost, ki ni 5061, kot je vrata 5062. Webex Hybrid Services uporablja isti zapis SIP TLS, ki se uporablja za B2B. V primeru pristanišča 5061 nekatere druge storitve, ki ne morejo zagotoviti potrdila odjemalca TLS, ne bodo delovale.

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

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

Poslovno-poslovni promet, mobilni Remote Access in Webex promet na istem paru hitrih cest

Klici med podjetji (B2B) ter mobilni in Remote Access (MRA) klici uporabljajo vrata 5061 za SIP TLS, Webex promet pa uporablja vrata 5062 za SIP TLS z medsebojno preverjanjem pristnosti.

Preverjanje lastništva domene je del preverjanja identitete. Preverjanje domene je varnostni ukrep in preverjanje identitete, ki ga oblak Webex izvaja, da dokaže, da ste to, za kar pravite, da ste.

Preverjanje identitete poteka v dveh fazah:

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

   • E-poštna domena

   • Domena Expressway-E DNS

   • Domena URI imenika

2. Preverjanje lastništva imena Expressway-E DNS. Ta korak se izvede z izvajanjem TLS z medsebojno preverjanjem pristnosti in vključuje uporabo javnih potrdil tako v oblaku kot na hitri cesti. Za razliko od preverjanja identitete domene se ta korak izvede med vsakim klicem, opravljenim v oblak in prejetim iz njega.

Pomen preverjanja lastništva domene

Oblak Webex opravi 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 preverjanje lastništva domene ne bo izvedeno.

Podjetje z domeno DNS, nastavljeno na »hacker.com«, kupi Webex Hybrid Services. Drugo podjetje z lastno domeno nastavljeno na »example.com« uporablja tudi hibridne storitve. Eden od generalnih direktorjev podjetja Example.com se imenuje Jane Roe in ima imenik URI jane.roe@example.com.

Administratorka podjetja Hacker.com določi enega od svojih URI-jev imenika na jane.roe@example.com, e-poštni naslov pa na 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, se e-poštno sporočilo za preverjanje pre bere in odgovori ter se lahko prijavi. Nazadnje pokliče kolega Johna Doeja tako, da pokliče john.doe@example.com iz svoje aplikacije Webex. John sedi v svoji pisarni in vidi klic na svoji video napravi, ki prihaja s strani jane.roe@example.com; to je URI imenika, povezan s tem e-poštnim računom.

»Je v tujini,« misli. Morda bo potrebovala nekaj pomembnega.« Odgovori se na telefon, ponarejena Jane Roe pa prosi za pomembne dokumente. Pojasnjuje, da je njena naprava pokvarjena in ker potuje, ga prosi, naj dokumente pošlje na njen zasebni e-poštni naslov jane.roe@hacker.com. Tako podjetje šele potem, ko se Jane Roe vrne v pisarno, spozna, da so pomembne informacije uhajale zunaj 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 v hibridnem klicanju. Če ne, 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, domene URI imenika.

   • Vse te domene morajo biti usmerljive in jih poznajo javni strežniki DNS.

   • Če želite dokazati lastništvo, mora skrbnik DNS vnesti besedilni zapis DNS (TXT). Zapis TXT je vrsta zapisa virov v DNS, ki se uporablja za zagotavljanje možnosti povezovanja poljubnega in neformatiranega besedila z gostiteljem ali drugim imenom.

   • Skrbnik DNS mora vnesti ta zapis TXT v območje, katerega lastništvo mora biti dokazano. Po tem koraku oblak Webex izvede poizvedbo o zapisu TXT za to domeno.

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

   • Kot primer mora skrbnik dokazati, da je lastnik domene »example.com«, če želi, da Webex Hybrid Services deluje na njeni domeni.

   • Preko https://admin.webex.com začne postopek preverjanja tako, da ustvari zapis TXT, ki se ujema z žetonom, ki ga je ustvaril oblak Webex:

     

   • Skrbnik DNS nato ustvari zapis TXT za to domeno z vrednostjo nastavljeno na 123456789abcdef123456789abcdef 123456789abcdef123456789abcdef, 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 skrbnik dodal zapis TXT za svojo domeno v javni DNS in da je lastnica domene.

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

   • Oblak mora preveriti, ali ima Expressway-E potrjeno identiteto enega od certifikacijskih organov, ki jim oblak zaupa. Upravitelj Expressway-E mora zahtevati javno potrdilo za svoj Expressway-E pri enem od teh organov za certificiranje. Za izdajo potrdila organ za potrdilo izvede postopek preverjanja identitete, ki temelji na preverjanju veljavnosti domene (za potrdila, potrjena z domeno) ali preverjanju validacije organizacije (za potrdila, potrjena organizacije).

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

Priključek naprave Webex mora komunicirati z Webexom, da lahko hibridno klicanje deluje.

Webex Device Connector je nameščen v notranjem omrežju, način komuniciranja z oblakom pa je prek izhodne povezave HTTPS — iste vrste, ki se uporablja za kateri koli brskalnik , ki se poveže s spletnim strežnikom.

Komunikacija z oblakom Webex uporablja TLS. Webex Device Connector je odjemalec TLS, oblak Webex pa strežnik TLS. Kot tak Webex Device Connector preveri potrdilo strežnika.

Certifikacijski organ podpiše potrdilo strežnika z lastnim zasebnim ključem. Vsakdo, ki ima javni ključ, lahko ta podpis dekodira in dokaže, da je isti certifikacijski organ podpisal to potrdilo.

Če mora Webex Device Connector potrditi potrdilo, ki ga je zagotovil oblak, mora za dekodiranje podpisa uporabiti javni ključ organa za potrdilo, ki je podpisal potrdilo. Javni ključ je vsebovan v potrdilu organa za potrdilo. Če želite vzpostaviti zaupanje organom za certifikate, ki jih uporablja oblak, mora biti seznam potrdil teh zaupanja vrednih certifikatov v trgovini zaupanja Webex Device Connector.

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

Seznam certifikatov certifikatov je potreben tudi za Expressway-E v prevoznem paru . Expressway-E komunicira z oblakom Webex z uporabo SIP s TLS, ki ga uveljavlja medsebojno preverjanje pristnosti. Expressway-E zaupa klicem, ki prihajajo iz oblaka in odhajajo v oblak, le če se CN ali SAN potrdila, ki ga oblak predstavi med nastavitvijo povezave TLS, ujema z imenom teme, konfiguriranim za območje DNS na Expressway (»callservice.webex.com«). Organ za potrdilo izda potrdilo šele po preverjanju identitete. Za podpisovanje potrdila je treba dokazati lastništvo domene callservice.webex.com. Ker smo lastniki te domene (Cisco), je ime DNS »callservice.webex.com« neposreden dokaz, da je oddaljeni vrstnik resnično Webex.

Koledar priključek združuje Webex s storit Microsoft Exchange vami 2013, 2016, 2019 ali Office 365 prek računa za lažno predstavljanje. Vloga upravljanja lažnega predstavljanja aplikacij v Exchangeu omogoča aplikacijam, da se predstavljajo za uporabnike v organizaciji za izvajanje nalog v imenu uporabnika. Vloga predstavljanja aplikacije mora biti konfigurirana v Exchangeu in se uporablja v priključku koledarja kot del konfiguracije Exchange na vmesniku Expressway-C.

Račun za lažno predstavljanje Exchange je Microsoftova priporočena metoda za to nalogo. Skrbnikom Expressway-C gesla ni treba poznati, ker lahko vrednost v vmesnik Expressway-C vnese skrbnik Exchange. Geslo ni jasno prikazano, tudi če ima skrbnik Expressway-C root dostop do polja Expressway-C. Geslo je shranjeno šifrirano z istim mehanizmom šifriranja poverilnic kot druga gesla na Expressway-C.

Za dodatno varnost sledite korakom iz Vodnika za uvajanje Cisco Webex hibridne koledar storitve, da omogočite TLS za zaščito povezav EWS na žici.

Za dodatno varnost sledite navodilom v razdelku Nam esti priključek za koledar hitre ceste, Microsoft Exchange da omogočite TLS za zaščito povezav EWS na žici.