Det här avsnittet innehåller ytterligare sammanhang om viktiga konfigurationsobjekt som relaterar till Hybrid Services.

Dessa punkter är avgörande om du vill distribuera Hybrid Calling för Webex-enheter framgångsrikt. Vi har särskilt markerat dessa saker av följande skäl:

• Vi vill förklara dem så att du förstår deras roll i en hybriddistribution och känner dig trygg.

• De är obligatoriska förutsättningar som säkerställer en säker distribution mellan vårt moln och din lokala miljö.

• De bör behandlas som nollaktiviteter före dagen: de kan ta lite längre tid att slutföra än typisk konfiguration i ett användargränssnitt, så tillåt en tidsram för att sortera dessa objekt.

• När dessa objekt har åtgärdats i din miljö kommer resten av din Hybrid Services-konfiguration att gå smidigt.

Expressway-C- och Expressway-E- pardistributionen tillåter samtal till och från Internet med hjälp av brandväggstraverseringsteknik . Den här distributionen är det som säkert tar din lokala samtalskontroll och koppl ar den till Webex.

Expressway-C och Expressway-E kräver inte att någon inkommande port öppnas i DMZ-brandväggen (demilitariserad zon) på grund av brandväggsövergångsarkitekturen. Men TCP SIP-signalportar och UDP- mediaportar måste öppnas inkommande på Internet- brandväggen för att låta inkommande samtal komma igenom. Du måste tillåta tid för att få rätt port öppnad på din företagsbrandvägg.

Brandväggsövergångsarkitekturen visas i följande diagram:

Till exempel, för inkommande B2B-samtal som använder SIP-protokoll, måste TCP-portarna 5060 och 5061 (5061 används för SIP TLS) öppnas på den externa brandväggen tillsammans med UDP-medieportar som används för tjänster som röst, video, innehållsdelning, dubbel video och så vidare. Vilka medieportar som ska öppnas beror på antalet samtidiga samtal och antalet tjänster.

Du kan konfigurera SIP-lyssningsporten på Expressway till val fritt värde mellan 1024 och 65534. Samtidigt måste detta värde och protokolltypen annonseras i de offentliga po DNS SRV sterna, och samma värde måste öppnas på Internet-brandväggen.

Även om standarden för SIP TCP är 5060 och för SIP TLS 5061, hindrar ingenting användning av olika portar, som följande exempel visar.

Exempel

I det här exemplet antar vi att port 5062 används för inkommande SIP TLS-anrop.

DNS SRVRekordet för ett kluster med två Expressway-servrar ser ut så här:

_klunkar. _tcp.example .com SRV-tjänstplats:

priority = 10

weight = 10

port = 5062

svr värdnamn = us-expe1.example.com

_klunkar. _tcp.example .com SRV-tjänstplats:

priority = 10

weight = 10

port = 5062

svr värdnamn = us-expe2.example.com

Dessa poster innebär att samtal riktas till us-expe1.example.com och us-expe2.example.com med lika belastnings delning (prioritet och vikt) med TLS som transporttyp och 5062 som lyssningsportnummer.

En enhet som är extern till nätverket (på Internet) och som ringer ett SIP-samtal till en användare av företags domänen (user1@example.com) måste fråga DNS för att förstå vilken transporttyp som ska användas, port numret, hur man laddar och delar trafiken och vilka SIP- servrar som ska skickas samtalet till.

Om DNS-posten innehåller _sips. _tcp, posten anger SIP TLS.

TLS är ett klient-serverprotokoll och använder i de vanligaste implementeringarna certifikat för autentisering. I ett företag-till-företag-samtal sscenario är TLS-klienten den anropande enheten och TLS-servern är den anropade enheten. Med TLS kontrollerar klienten serverns certifikat, och om certifikatkontrollen misslyckas kopplar den från samtalet . Klienten behöver inte ett certifikat.

TLS-handskakning visas i följande diagram:

TLS-specifikationen anger dock att servern också kan kontrollera klientcertifikatet genom att skicka ett meddelande om certifikatbegäran till klienten under TLS- handskakningsprotokollet. Det här meddelandet är användbart för en server-till-server-anslutning, till exempel vid samtal som upprättas mellan Expressw ay-E och Webex-molnet. Detta koncept kallas TLS med ömsesidig autentisering och krävs vid integration med Webex.

Både de uppringande och de uppringda parterna kontrollerar certifikatet för den andra kamraten, som följande diagram visar:

Molnet kontrollerar Expressway-identiteten och Expressway kontrollerar molnidentiteten. Om till exempel molnidentit eten i certifikatet (CN eller SAN) inte stämmer överens med vad som är konfigurerat på Expressway, bry ts anslutningen.

Om ömsesidig autentisering är aktiverad begär Expressway-E alltid klient certifikatet. Som ett resultat fungerar inte Mobile och Remote Access (MRA), eftersom certifikat i de flesta fall inte distribueras på Jabber-klienter . I ett företag-till-företag-scenario, om den anropande enheten inte kan tillhandahålla ett certifikat, kopplas samtalet bort.

