Ovaj odeljak pruža dodatni kontekst o ključnim stavkama za konfiguraciju koje su povezane sa hibridnim uslugama.

Ove tačke su ključne ako želite uspešno da primenite hibridno pozivanje za Webex uređaje. Posebno smo istakli ove stavke iz sledećih razloga:

• Želimo da ih objasnimo, kako biste razumeli njihovu ulogu u hibridnom raspoređivanju i osećali se uverljivo.

• To su obavezni preduslovi koji obezbeđuju bezbedno raspoređivanje između našeg oblaka i vašeg lokalnog okruženja.

• Treba ih tretirati kao pre-day zero aktivnosti: može da potraje malo duže od tipične konfiguracije u korisničkom interfejsu, tako da dozvolite vremenski okvir za sortiranje ovih stavki.

• Kada se ove stavke reše u vašem okruženju, ostatak konfiguracije hibridnih usluga će funkcionisati bez problema.

Primena Expressway-C i Expressway-E para omogućava pozive ka internetu i sa njega koristeći tehnologije za prelazak zaštitnog zida. Ova implementacija je ono što bezbedno preuzima vašu lokalnu kontrolu poziva i povezuje je sa aplikacijom Webex.

Expressway-C i Expressway-E ne zahtevaju da se bilo koji dolazni port otvori u demilitarizovanom zonom (DMZ) zaštitnom zidu zbog arhitekture trasalnog zaštitnog zida. Međutim, TCP SIP portovi za signalizaciju i UDP medijski portovi moraju biti otvoreni dolazni na Internet zaštitnom zidu da bi dolazni pozivi došli. Morate dozvoliti vreme da se odgovarajući port otvori na poslovnom zaštitnom zidu.

Arhitektura pređenog zida prikazana je u sledećem dijagramu:

Na primer, za dolazne poslovne (B2B) pozive pomoću SIP protokola, TCP portovi 5060 i 5061 (5061 se koriste za SIP TLS) moraju biti otvoreni na spoljnom zaštitnom zidu, zajedno sa UDP portovima medija koji se koriste za usluge kao što su glas, video zapisi, deljenje sadržaja, dvostruki video zapis i slično. Koji medijski portovi za otvaranje zavise od broja uporednih poziva i broja usluga.

SiP port za slušanje na Expressway-u možete da konfigurišete tako da bude bilo koja vrednost između 1024 i 65534. Istovremeno, ova vrednost i tip protokola moraju da se reklamiraju u javnim DNS SRV zapisima, a ista ta vrednost mora biti otvorena i na Internet zaštitnom zidu.

Iako je standard za SIP TCP 5060, a za SIP TLS 5061, ništa ne sprečava upotrebu različitih portova, kao što pokazuje sledeći primer.

Primer

U ovom primeru pretpostavljamo da se port 5062 koristi za dolazne SIP TLS pozive.

DNS SRV zapis za klaster dva Expressway servera izgleda ovako:

_sips._tcp.example.com lokacija SRV usluge:

prioritet = 10

težina = 10

luka = 5062

svr hostname = us-expe1.example.com

_sips._tcp.example.com lokacija SRV usluge:

prioritet = 10

težina = 10

luka = 5062

svr hostname = us-expe2.example.com

Ovi zapisi znače da su pozivi usmereni na us-expe1.example.com i us-expe2.example.com sa jednakim deljenjem opterećenja (prioritet i težina) koristeći TLS kao vrstu transporta i 5062 kao broj porta za slušanje.

Uređaj koji je spoljni za mrežu (na Internetu) i koji poziva SIP korisniku korporativnog domena (user1@example.com) mora da ispita DNS da bi razumeo koji tip transporta da koristi, broj porta, kako da učita saobraćaj i na koje SIP servere da pošalje poziv.

Ako stavka DNS-a _sipsuključuje . . ._tcp

TLS je protokol klijent-server i, u najčešćim implementacijama, koristi certifikate za potvrdu identiteta. U scenariju poslovnog poziva, TLS klijent je uređaj za pozivanje, a TLS server se zove uređaj. Pomoću TLS-a klijent proverava certifikat servera i ako provera certifikata ne uspe, prekida poziv. Klijentu nije potreban certifikat.

