Această secțiune oferă context suplimentar despre elementele cheie de configurare care se referă la serviciile hibride.

Aceste puncte sunt cruciale dacă doriți să implementați cu succes apelarea hibridă pentru dispozitivele Webex. Am evidențiat aceste elemente în special din următoarele motive:

• Vrem să le explicăm, astfel încât să înțelegeți rolul lor într-o implementare hibridă și să vă simțiți liniștiți.

• Acestea sunt condiții prealabile obligatorii care asigură o implementare sigură între cloud-ul nostru și mediul dvs. local.

• Acestea ar trebui tratate ca activități zero înainte de zi: pot dura puțin mai mult decât configurația obișnuită într-o interfață cu utilizatorul, deci permiteți un interval de timp pentru a sorta aceste elemente.

• După ce aceste elemente sunt abordate în mediul dvs., restul configurației serviciilor hibride va merge fără probleme.

Implementarea perechilor Expressway-C și Expressway-E permite apeluri către și de la Internet folosind tehnologii de traversare firewall. Această implementare este ceea ce preia în siguranță controlul apelurilor locale și îl conectează la Webex.

Expressway-C și Expressway-E nu necesită deschiderea unui port de intrare în paravanul de protecție a zonei demilitarizate (DMZ) din cauza arhitecturii de traversare a firewall-ului. Dar porturile de semnalizare TCP SIP și porturile media UDP trebuie deschise la intrare pe firewall-ul Internet pentru a permite apelurilor primite să treacă. Trebuie să acordați timp pentru ca portul corespunzător să fie deschis pe firewall-ul întreprinderii.

Arhitectura de traversare a firewall-ului este prezentată în următoarea diagramă:

De exemplu, pentru apelurile de intrare business-to-business (B2B) care utilizează protocolul SIP, porturile TCP 5060 și 5061 (5061 este utilizat pentru SIP TLS) trebuie deschise pe firewall-ul extern, împreună cu porturile media UDP utilizate pentru servicii precum voce, video, partajare de conținut, video dual și așa mai departe. Ce porturi media să deschidă depinde de numărul de apeluri concomitente și de numărul de servicii.

Puteți configura portul de ascultare SIP de pe Expressway pentru a fi orice valoare între 1024 și 65534. În același timp, această valoare și tipul de protocol trebuie să fie anun țate în DNS SRV înregistrările publice și aceeași valoare trebuie deschisă pe paravanul de protecție Internet.

Deși standardul pentru SIP TCP este 5060 și pentru SIP TLS 5061, nimic nu împiedică utilizarea diferitelor porturi, după cum arată exemplul următor.

Exemplu

În acest exemplu, presupunem că portul 5062 este utilizat pentru apelurile SIP TLS de intrare.

În DNS SRV registrarea pentru un cluster de două servere Expressway arată astfel:

_înghițituri. _tcp.example .com Locația serviciului SRV:

priority = 10

weight = 10

port = 5062

svr nume de gazdă = us-expe1.example.com

_înghițituri. _tcp.example .com Locația serviciului SRV:

priority = 10

weight = 10

port = 5062

svr nume de gazdă = us-expe2.example.com

Aceste înregistrări înseamnă că apelurile sunt direcționate către us-expe1.example.com și us-expe2.example.com cu o partajare egală a sarcinii (prioritate și greutate) folosind TLS ca tip de transport și 5062 ca număr de port de ascultare.

Un dispozitiv extern rețelei (pe Internet) și care efectuează un apel SIP către un utilizator al domeniului corporativ (user1@example.com) trebuie să interogeze DNS pentru a înțelege ce tip de transport să utilizeze, numărul portului, modul de încărcare a traficului și serverele SIP către care să trimită apelul.

Dacă intrarea DNS include _sips. _tcp, intrarea specifică SIP TLS.