Vi rekommenderar att du använder ett annat värde än 5061 för TLS med ömsesidig autentisering, till exempel port 5062. Webex Hybrid Services använder samma SIP TLS-post som används för B2B. När det gäller port 5061 fungerar vissa andra tjänster som inte kan tillhandahålla ett TLS-klient certifikat inte.

Om en befintlig post redan används för kommunikation mellan företag rekommenderar vi att du anger en underdomän till företagsdomänen som SIP-destination i Control Hub, och följaktligen en offentlig DNS SRV post, enligt följande:

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

Affärs-till-företag-, mobil- Remote Access och Webex-trafik på samma Expressway-par

Business-to-Business (B2B) och Mobile och Remote Access (MRA) - samtal använder port 5061 för SIP TLS, och Webex-trafik använder port 5062 för SIP TLS med ömsesidig autentisering.

Kontroll av domänägande är en del av identitetsverifieringen. Domänverifiering är en säkerhetsåtgärd och identitetskontroll som Webex-molnet implementerar för att bevisa att du är den du säger att du är.

Identitetskontrollen utförs i två steg:

1. Kontroll av domänägande. Det här steget omfattar tre typer av domäner och är en engångsverifieringskontroll:

   • E-postdomän

   • Expressway-E DNS-domän

   • Katalog-URI-domän

2. Expressway-E DNS-namnägarkontroll. Detta steg utförs genom implementering av TLS med ömsesidig autentisering och innebär användning av offentliga certifikat på både molnet och Expressway. Till skillnad från domänidentitetskontrollen utförs detta steg under alla samtal som görs till och tas emot från molnet.

Betydelsen av domänägarkontrollen

Webex-molnet utför domänägarkontrollen för att upprätthålla säkerhet. Identitetsstöld är ett möjligt hot om denna kontroll inte utförs.

Följande berättelse beskriver vad som kan hända om en domänägarkontroll inte utförs.

Ett företag med DNS-domän inställd på ”hacker.com” köper Webex Hybrid Services. Ett annat företag, med sin egen domän inställd på ”example.com”, använder också hybridtjänster. En av cheferna för företaget Example.com heter Jane Roe och har katalogen URI jane.roe@example.com.

Administratören för Hacker.com-företaget ställer in en av sina katalog-URI till jane.roe@example.com och e-postadressen till jane.roe@hacker.com. Hon kan göra det eftersom molnet inte kontrollerar SIP URI-domänen i det här exemplet.

Därefter loggar hon in på Webex App med jane.roe@hacker.com. Eftersom hon äger domänen läses och besvaras verifierings-e-postmeddelandet, och hon kan logga in. Slutligen ringer hon till en kollega, John Doe, genom att ringa john.doe@example.com från sin Webex-app. John sitter på sitt kontor och ser ett samtal på sin videoenhet som kommer från jane.roe@example.com; det är katalog-URI som är associerad med det e-postkontot.

”Hon är utomlands”, tänker han. ”Hon kanske behöver något viktigt.” Han svarar på telefonen, och den falska Jane Roe ber om viktiga dokument. Hon förklarar att hennes enhet är trasig, och eftersom hon reser ber hon honom skicka dokumenten till sin privata e-postadress, jane.roe@hacker.com. På så sätt inser företaget först efter att Jane Roe kommer tillbaka till kontoret att viktig information läckt ut utanför företaget.

Företaget Example.com har många sätt att skydda mot bedrägliga samtal som kommer från Internet, men ett av Webex-molnets ansvar är att se till att identiteten på alla som ringer från Webex är korrekt och inte förfalskad.

För att kontrollera identiteten kräver Webex att företaget bevisar att det äger domänerna som används i Hybrid Calling. Om den inte gör det fungerar inte hybridtjänster.

För att säkerställa detta ägande krävs de två stegen för domänverifiering:

1. Bevisa att företaget äger e-postdomänen, Expressway-E-domän, Directory URI-domän.

   • Alla dessa domäner måste vara routningsbara och kända av offentliga DNS-servrar.

   • För att bevisa ägandet måste DNS-administratören ange en DNS-textpost (TXT). En TXT-post är en typ av resurspost i DNS som används för att ge möjlighet att associera viss godtycklig och oformaterad text med en värd eller ett annat namn.

   • DNS-administratören måste ange den TXT-posten i den zon vars ägande måste bevisas. Efter det steget utför Webex-molnet en TXT-postfråga för den domänen.

   • Om TXT-frågan lyckas och resultatet matchar token som genererades från Webex-molnet verifieras domänen.

   • Som ett exempel måste administratören bevisa att hon äger domänen ”example.com”, om hon vill att Webex Hybrid Services ska fungera på hennes domän.

   • Via https://admin.webex.com startar hon verifieringsprocessen genom att skapa en TXT-post för att matcha token som Webex-molnet genererade:

     

   • DNS-administratören skapar sedan en TXT-post för den här domänen med värdet inställt på 123456789abcdef123456789abcdef 123456789abcdef123456789abcdef, som i följande exempel:

     

   • Vid denna tidpunkt kan molnet verifiera att TXT-posten för domänen example.com matchar token.

   • Molnet utför en TXT DNS-sökning:

     

   • Eftersom TXT-värdet matchar tokenvärdet bevisar den här matchningen att administratören har lagt till TXT-posten för sin egen domän till den offentliga DNS och att hon äger domänen.