TLS rukovanje je prikazano u sledećem dijagramu:

Međutim, TLS specifikacija navodi da server takođe može da proveri certifikat klijenta slanjem poruke zahteva za certifikat klijentu tokom TLS protokola rukovanja. Ova poruka je korisna na vezi sa serverom-na-server, kao što je poziv koji je uspostavljen između Expressway-E i Webex oblaka. Ovaj koncept se zove TLS sa međusobnom potvrdom identiteta i potreban je prilikom integracije sa aplikacijom Webex.

I pozvane i pozvane strane proveravaju certifikat drugog ravnopravnog uređaja, kao što pokazuje sledeći dijagram:

Oblak proverava identitet Ekspresveja, a Expressway proverava identitet oblaka. Na primer, ako se identitet u oblaku u certifikatu (CN ili SAN) ne podudara sa onim što je konfigurisano na Expressway-u, veza će biti odbačena.

Ako je uključena međusobna potvrda identiteta, Expressway-E uvek zahteva certifikat klijenta. Kao rezultat toga, mobilni i daljinski pristup (MRA) neće funkcionisati, jer u većini slučajeva certifikati nisu raspoređeni na Jabber klijentima. U poslovnom scenariju, ako entitet poziva ne može da obezbedi certifikat, poziv je prekinut.

Preporučujemo da koristite vrednost koja nije 5061 za TLS sa međusobnom potvrdom identiteta, kao što je port 5062. Webex hibridne usluge koriste isti SIP TLS zapis koji se koristi za B2B. U slučaju porta 5061, neke druge usluge koje ne mogu da obezbede TLS certifikat klijenta neće funkcionisati.

Ako se postojeći zapis već koristi za poslovne komunikacije, preporučujemo da kao SIP odredište u Kontrolnom čvorištu, a zatim i javni DNS SRV zapis, na sledeći način:

 Usluga i protokol: _sips._tcp.mtls.example.com Prioritet: 1 Тежине: 10 Broj porta: 5062 Cilj: us-expe1.example.com 

Poslovni, mobilni i daljinski pristup i Webex saobraćaj u istom Expressway paru

Business-to-business (B2B) i mobilni i daljinski pristup (MRA) pozivi koriste port 5061 za SIP TLS, a Webex saobraćaj koristi port 5062 za SIP TLS sa međusobnom potvrdom identiteta.

Provera vlasništva nad domenom je deo provere identiteta. Potvrda domena je bezbednosna mera i provera identiteta koju Webex cloud sprovodi da bi dokazao da ste ono što se kaže da ste.

Provera identiteta se vrši u dve faze:

1. Provera vlasništva nad domenom. Ovaj korak uključuje tri tipa domena i to je provera jedne provere:

   • Domen e-pošte

   • Expressway-E DNS domen

   • URI domen direktorijuma

2. Provera vlasništva nad Imenom Expressway-E DNS. Ovaj korak se izvodi kroz implementaciju TLS-a uz međusobnu potvrdu identiteta i podrazumeva korišćenje javnih sertifikata i na oblaku i na Ekspresveju. Za razliku od provere identiteta domena, ovaj korak se izvršava tokom poziva koji se obavi i primi iz oblaka.

Značaj provere vlasništva nad domenom

Webex oblak obavlja proveru vlasništva nad domenom kako bi se primenila bezbednost. Krađa identiteta je jedna od mogućih pretnji ako se ova provera ne izvrši.

Sledeća priča detaljno opisuje šta može da se desi ako se ne izvrši provera vlasništva nad domenom.

Kompanija sa DNS domenom podešenim na „hacker.com“ kupuje Webex hibridne usluge. Druga kompanija, sa sopstvenim domenom podešenim na "example.com", takođe koristi hibridneusluge. Jedna od generalnih direktorka kompanije se Example.com Džejn Ro i ima direktorijum URI jane.roe@example.com.

