Esta sección proporciona un contexto adicional sobre los elementos de configuración clave relacionados con los servicios híbridos.

Estos puntos son cruciales si desea implementar con éxito Hybrid Calling para dispositivos Webex. Hemos destacado estos elementos en particular por las siguientes razones:

• Queremos explicarlos, para que entienda su papel en una implementación híbrida y se sienta tranquilizado.

• Son requisitos previos obligatorios que garantizan una implementación segura entre nuestra nube y su entorno local.

• Deben tratarse como actividades previas al día cero: pueden tardar un poco más en completarse que la configuración típica en una interfaz de usuario, así que permita un período de tiempo para ordenar estos elementos.

• Después de abordar estos elementos en su entorno, el resto de su configuración de servicios híbridos se realizará sin problemas.

La implementación del par Expressway-C y Expressway-E permite llamadas hacia y desde Internet utilizando tecnologías de firewall cruzadas. Esta implementación es lo que toma de manera segura su control de llamadas en las instalaciones y lo ata a Webex.

Expressway-C y Expressway-E no requieren que se abra ningún puerto entrante en el firewall de zona desmilitarizada (DMZ) debido a la arquitectura transversal del firewall. Pero los puertos de señalización TCP SIP y los puertos de medios UDP deben abrirse de entrada en el firewall de Internet para permitir que las llamadas entrantes lleguen. Debe dejar tiempo para que se abra el puerto apropiado en su firewall empresarial.

La arquitectura transversal del firewall se muestra en el siguiente diagrama:

Por ejemplo, para las llamadas entrantes de empresa a empresa (B2B) que utilizan el protocolo SIP, los puertos TCP 5060 y 5061 (5061 se usa para SIP TLS) deben abrirse en el firewall externo, junto con los puertos de medios UDP utilizados para servicios como voz, video, uso compartido de contenido, video dual, etc. Los puertos multimedia que se van a abrir dependen de la cantidad de llamadas simultáneas y de la cantidad de servicios.

Puede configurar el puerto de escucha SIP en Expressway para que tenga cualquier valor entre 1024 y 65534. Al mismo tiempo, este valor y el tipo de protocolo deben anunciarse en los DNS SRV registros públicos, y ese mismo valor debe abrirse en el firewall de Internet.

Aunque el estándar para SIP TCP es 5060 y para SIP TLS 5061, nada impide el uso de diferentes puertos, como muestra el siguiente ejemplo.

Ejemplo

En este ejemplo, asumimos que el puerto 5062 se usa para llamadas TLS SIP entrantes.

El DNS SRV récord de un clúster de dos servidores Expressway se ve así:

_sorbos. Ubicación del servicio SRV _tcp.example.com:

priority = 10

weight = 10

port = 5062

nombre de host svr = us-expe1.example.com

_sorbos. Ubicación del servicio SRV _tcp.example.com:

priority = 10

weight = 10

port = 5062

nombre de host svr = us-expe2.example.com

Estos registros significan que las llamadas se dirigen a us-expe1.example.com y us-expe2.example.com con la misma carga compartida (prioridad y peso) usando TLS como tipo de transporte y 5062 como número de puerto de escucha.

Un dispositivo que es externo a la red (en Internet) y que realiza una llamada SIP a un usuario del dominio corporativo (user1@example.com) debe consultar el DNS para saber qué tipo de transporte usar, el número de puerto, cómo compartir carga el tráfico y a qué servidores SIP enviar la llamada.

Si la entrada DNS incluye _sips. _tcp, la entrada especifica SIP TLS.

TLS es un protocolo cliente-servidor y, en las implementaciones más comunes, utiliza certificados para la autenticación. En un escenario de llamada de empresa a empresa, el cliente TLS es el dispositivo que llama y el servidor TLS es el dispositivo llamado. Con TLS, el cliente comprueba el certificado del servidor, y si falla la comprobación del certificado, desconecta la llamada. El cliente no necesita un certificado.

El apretón de manos TLS se muestra en el siguiente diagrama:

Sin embargo, la especificación TLS indica que el servidor también puede verificar el certificado del cliente enviando un mensaje de solicitud de certificado al cliente durante el protocolo de enlace TLS . Este mensaje es útil en una conexión de servidor a servidor, como en una llamada que se establece entre Expressway-E y la nube de Webex. Este concepto se llama TLS con autenticación mutua y se requiere cuando se integra con Webex.

Tanto las partes que llaman como las llamadas verifican el certificado del otro par, como muestra el siguiente diagrama:

La nube comprueba la identidad de la autopista y Expressway comprueba la identidad de la nube. Por ejemplo, si la identidad de la nube en el certificado (CN o SAN) no coincide con lo que está configurado en Expressway, la conexión se elimina.

Si la autenticación mutua está activada, Expressway-E siempre solicita el certificado de cliente. Como resultado, Mobile y Remote Access (MRA) no funcionarán, porque en la mayoría de los casos los certificados no se implementan en los clientes Jabber . En un escenario de empresa a empresa, si la entidad llamante no puede proporcionar un certificado, la llamada se desconecta.

