Esta sección proporciona más contexto sobre puntos de configuración clave relacionados con los Servicios híbridos de .

Estos puntos son cruciales si quiere implementar con éxito las llamadas híbridas para los dispositivos de Webex. Hemos destacado estos puntos en particular por los siguientes motivos:

• Queremos explicarlas, para que usted pueda conocer su rol en una implementación híbrida y se sienta tranquilo.

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

• Deberían ser tratados como actividades de día cero: es posible que se tarde un poco más en implementarlos que en el caso de la configuración típica en una interfaz de usuario; por eso, reserve cierto tiempo para ordenarlos.

• Una vez que resuelva estos puntos en su entorno, no tendrá ningún problema con el resto de la configuración de sus Servicios híbridos de .

La implementación de pares Expressway-C y Expressway-E permite llamadas hacia y desde Internet mediante tecnologías transversales de firewall. Esta implementación es lo que toma en forma segura su control de llamadas local y lo vincula con Webex.

Ni el Expressway-C ni el Expressway-E requieren que se abra ningún puerto entrante en la zona desmilitarizada (DMZ) debido a la arquitectura transversal del firewall. Pero se deben abrir los puertos de señales SIP de TCP y los de medios de UDP que ingresan al firewall de Internet para permitir el paso de las llamadas entrantes. Debe reservar cierto tiempo para abrir el puerto correcto en su firewall empresarial.

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

Por ejemplo: en el caso de llamadas interempresas (B2B) entrantes en las que se utilice el protocolo SIP, se deben abrir los puertos 5060 y 5061 (5061 se utiliza para SIP TLS) de TCP en el firewall externo, junto con los puertos para medios UDP que se utilizan para servicios como voz, vídeo, uso compartido de contenido, vídeo doble y demás. Los puertos para medios que se deban abrir dependerán de la cantidad de llamadas concurrentes y de la cantidad de servicios.

Puede configurar el puerto para escuchar SIP en Expressway en cualquier valor dentro del rango de 1024 a 65534. Al mismo tiempo, este valor y el tipo de protocolo deben informarse en los registros de SRV de DNS, y se debe abrir ese mismo valor en el firewall de Internet.

Aunque el estándar para SIP TCP es 5060 y para SIP TLS es 5061, nada impide el uso de otros puertos, tal como se indica en el siguiente ejemplo.

Ejemplo

En este ejemplo, suponemos que el puerto 5062 se utiliza para llamadas SIP TLS entrantes.

El registro de SRV de DNS correspondiente a un grupo de dos servidores Expressway tiene dice lo siguiente:

_sips._tcp.ejemplo.com ubicación del servicio SRV:

priority = 10

weight = 10

port = 5062

svr hostname = us-expe1.example.com

_sips._tcp.ejemplo.com ubicación del servicio SRV:

priority = 10

weight = 10

port = 5062

svr hostname = us-expe2.example.com

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

Un dispositivo que sea externo a la red (en Internet) y que realice una llamada SIP a un usuario del dominio corporativo (usuario1@ejemplo.com) deberá consultar al DNS para saber qué tipo de transporte usar, el número de puerto, cómo equilibrar la carga del tráfico y a qué servidores SIP enviar la llamada.

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

TLS es un protocolo cliente-servidor y, en las implementaciones más comunes, utiliza certificados para la autenticación. En una situación de llamadas interempresas, el cliente TLS es el dispositivo que hace la llamada, y el servidor TLS es el dispositivo al que se realiza la llamada. Con TLS, el cliente comprueba el certificado del servidor y, si falla la comprobación del certificado, se desconecta. El cliente no necesita un certificado.

En el siguiente diagrama se muestra el protocolo de enlace TLS:

Sin embargo, la especificación TLS establece que el servidor también puede comprobar el certificado del cliente enviándole un mensaje de Solicitud de certificado durante el protocolo de enlace TLS. Este mensaje es útil en una conexión entre servidores, 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 es necesario para la integración con Webex.

Tanto la parte que realiza la llamada como la que la recibe comprueban el certificado de la otra, tal como se indica en el siguiente diagrama:

La nube comprueba la identidad del Expressway, y el Expressway comprueba la identidad de la nube. Por ejemplo: si la identidad de la nube incluida en el certificado (CN o SAN) no coincide con la configurada en Expressway, se interrumpe la conexión.