Administrator kompanije Hacker.com od njenih korisničkih naloga za imenike da jane.roe@example.com i e-adresu na jane.roe@hacker.com. Ona to može da uradi jer oblak u ovom primeru ne proverava SIP URI domen.

Potom se prijavljuje u aplikaciju Webex pomoću adrese jane.roe@hacker.com. Pošto je vlasnica domena, verifikaciona e-pošta se čita i odgovara, i može da se prijavi. Na kraju, ona pozove kolegu, Džona Doa, biranjem broja john.doe@example.com iz aplikacije Webex. Džon sedi u svojoj kancelariji i vidi poziv na video uređaju koji dolazi sa jane.roe@example.com; to je URI direktorijuma povezan sa tim nalogom e-pošte.

"Ona je u inostranstvu", misli on. "Možda će joj trebati nešto važno." Javlja se na telefon, a lažna Džejn Ro traži važna dokumenta. Ona objašnjava da joj je uređaj pokvaren, a pošto putuje, traži od njega da pošalje dokumenta na njenu privatnu imejl adresu, jane.roe@hacker.com. Na ovaj način, kompanija shvata tek kada se Džejn Ro vrati u kancelariju da su važne informacije procurele van kompanije.

Kompanija Example.com ima mnogo načina da se zaštiti od zlonamernih poziva koji dolaze sa interneta, ali jedna od odgovornosti Webex oblaka je da se osigura da je identitet osobe koja poziva sa Webexa tačan i da ne bude falsifikovan.

Da bi proverio identitet, Webex zahteva da kompanija dokaže da je vlasnik domena koji se koriste u hibridnom pozivanju. Ako se to ne dogodi, hibridne usluge neće funkcionisati.

Da biste obezbedili ovo vlasništvo, potrebna su dva koraka provere domena:

1. Dokaži da je kompanija vlasnik domena e-pošte, Expressway-E domena, direktorijuma URI domena.

   • Svi ti domeni moraju biti usmeravani i poznati od strane javnih DNS servera.

   • Da bi dokazao vlasništvo, DNS administrator mora da unese zapis DNS teksta (TXT). TXT zapis je vrsta zapisa resursa u DNS-u koji se koristi za obezbeđivanje mogućnosti povezivanja nekog proizvoljnog i neoblikovanog teksta sa domaćinom ili drugim imenom.

   • DNS administrator mora uneti taj TXT zapis u zonu čije vlasništvo mora biti dokazano. Nakon tog koraka, Webex oblak obavlja upit za TXT zapis za taj domen.

   • Ako je TXT upit uspešan i rezultat se podudara sa tokenom koji je generisan iz Webex oblaka, domen je potvrđen.

   • Kao primer, administrator mora da dokaže da je vlasnik domena „example.com“ ako želi da Webex hibridne usluge rade na njenom domenu.

   • Putem https://admin.webex.com, pokreće proces verifikacije kreiranjem TXT zapisa koji će odgovarati tokenu koji je Webex oblak generisao:

     

   • DNS administrator zatim kreira TXT zapis za ovaj domen sa vrednošću postavljenom na 123456789abcdef123456789abcdef123456789abcdef123456789abcdef, kao u sledećem primeru:

     

   • U ovom trenutku, oblak može da potvrdi da se TXT zapis za example.com podudara sa simbolom.

   • Oblak izvršava TXT DNS pronalaženje:

     

   • Pošto se TXT vrednost podudara sa vrednošću simbola, ovo podudaranje dokazuje da je administrator dodao TXT zapis za sopstveni domen javnom DNS-u i da je ona vlasnik domena.

2. Provera vlasništva nad Imenom Expressway-E DNS.

   • Oblak mora da proveri da li Expressway-E ima potvrđen identitet od jednog od autoriteta za izdavanje sertifikata kome cloud veruje. Administrator Expressway-E mora da zatraži javni sertifikat za svoj Expressway-E jednom od tih autoriteta za izdavanje sertifikata. Da bi izdao certifikat, autoritet za proveru identiteta izvršava proces provere identiteta, na osnovu provere valjanosti domena (za certifikate proverenog domena) ili provere valjanosti organizacije (za certifikate proverene organizacije).

   • Pozivi u oblak i iz oblaka zavise od certifikata koji je izdat Expressway-E. Ako certifikat nije važeći, poziv je odbačen.