Le recomendamos que utilice un valor que no sea 5061 para TLS con autenticación mutua, como el puerto 5062. Webex Hybrid Services utiliza el mismo registro TLS SIP utilizado para B2B. En el caso del puerto 5061, algunos otros servicios que no pueden proporcionar un certificado de cliente TLS no funcionarán.

Si ya se utiliza un registro existente para las comunicaciones entre empresas, se recomienda especificar un subdominio del dominio corporativo como destino SIP en Control Hub y, en consecuencia, un DNS SRV registro público, de la siguiente manera:

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

Tráfico de empresa a empresa, móvil Remote Access y Webex en el mismo par de Autopista

Las llamadas de empresa a empresa (B2B) y móviles y Remote Access (MRA) utilizan el puerto 5061 para SIP TLS, y el tráfico de Webex usa el puerto 5062 para SIP TLS con autenticación mutua.

La verificación de propiedad del dominio es parte de la verificación de identidad. La verificación de dominio es una medida de seguridad y una verificación de identidad que la nube de Webex implementa para demostrar que es quien dice ser.

La verificación de identidad se realiza en dos etapas:

1. Verificación de propiedad del dominio. Este paso involucra tres tipos de dominios y es una verificación de verificación única:

   • Dominio de correo electrónico

   • Dominio DNS de Expressway-E

   • Dominio URI del directorio

2. Verificación de propiedad del nombre DNS de Expressway-E. Este paso se realiza mediante la implementación de TLS con autenticación mutua e implica el uso de certificados públicos tanto en la nube como en la autopista. A diferencia de la verificación de identidad de dominio, este paso se realiza durante cualquier llamada realizada y recibida desde la nube.

La importancia de la verificación de propiedad del dominio

La nube de Webex realiza la verificación de propiedad del dominio para hacer cumplir la seguridad. El robo de identidad es una posible amenaza si no se realiza esta comprobación.

La siguiente historia detalla lo que podría suceder si no se realiza una verificación de propiedad de dominio.

Una compañía con el dominio DNS establecido en “hacker.com” compra Webex Hybrid Services. Otra compañía, con su propio dominio establecido en “example.com”, también está utilizando servicios híbridos. Uno de los gerentes generales de la compañía Example.com se llama Jane Roe y tiene el URI del directorio jane.roe@example.com.

La administradora de la compañía Hacker.com establece uno de sus URI de directorio en jane.roe@example.com y la dirección de correo electrónico en jane.roe@hacker.com. Ella puede hacerlo porque la nube no comprueba el dominio URI SIP en este ejemplo.

A continuación, se inscribe en Webex App con jane.roe@hacker.com. Debido a que es dueña del dominio, el correo electrónico de verificación se lee y responde, y puede iniciar sesión. Finalmente, llama a un colega, John Doe, marcando john.doe@example.com desde su aplicación Webex. John está sentado en su oficina y ve una llamada en su dispositivo de video proveniente de jane.roe@example.com; ese es el URI del directorio asociado con esa cuenta de correo electrónico.

“Ella está en el extranjero”, piensa. “Ella podría necesitar algo importante”. Él contesta el teléfono y la falsa Jane Roe pide documentos importantes. Ella explica que su dispositivo está roto y, como está viajando, le pide que envíe los documentos a su dirección de correo electrónico privada, jane.roe@hacker.com. De esta manera, la compañía solo se da cuenta después de que Jane Roe regrese a la oficina que se filtró información importante fuera de la compañía.

La compañía Example.com tiene muchas maneras de protegerse contra llamadas fraudulentas provenientes de Internet, pero una de las responsabilidades de la nube de Webex es asegurarse de que la identidad de cualquier persona que llame desde Webex sea correcta y no falsificada.

Para verificar la identidad, Webex requiere que la compañía demuestre que es propietaria de los dominios utilizados en las llamadas híbridas. Si no es así, los servicios híbridos no funcionarán.

Para garantizar esta propiedad, se requieren los dos pasos de verificación del dominio:

1. Demuestra que la compañía posee el dominio de correo electrónico, el dominio Expressway-E, el dominio URI del directorio.

   • Todos esos dominios deben ser enrutables y ser conocidos por servidores DNS públicos.

   • Para probar la propiedad, el administrador de DNS debe introducir un registro de texto DNS (TXT). Un registro TXT es un tipo de registro de recursos en el DNS utilizado para proporcionar la capacidad de asociar algún texto arbitrario y sin formato con un host u otro nombre.

   • El administrador de DNS debe ingresar ese registro TXT en la zona cuya propiedad debe probarse. Después de ese paso, la nube de Webex realiza una consulta de registro TXT para ese dominio.

   • Si la consulta TXT se realiza correctamente y el resultado coincide con el token que se generó desde la nube de Webex, se verifica el dominio.

   • Como ejemplo, el administrador debe probar que es propietaria del dominio “example.com”, si quiere que Webex Hybrid Services funcione en su dominio.

   • A través de https://admin.webex.com, inicia el proceso de verificación creando un registro TXT para que coincida con el token que generó la nube de Webex:

     

   • A continuación, el administrador DNS crea un registro TXT para este dominio con el valor establecido en 123456789abcdef123456789abcdef123456789abcdef123456789abcdef, como en el siguiente ejemplo:

     

   • En este punto, la nube puede verificar que el registro TXT del dominio example.com coincida con el token.

   • La nube realiza una búsqueda de DNS TXT:

     

   • Debido a que el valor TXT coincide con el valor del token, esta coincidencia demuestra que la administradora agregó el registro TXT de su propio dominio al DNS público y que ella es la propietaria del dominio.

2. Verificación de propiedad del nombre DNS de Expressway-E.

   • La nube debe verificar que Expressway-E tenga una identidad confirmada de una de las autoridades de certificación en las que confía la nube. El administrador de Expressway-E debe solicitar un certificado público para su Expressway-E a una de esas autoridades certificadoras. Para emitir el certificado, la autoridad certificadora realiza un proceso de verificación de identidad, basado en una comprobación de validación de dominio (para certificados validados de dominio) o verificación de validación de organización (para certificados validados por la organización).

   • Las llamadas hacia y desde la nube dependen del certificado que se emitió al Expressway-E. Si el certificado no es válido, se deja de llamar.

El conector de dispositivos Webex debe comunicarse con Webex para que las llamadas híbridas funcionen.

Webex Device Connector se implementa en la red interna y la forma en que se comunica con la nube es a través de una conexión HTTPS saliente, el mismo tipo que se utiliza para cualquier navegador que se conecte a un servidor web.

La comunicación con la nube de Webex utiliza TLS. Webex Device Connector es el cliente TLS y la nube de Webex es el servidor TLS. Como tal, Webex Device Connector comprueba el certificado del servidor.

La autoridad certificadora firma un certificado de servidor utilizando su propia clave privada. Cualquier persona con la clave pública puede decodificar esa firma y probar que la misma autoridad certificadora firmó ese certificado.

Si Webex Device Connector tiene que validar el certificado proporcionado por la nube, debe usar la clave pública de la autoridad de certificación que firmó ese certificado para decodificar la firma. Una clave pública está contenida en el certificado de la autoridad de certificación. Para establecer confianza con las autoridades de certificación utilizadas por la nube, la lista de certificados de estas autoridades de certificación de confianza debe estar en el almacén de confianza de Webex Device Connector.

Cuando se comunica con dispositivos, la herramienta utiliza certificados de confianza que proporciona. Actualmente, la manera de hacerlo es colocándolos [home folder]/.devicestool/certs.

También se requiere una lista de certificados de autoridad de certificación para el Expressway-E en el par transversal. Expressway-E se comunica con la nube de Webex mediante SIP con TLS, implementado por autenticación mutua. Expressway-E confía en las llamadas que vienen y van a la nube, solo si la CN o SAN del certificado presentado por la nube durante la configuración de la conexión TLS coincide con el nombre del asunto configurado para la zona DNS en Expressway (“callservice.webex.com”). La autoridad de certificación emite un certificado solo después de una verificación de identidad. Se debe probar la propiedad del dominio callservice.webex.com para que se firme un certificado. Debido a que nosotros (Cisco) somos dueños de ese dominio, el nombre DNS “callservice.webex.com” es una prueba directa de que el par remoto es verdaderamente Webex.

El conector de calendario integra Webex con Microsoft Exchange 2013, 2016, 2019 u Office 365 a través de una cuenta de suplantación. La función de administración de suplantación de aplicaciones en Exchange permite que las aplicaciones se suplanten a usuarios de una organización para realizar tareas en nombre del usuario. La función de suplantación de la aplicación debe configurarse en Exchange y se utiliza en el conector de calendario como parte de la configuración de Exchange en la interfaz Expressway-C.

La cuenta de suplantación de identidad de Exchange es el método recomendado por Microsoft para esta tarea. Los administradores de Expressway-C no necesitan saber la contraseña, ya que un administrador de Exchange puede introducir el valor en la interfaz Expressway-C. La contraseña no se muestra claramente, incluso si el administrador de Expressway-C tiene acceso root al cuadro Expressway-C. La contraseña se almacena cifrada utilizando el mismo mecanismo de cifrado de credenciales que otras contraseñas en Expressway-C.

Para mayor seguridad, siga los pasos de la Guía de implementación de Cisco Webex Hybrid Calendar Service para habilitar TLS con el fin de proteger las conexiones EWS en el cable.

Para mayor seguridad, siga los pasos de Implementar Expressway Calendar Connector Microsoft Exchange para habilitar TLS con el fin de asegurar las conexiones EWS en el cable.