Si la autenticación mutua está activada, el Expressway-E siempre solicita el certificado del cliente. Como consecuencia de ello, Mobile and Remote Access (MRA) no funcionará porque, en la mayoría de los casos, no se implementan certificados en clientes Jabber. En una situación interempresas, la llamada se desconecta si la entidad que realiza la llamada no puede proporcionar ningún certificado.

Le recomendamos que no elija 5061 para TLS con autenticación mutua; puede elegir, por ejemplo, el puerto 5062. Los Servicios híbridos de Webex utilizan el mismo registro TLS de SIP que para B2B. En el caso del puerto 5061, tampoco funcionarán otros servicios que no puedan proporcionar un certificado de cliente TLS.

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

 Servicio y protocolo: _sips._tcp.mtls.example.com Prioridad: 1 Peso: Número de puerto 10: 5062 Objetivo: us-expe1.ejemplo.com 

Acceso entre empresas, móvil y remoto y tráfico de Webex en el mismo par Expressway

Las llamadas interempresas (B2B) y de acceso móvil y remoto (MRA) utilizan el puerto 5061 para SIP TLS, y el tráfico de Webex utiliza el puerto 5062 para SIP TLS con autenticación mutua.

La comprobación de la titularidad de los dominios es parte de la verificación de identidades. La verificación de dominios es una medida de seguridad y una comprobación de identidad que implementa la nube de Webex para demostrar que usted es quien dice ser.

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

1. Comprobación de la titularidad del dominio. Este paso implica a tres tipos de dominios y es una comprobación de verificación que se realiza una sola vez:

   • Dominio de correo electrónico

   • Dominio DNS de Expressway-e

   • Dominio URL de directorio

2. Comprobación de la titularidad de nombres DNS en Expressway-E. Este paso se realiza por medio de la implementación de TLS con autenticación mutua e implica el uso de certificados públicos, tanto en la nube como en el Expressway. A diferencia de la comprobación de identidades de dominios, este paso se realiza durante cualquier llamada hecha a la nube o recibida de la nube.

La importancia de la comprobación de la titularidad de los dominios

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

En el siguiente relato se detalla lo que podría suceder si no se realiza una comprobación de la titularidad de un dominio.

Una empresa con dominio DNS definido en "hacker.com" compra los Servicios híbridos de Webex. Otra empresa, con su propio dominio definido en "ejemplo.com", también está usando los servicios híbridos. Una de los gerentes generales de la empresa Example.com se llama Jane Roe y su URL de directorio es jane.roe@example.com.

La administradora de la empresa Hacker.com define una de sus URL de directorio en jane.roe@example.com y la dirección de correo electrónico en jane.roe@hacker.com. Ella puede hacer so porque la nube no comprueba el dominio SIP URL en este ejemplo.

Luego inicia sesión en la aplicación Webex con jane.roe@hacker.com. Como ella es la titular del dominio, se lee y responde el correo electrónico de verificación, y puede iniciar sesión. Por último, hace una llamada a un colega, John Doe, marcando john.doe@example.com desde su Aplicación de Webex. John está sentado en su oficina y ve una llamada de jane.roe@example.com en su dispositivo de vídeo; esa es la URL de directorio asociada con esa cuenta de correo electrónico.

"Está fuera del país", piensa. "Tal vez necesite algo importante." Contesta el teléfono, y la falsa Jane Roe le solicita documentos importantes. Ella le explica que su dispositivo no funciona y, como está de viaje, le pide que le envíe los documentos a su dirección de correo electrónico privada: jane.roe@hacker.com. De esta manera, la empresa recién se da cuenta de que hubo una fuga de información importante recién cuando Jane Roe vuelve a la oficina.

La empresa 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 esté falsificada.

Para comprobar la identidad, Webex requiere que la empresa demuestre que es la titular de los dominios que se utilizan en las llamadas híbridas. Si no lo hace, los servicios híbridos no funcionarán.

Para asegurar esta titularidad, se requieren los dos pasos de verificación de dominios:

1. Demostrar que la empresa es titular del dominio de correo electrónico, del dominio del Expressway-E y del dominio de la URL de directorio.

   • Todos estos dominios deben poder enrutarse y ser conocidos por servidores DNS públicos.

   • Para demostrar la titularidad, la administradora de DNS debe introducir un registro de texto (TXT) de DNS. Un registro TXT es un tipo de registro de recursos en el DNS que se utiliza para poder asociar un texto arbitrario y sin formato a un host u otro nombre.

   • La administradora de DNS debe introducir el registro TXT en la zona en la que se deba demostrar la titularidad. Después de ese paso, la nube de Webex realiza una consulta de registros TXT para ese dominio.

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

   • A modo de ejemplo, la administradora debe demostrar que es la titular del dominio "ejemplo.com", si quiere que los servicios híbridos de Webex funcionen 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:

     

   • Luego, el administrador de DNS crea un registro TXT para este dominio con el valor definido en 123456789abcdef123456789abcdef123456789abcdef123456789abcdef, como en el siguiente ejemplo:

     

   • En este momento, la nube puede verificar que el registro TXT correspondiente al dominio example.com coincide con el token.

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

     

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

2. Comprobación de la titularidad de nombres DNS en Expressway-E.

   • La nube debe comprobar que el Expressway-E tiene una identidad confirmada por una de las autoridades de emisión de certificados en las que confía. El administrador del Expressway-E debe solicitar un certificado público para su Expressway-E a una de las autoridades de emisión de certificados. Para emitir el certificado, la autoridad realiza un proceso de verificación de la identidad sobre la base de una comprobación de validación del dominio (para los certificados validados del dominio) o de una comprobación de validación de la organización (para certificados validados de la organización).

   • Las llamadas entrantes y salientes de la nube dependen del certificado que se haya emitido al Expressway-E. Si el certificado no es válido, la llamada se interrumpe.

El conector de dispositivos de 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 conecta a un servidor web.

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

La autoridad de emisión de certificados firma un certificado de servidor con su propia clave privada. Cualquier persona que posea la clave pública puede decodificar esa firma y demostrar que la misma autoridad de emisión de certificados firmó ese certificado.

Si el conector de dispositivos de Webex tiene que validar el certificado proporcionado por la nube, debe utilizar la clave pública de la autoridad de emisión de certificados que firmó ese certificado para decodificar la firma. Hay una clave pública en el certificado de la autoridad de emisión de certificados. Para establecer una relación de confianza con las autoridades de emisión de certificados utilizadas por la nube, la lista de certificados de estas autoridades de confianza debe estar en el almacén de confianza de Webex Device Connector.

Al comunicarse con dispositivos, la herramienta utiliza certificados de confianza que usted proporciona. Actualmente, la forma de hacerlo es colocándolos en [home folder]/.devicestool/certs.

También se requiere una lista de certificados de autoridades de emisión de certificados para el Expressway-E del par transversal. Expressway-E se comunica con la nube de Webex mediante SIP con TLS, impuesto por autenticación mutua. El Expressway-E confía en las llamadas hacia y desde la nube solo si el CN o el SAN del certificado presentado por la nube durante la configuración de la conexión TLS coincide con el nombre de sujeto configurado para la zona DNS en Expressway ("callservice.webex.com"). La autoridad de emisión de certificados emite un certificado solo después de una comprobación de identidad. Se debe demostrar la propiedad del dominio callservice.webex.com para obtener un certificado firmado. Como nosotros (Cisco) somos los propietarios de ese dominio, el nombre de DNS "callservice.webex.com" es una prueba directa de que el par remoto realmente es Webex.

El conector de calendarios integra Webex con Microsoft Exchange 2013, 2016 y 2019, o con Office 365, por medio de una cuenta de suplantación. La función de administración de suplantación de aplicaciones de Exchange permite que las aplicaciones suplanten a los usuarios de una organización para realizar tareas en su nombre. La función de suplantación de aplicaciones se debe configurar 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 Exchange es el método recomendado por Microsoft para esta tarea. Expressway-C los administradores no necesitan conocer la contraseña, ya que un administrador de Exchange puede introducir el valor en la interfaz Expressway-C. La contraseña no se hace evidente, incluso si el administrador del Expressway-C tiene acceso de raíz a la caja del Expressway-C. La contraseña se almacena cifrada utilizando el mismo mecanismo de cifrado de credenciales que el de otras contraseñas Expressway-C.

Para mayor seguridad, siga los pasos de la Guía de implementación para el Servicio de calendario híbrido de Cisco Webex para habilitar TLS a fin de asegurar conexiones EWS en el cable.

Para mayor seguridad, siga los pasos de Implementar el Conector de calendario de Expressway para Microsoft Exchange a fin de habilitar TLS a fin de asegurar conexiones EWS en el cable.