2. Expressway-E DNS Namn ägarkontroll.

   • Molnet måste kontrollera att Expressway-E har en bekräftad identitet från en av de certifikatmyndigheter som molnet litar på. Expressway-E-administratören måste begära ett offentligt certifikat för sin Expressway-E till en av dessa certifikatmyndigheter. För att utfärda certifikatet utför certifikatutfärdaren en identitetsverifieringsprocess, baserad på en domänvalideringskontroll (för domänvaliderade certifikat) eller organisationsvalideringskontroll (för organisationsvaliderade certifikat).

   • Samtal till och från molnet beror på certifikatet som utfärdades till Expressway-E. Om certifikatet inte är giltigt avbryts samtalet.

Webex Device Connector måste kommunicera med Webex för att hybridanrop ska fungera.

Webex Device Connector distribueras i det interna nätverket, och sättet det kommunicerar med molnet är via en utgående HTTPS-anslutning - samma typ som används för alla webbläsare som ansluter till en webbserver.

Kommunikation till Webex-molnet använder TLS. Webex Device Connector är TLS-klienten och Webex-molnet är TLS-servern. Som sådan kontrollerar Webex Device Connector servercertifikatet.

Certifikatutfärdaren signerar ett servercertifikat med sin egen privata nyckel. Alla som har den offentliga nyckeln kan avkoda den signaturen och bevisa att samma certifikatutfärdare har signerat certifikatet.

Om Webex Device Connector måste validera certifikatet som tillhandahålls av molnet måste den använda den offentliga nyckeln för certifikat utfärdaren som signerade certifikatet för att avkoda signaturen. En offentlig nyckel finns i certifikatutfärdarens certifikat. Om du vill skapa förtroende hos de certifikatmyndigheter som används av molnet måste listan över certifikat för dessa betrodda certifikatmyndigheter finnas i Webex Device Connectors förtroendelager.

När du kommunicerar med enheter använder verktyget betrodda certifikat som du tillhandahåller. För närvarande är sättet att göra det genom att placera dem i [home folder]/.devicestool/certs.

En lista över certifikatutfärdarcertifikat krävs också för Expressway-E i traverseringsparet. Expressway-E kommunicerar med Webex-molnet med SIP med TLS, verkställs genom ömsesidig autentisering. Expressway-E litar på samtal som kommer från och går till molnet, endast om CN eller SAN för certifikatet som presenteras av molnet under TLS-anslutningen matchar ämnesnamnet som konfigurerats för DNS-zonen på Expressway (”callservice.webex.com”). Certifikatutfärdaren utfärdar ett certifikat först efter en identitetskontroll. Äganderätten till domänen callservice.webex.com måste bevisas för att få ett certifikat signerat. Eftersom vi (Cisco) äger den domänen är DNS-namnet ”callservice.webex.com” ett direkt bevis på att fjärrkamraten verkligen är Webex.

kalenderanslutningen integrerar Webex med Microsoft Exchange 2013, 2016, 2019 eller Office 365 via ett personifieringskonto. Rollen för hantering av programpersonifiering i Exchange gör det möjligt för program att utge sig för att vara användare i en organisation för att utföra uppgifter på användarens vägnar. Programpersonifieringsrollen måste konfigureras i Exchange och används i kalenderanslutningen som en del av Exchange-konfigurationen på Expressway-C-gränssnittet.

Exchange-efterlikningskontot är Microsofts rekommenderade metod för den här uppgiften. Expressway-C-administratörer behöver inte känna till lösenordet, eftersom värdet kan anges i Expressway-C-gränssnittet av en Exchange-administratör. Lösenordet visas inte tydligt, även om Expressway-C-administratören har root-åtkomst till rutan Expressway-C. Lösenordet lagras krypterat med samma autentiseringskrypteringsmekanism som andra lösenord på Expressway-C.

För ytterligare säkerhet, följ stegen i Deployment Guide for Cisco Webex Hybrid Calendar Service för att aktivera TLS för att säkra EWS-anslutningar på kabeln.

För ytterligare säkerhet, följ stegen i Distribuera Expressway Calendar Connector för Microsoft Exchange att aktivera TLS för att säkra EWS-anslutningar på ledningen.