- Kezdőlap
- /
- Cikk
Ez a cikk azoknak a hálózati rendszergazdáknak szól, különösen tűzfal- és proxybiztonsági rendszergazdáknak, akik használni szeretnék a Webex Calling szolgáltatásait a szervezetükön belül.
A tűzfalhoz és a hozzáférési követelményekhez tartozó portreferencia-adatokat a Cisco Webex Callinghoz tartozó portreferencia-adatok szakaszban találja.
Végpontokra vonatkozó követelmények
Webex Calling Edge
SIP-regisztráció vagy hívás végrehajtásához a következő lépéseket végezze el:
Azonosítsa egy SIP-végpont állomáscímét az aktív Edge-csomópontokhoz.
Teljesítse az összes felhasználó- és eszközkonfigurációra vonatkozó előfeltételt.
Bizonyosodjon meg arról, hogy a végpont rendelkezik nyilvános hálózati kapcsolattal a szolgáltatásazonosítás megkezdéséhez.
Teljesítse a végpont régió- vagy adatközpont-specifikus beüzemelési konfigurációval történő rendszerindításának előfeltételeit. Ezzel a konfigurációval lekérheti az adott tartománynév utótagját a szolgáltatásazonosításhoz.
IPv4 versus IPv6
Az eszközök egyvermes vagy kétvermes módban működnek. A konfiguráció határozza meg az előnyben részesített protokoll módosításait, és ezek a módosítások nem részei a szolgáltatásazonosításnak.
Egyvermes mód—Csak egy IP-protokollt (pl. IPv4) engedélyez, és figyelmen kívül hagyja a többi protokollcímet.
Kétvermes mód—A konfiguráción keresztül kiválasztja az előnyben részesített IP-verziót.
A kliens az összes előnyben részesített cím prioritását alacsonyabbnak (azaz előnyben részesítettnek) tekinti, mint az IP összes címét. Ha az előnyben részesített az IPv4, akkor az összes IPv4-címet megpróbálja a rendszer, mielőtt IPv6-címre kerülne sor. Ha az összes cím sikertelen, a ciklus újrakezdődik, a legalacsonyabb prioritású, előnyben részesített protokollcímmel.
A leküldéses értesítés beérkezésekor regisztráló mobilkliens a korábbi regisztrációk alapján dönthet a mód optimalizálásáról.
Az állomáscím feloldása a DNS SRV-címről
Az üzembe helyezés során kapott végpont-konfigurációs fájlban a tartományjelző a tartománynevet adja meg a hozzáférési peremhálózati szolgáltatás felderítéséhez. Példa a tartománynévre:
wxc.edge.bcld.webex.com
A példa alapján a DNS SRV-keresést végző végpont ehhez a tartományhoz a következőhöz hasonló választ kaphat:
# nslookup -type=srv _sips._tcp. wxc.edge.bcld.webex.com
_sips._tcp.wxc.edge.bcld.webex.com SRV 5 100 5061 sip-edge1.us-dc1.bcld.webex.com.
_sips._tcp.wxc.edge.bcld.webex.com SRV 10 105 5061 sip-edge2.us-dc1. bcld.webex.com.
Ebben az esetben az SRV-rekord 3 A-rekordra mutat.
sip-edge1.us-dc1.bcld.webex.com
sip-edge2.us-dc1.bcld.webex.com
A példában az összes állomás az 5061-es portra van közzétéve, eltérő súlyozással és prioritással.
Vegye figyelembe e végpontokra vonatkozó követelményeket.
A végpontnak
_sips._tcp
(szolgáltatás és protokoll kombinációját) kell használnia előtagként a DNS SRV-keresés végrehajtásához, hogy lekérje az állomáscímet a TLS-alapú kommunikáció megkezdéséhez.A végpontnak DNS SRV-keresést kell végrehajtania Az állomáscím feloldása a DNS SRV-címről szakaszban leírt feltételek esetén.
A végpontnak figyelembe kell vennie az egyes állomáscímekben közzétett állomás, port, súly és prioritás értékét. Emellett a SIP-regisztráció során a szoftvercsatorna-kapcsolat létrehozásakor létre kell hoznia az állomás és a port közötti affinitást.
A DNS SRV-rekord használatára vonatkozóan az állomások prioritás és súly alapján való kiválasztásának kritériumait az RFC 2782 ismerteti.
SIP-re és médiára vonatkozó követelmények
Követelmény | Leírás |
---|---|
Megbízhatósági tanúsítvány szükséges a nyilvános kulcs titkosításához | A Webex-tanúsítványok aláírási jogosultságáról és az eszközökhöz szükséges CA-gyökértanúsítványról a cikkben olvashat |
Támogatott TLS-verziók a biztonságos SIP-hez | TLS 1,2 |
Támogatott TLS-rejtjelek a biztonságos SIP-hez | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 |
Támogatott SRTP-kulcsok a biztonságos médiához | AES_CM_128_HMAC_SHA1_80 |
A biztonságos SIP követelményei mTLS-sel (közös TLS)
A követelmények részletes magyarázata itt található.
A trönkről érkező hívások sikeres engedélyezéséhez és hitelesítéséhez aláírt tanúsítványra van szükség. A tanúsítványnak az alábbi követelményeknek kell megfelelnie:
A tanúsítványt a pontban említett hitelesítésszolgáltatónak kell aláírnia Milyen legfelső szintű hitelesítésszolgáltatók támogatottak a Cisco Webex audio és video platformok hívásai esetén?
Töltse fel a következőben említett bizalmi csomagot Milyen legfelső szintű hitelesítésszolgáltatók támogatottak a Cisco Webex audio és video platformok hívásai esetén? tovább a CUBE-ra.
A tanúsítványnak mindig érvényesnek kell lennie:
Az aláírt tanúsítványoknak mindig rendelkezniük kell érvényes lejárati dátummal.
A gyökér- vagy közbenső tanúsítványoknak érvényes lejárati idővel kell rendelkezniük, és nem lehetnek visszavontak.
A tanúsítványokat alá kell írni a kliens- és kiszolgálóhasználathoz.
A tanúsítványoknak tartalmazniuk kell a teljesen minősített tartománynevet (FQDN) általános névként, vagy a téma másik megnevezését a Control Hubban kiválasztott FQDN-nel együtt. Például:
A szervezete Control Hubjáról london.lgw.cisco.com:5061 FQDN-nel konfigurált törzsnek tartalmaznia kell a london.lgw.cisco.com címet a CN vagy SAN tanúsítványban.
Annak a trönknek, amely a szervezete Control Hubjából lett konfigurálva és az SRV-je a london.lgw.cisco.com volt, tartalmaznia kell a következőt a CN- vagy SAN-tanúsítványban: london.lgw.cisco.com. Azok a rekordok, amelyeket az SRV-cím (CNAME-re/A-rekordra/IP-címre) old fel, a SAN-ban opcionálisak.
Egynél több helyi átjáróval is megoszthat tanúsítványokat, azonban meg kell bizonyosodnia arról, hogy az FQDN-követelmények be vannak tartva.
Hatókörön kívül
Ez a cikk nem tartalmazza az alábbi, hálózatbiztonsággal kapcsolatos információkat:
F5-követelmények a CA-hoz és a rejtjelekhez
HTTP-alapú API a Webex-tűzfalszabályok letöltéséhez
API megbízható köteghez
Tűzfalkövetelmények és ALG-letiltás