TLS este un protocol client-server și, în cele mai comune implementări, folosește certificate pentru autentificare. Într-un scenariu de apel business-to-business, clientul TLS este dispozitivul apelant, iar server ul TLS este dispozitivul apelat. Cu TLS, clientul verifică certificatul serverului și, dacă verificarea certific atului eșuează, deconectează apelul . Clientul nu are nevoie de un certificat.

Strângerea de mână TLS este prezentată în următoarea diagramă:

Cu toate acestea, specificația TLS afirmă că serverul poate verifica, de asemenea, certificatul client trimițând un mesaj de solicitare de certificat către client în timpul protocolului de strângere de mână TLS. Acest mesaj este util într-o conexiune server-server, cum ar fi apelul stabilit între Expressway-E și cloud-ul Webex. Acest concept se numește TLS cu autentificare reciprocă și este necesar atunci când se integrează cu Webex.

Atât părțile apelante, cât și cele apelate verifică certific atul celuilalt coleg, după cum arată următoarea diagramă:

Cloudul verifică identitatea Expressway, iar Expressway verifică identitatea cloud. De exemplu, dacă identitatea cloud din certificat (CN sau SAN) nu corespunde cu cea configurată pe Expressway, conexiunea este întreruptă.

Dacă autentificarea reciprocă este activată, Expressway-E solicită întotdeauna certificatul clientului. Drept urmare, Mobile și Remote Access (MRA) nu vor funcționa, deoarece, în majoritatea cazurilor, certificatele nu sunt implementate pe clienții Jabber . Într-un scenariu business-to-business, dacă entitatea apelantă nu este în măsură să furnizeze un certificat, apelul este deconectat.

Vă recomandăm să utilizați o altă valoare decât 5061 pentru TLS cu autentificare reciprocă, cum ar fi portul 5062. Serviciile hibride Webex utilizează aceeași înregistrare SIP TLS utilizată pentru B2B. În cazul portului 5061, unele alte servicii care nu pot furniza un certificat client TLS nu vor funcționa.

Dacă o înregistrare existentă este deja utilizată pentru comunic ările între întreprinderi, vă recomandăm să specificați un subdomeniu al domeniului corporativ ca destinație SIP în Control Hub și, în consecință, o DNS SRV înregistrare publică, după cum urmează:

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

Trafic business-to-business, mobil Remote Access și Webex pe aceeași pereche Expressway

Apelurile Business-to-Business (B2B) și Mobile și Remote Access (MRA) utilizează portul 5061 pentru SIP TLS, iar traficul Webex utilizează portul 5062 pentru SIP TLS cu autentificare reciprocă.

Verificarea proprietății domeniului face parte din verificarea identității. Verificarea domeniului este o măsură de securitate și o verificare a identității pe care cloud-ul Webex o implementează pentru a dovedi că ești cine spui că ești.

Verificarea identității se efectuează în două etape:

1. Verificarea proprietății domeniului. Acest pas implică trei tipuri de domenii și este o verificare unică de verificare:

   • Domeniul de e-mail

   • Domeniul DNS Expressway-E

   • Domeniu URI director

2. Verificarea proprietății numelui DNS Expressway-E. Acest pas se realizează prin implementarea TLS cu autentificare reciprocă și implică utilizarea certificatelor publice atât pe cloud, cât și pe Expressway. Spre deosebire de verificarea identității domeniului, acest pas este efectuat în timpul oricărui apel efectuat și primit din cloud.

Importanța verificării proprietății domeniului

Cloudul Webex efectuează verificarea proprietății domeniului pentru a impune securitatea. Furtul de identitate este o posibilă amenințare dacă această verificare nu este efectuată.

Următoarea poveste detaliază ce s-ar putea întâmpla dacă nu se efectuează o verificare a proprietății domeniului.

O companie cu domeniu DNS setat la „hacker.com” cumpără Webex Hybrid Services. O altă companie, cu propriul domeniu setat la „example.com”, folosește, de asemenea, servicii hibride. Unul dintre directorii generali ai companiei Example.com se numește Jane Roe și are directorul URI jane.roe@example.com.