Webex konektor uređaja mora da komunicira sa aplikacijom Webex da bi hibridno pozivanje radilo.

Webex konektor uređaja se raspoređuje na internoj mreži, i način na koji komunicira sa oblakom odvija se putem odlazne HTTPS veze – isti tip koji se koristi za bilo koji pregledač koji se povezuje sa veb-serverom.

Komunikacija sa Webex oblakom koristi TLS. Webex konektor uređaja je TLS klijent, a Webex oblak je TLS server. Zbog toga Webex konektor uređaja proverava sertifikat servera.

Autoritet za izdavanje certifikata potpisuje certifikat servera koristeći sopstveni privatni ključ. Svako ko ima javni ključ može da dešifruje taj potpis i dokaže da je isti autoritet za izdavanje certifikata potpisao taj certifikat.

Ako Webex konektor uređaja mora da proveri valjanost sertifikata koji je obezbedio oblak, on mora da koristi javni ključ autoriteta za izdavanje sertifikata koji je potpisao taj sertifikat za dekodiranje potpisa. Javni ključ se nalazi u certifikatu autoriteta za izdavanje certifikata. Da biste uspostavili poverenje sa autoritetima za izdavanje sertifikata koje koristi oblak, lista sertifikata ovih autoriteta pouzdanih sertifikata mora da bude u skladištu pouzdanih sertifikata Webex Device Connector.

Kada komunicirate sa uređajima, alatka koristi pouzdane certifikate koje obezbedite. Trenutno je način da se to uradi tako što ćete ih staviti u [home fasciklu]/.devicestool/certs.

Lista certifikata autoriteta za izdavanje certifikata je takođe potrebna za Expressway-E u prelaznom paru. Expressway-E komunicira sa Webex oblakom koristeći SIP sa TLS-om, koji se sprovodi međusobnom potvrdom identiteta. Expressway-E veruje da pozivi koji dolaze iz oblaka i koji odlaze u oblak, samo ako se CN ili SAN sertifikata koji je predstavio oblak tokom podešavanja TLS veze podudara sa imenom subjekta konfigurisanim za DNS zonu na mrežnom prolazu Expressway („callservice.webex.com“). Autoritet za izdavanje certifikata objavljuje certifikat tek nakon provere identiteta. Neophodno je da se dokaže vlasništvo nad domenom callservice.webex.com da bi se dobio potpisani sertifikat. S obzirom na to da smo (Cisco) vlasnik tog domena, DNS ime „callservice.webex.com“ je direktan dokaz da je udaljeni birač zaista Webex.

linija spajanja kalendara integriše Webex sa Microsoft Exchange 2013, 2016, 2019 ili Office 365 putem naloga za imitiranje. Uloga upravljanja imitiranje aplikacija u programu Exchange omogućava aplikacijama da imitiraju korisnike u organizaciji za izvršavanje zadataka u ime korisnika. Uloga imitiranja aplikacije mora biti konfigurisana u Exchange serveru i koristi se u kalendarskoj liniji spajanja kao deo konfiguracije Exchange servera na Expressway-C interfejsu.

Exchange nalog za imitaciju je metod koji preporučuje Microsoft za ovaj zadatak. Administratori Expressway-C ne moraju da znaju lozinku, jer administrator Exchange servera može da unese vrednost u interfejs Expressway-C. Lozinka nije jasno prikazana, čak i ako administrator Expressway-C ima osnovni pristup Expressway-C kutiji. Lozinka je uskladištena šifrovana pomoću istog mehanizma šifrovanja akreditiva kao i druge lozinke na Expressway-C.

Za dodatnu bezbednost, pratite korake u Uputstvu za upotrebu za Cisco Webex Hybrid Calendar Service kako biste omogućili TLS kako biste osigurali EWS veze na žici.

Za dodatnu bezbednost, pratite korake u Konektoru za implementaciju ekspresnog kalendara za Microsoft Exchange da biste omogućili TLS kako biste obezbedili EWS veze na žici.