Administratorul companiei Hacker.com stabilește unul dintre URI-urile sale de director la jane.roe@example.com și adresa de e-mail la jane.roe@hacker.com. Ea poate face asta deoarece cloud-ul nu verifică domeniul URI SIP în acest exemplu.

Apoi, se conectează la aplicația Webex cu jane.roe@hacker.com. Deoarece deține domeniul, e-mailul de verificare este citit și răspuns, iar ea se poate conecta. În cele din urmă, ea face un apel unui coleg, John Doe, apelând john.doe@example.com din aplicația Webex. John stă în biroul său și vede un apel pe dispozitivul său video venind de la jane.roe@example.com; acesta este directorul URI asociat contului de e-mail respectiv.

„Ea este în străinătate”, se gândește el. S-ar putea să aibă nevoie de ceva important.” El răspunde la telefon, iar falsa Jane Roe cere documente importante. Ea explică că dispozitivul ei este defect și, pentru că călătorește, îi cere să trimită documentele la adresa ei de e-mail privată, jane.roe@hacker.com. În acest fel, compania își dă seama abia după ce Jane Roe se întoarce la birou că informații importante au fost scurse în afara companiei.

Compania Example.com are multe modalități de a proteja împotriva apelurilor frauduloase provenite de pe Internet, dar una dintre responsabilitățile cloud-ului Webex este să se asigure că identitatea oricui apelează de la Webex este corectă și nu falsificată.

Pentru a verifica identitatea, Webex solicită companiei să dovedească faptul că deține domeniile utilizate în Hybrid Calling. Dacă nu, serviciile hibride nu vor funcționa.

Pentru a asigura această proprietate, sunt necesari cei doi pași de verificare a domeniului:

1. Dovedește că compania deține domeniul de e-mail, domeniul Expressway-E, domeniul URI Directory.

   • Toate aceste domenii trebuie să fie rutabile și cunoscute de serverele DNS publice.

   • Pentru a dovedi proprietatea, administratorul DNS trebuie să introducă o înregistrare Text DNS (TXT). O înregistrare TXT este un tip de înregistrare a resurselor din DNS utilizat pentru a oferi posibilitatea de a asocia un text arbitrar și neformatat cu o gazdă sau alt nume.

   • Administratorul DNS trebuie să introducă acea înregistrare TXT în zona a cărei proprietate trebuie dovedită. După acest pas, cloud-ul Webex efectuează o interogare de înregistrare TXT pentru acel domeniu.

   • Dacă interogarea TXT are succes și rezultatul se potrivește cu jetonul generat din norul Webex, domeniul este verificat.

   • De exemplu, administratorul trebuie să demonstreze că deține domeniul „example.com”, dacă dorește ca Webex Hybrid Services să funcționeze pe domeniul său.

   • Prin https://admin.webex.com, ea începe procesul de verificare prin crearea unei înregistrări TXT pentru a se potrivi cu jetonul generat de cloud Webex:

     

   • Administratorul DNS creează apoi o înregistrare TXT pentru acest domeniu cu valoarea setată la 123456789abcdef123456789abcdef 123456789abcdef123456789abcdef, ca în exemplul următor:

     

   • În acest moment, norul poate verifica dacă înregistrarea TXT pentru domeniul example.com se potrivește cu jetonul.

   • Norul efectuează o căutare DNS TXT:

     

   • Deoarece valoarea TXT se potrivește cu valoarea jetonului, această potrivire dovedește că administratorul a adăugat înregistrarea TXT pentru propriul domeniu la DNS-ul public și că deține domeniul.

2. Verificarea proprietății numelui DNS Expressway-E.

   • Cloud-ul trebuie să verifice dacă Expressway-E are o identitate confirmată de la una dintre autoritățile de certificare în care cloud are încredere. Administratorul Expressway-E trebuie să solicite un certificat public pentru Expressway-E-ul său uneia dintre aceste autorități de certificare. Pentru a emite certificatul, autoritatea de certificat efectuează un proces de verificare a identității, bazat pe o verificare de validare a domeniului (pentru certificatele validate de domeniu) sau verificarea validării organizației (pentru certificatele validate de organizație).

   • Apelurile către și de la cloud depind de certificatul care a fost emis Expressway-E. Dacă certificatul nu este valabil, apelul este întrerupt.

Conectorul dispozitivului Webex trebuie să comunice cu Webex pentru ca apelarea hibridă să funcționeze.

Webex Device Connector este implementat în rețeaua internă, iar modul în care comunică cu cloud-ul este printr-o conexiune HTTPS de ieșire - același tip care este utilizat pentru orice browser care se conectează la un server web.

Comunicarea cu cloud-ul Webex utilizează TLS. Webex Device Connector este clientul TLS, iar cloud-ul Webex este serverul TLS. Ca atare, Webex Device Connector verifică certificatul serverului.

Autoritatea de certificare semnează un certificat de server utilizând propria cheie privată. Oricine are cheia publică poate decoda semnătura respectivă și poate dovedi că aceeași autoritate de certificat a semnat acel certificat.

Dacă Webex Device Connector trebuie să valideze certificatul furnizat de cloud, acesta trebuie să utilizeze cheia publică a autorit ății de certificat care a semnat certificatul respectiv pentru a decoda semnătura. O cheie publică este conținută în certificatul autorității de certificare. Pentru a stabili încrederea cu autoritățile de certificare utilizate de cloud, lista certificatelor acestor autorități de certificare de încredere trebuie să se afle în magazinul de încredere Webex Device Connector.

Când comunicați cu dispozitive, instrumentul utilizează certificate de încredere pe care le furnizați. În prezent, modalitatea de a face acest lucru este prin plasarea lor [home folder]/.devicestool/certs.

O listă de certificate de autoritate de certificare este, de asemenea, necesară pentru Expressway-E în perechea de traversare. Expressway-E comunică cu cloud-ul Webex folosind SIP cu TLS, impus prin autentificare reciprocă. Expressway-E are încredere în apelurile care vin de la și care merg în cloud, numai dacă CN sau SAN al certificatului prezentat de cloud în timpul configurării conexiunii TLS se potrivește cu numele subiectului configurat pentru zona DNS de pe Expressway („callservice.webex.com”). Autoritatea de certificare eliberează un certificat numai după o verificare a identității. Proprietatea domeniului callservice.webex.com trebuie dovedită pentru a obține un certificat semnat. Deoarece noi (Cisco) deținem acel domeniu, numele DNS „callservice.webex.com” este o dovadă directă că peer-ul de la distanță este cu adevărat Webex.

conectorul calendarului integrează Webex cu Microsoft Exchange 2013, 2016, 2019 sau Office 365 printr-un cont de impersonare. Rolul de gestionare a impersonării aplicațiilor din Exchange permite aplicațiilor să identifice utilizatorii dintr-o organizație pentru a efectua activități în numele utilizatorului. Rolul de imitare a aplicației trebuie configurat în Exchange și este utilizat în conectorul calendarului ca parte a configurației Exchange pe interfața Expressway-C.

Contul de impersonare Exchange este metoda recomandată de Microsoft pentru această activitate. Administratorii Expressway-C nu trebuie să cunoască parola, deoarece valoarea poate fi introdusă în interfața Expressway-C de către un administrator Exchange. Parola nu este afișată clar, chiar dacă administratorul Expressway-C are acces root la caseta Expressway-C. Parola este stocată criptată folosind același mecanism de criptare a acreditărilor ca și alte parole de pe Expressway-C.

Pentru securitate suplimentară, urmați pașii din Ghi dul de implementare pentru serviciul de calendar Cisco Webex hibrid pentru a activa TLS pentru a securiza conexiunile EWS pe fir.

Pentru securitate suplimentară, urmați pașii din Implement area conectorului calendarului Expressway Microsoft Exchange pentru a activa TLS pentru a securiza conexiunile EWS pe fir.