Utilización de un proxy inverso, un distribuidor de IP o un equilibrador de carga

Los diagramas de este tema muestran una topología de red en cuya zona desmilitarizada (DMZ) se encuentra un proxy inverso y proporciona servicios de autenticación para los clientes de dispositivos móviles.

El primer diagrama representa un servidor autónomo de IBM Traveler en esta topología.

En el segundo diagrama, se muestra la misma topología de red con una agrupación de alta disponibilidad de los servidores de IBM Traveler. En este caso, la función de distribuir o equilibrar la carga de las solicitudes de dispositivos la proporciona un servidor independiente del dominio de confianza.

En el tercer diagrama, se muestra la topología de red con el proxy de autenticación que ofrece también la capacidad de distribuir las solicitudes móviles en la agrupación de alta disponibilidad de servidores de IBMTraveler. IBM® Mobile Connect puede proporcionar el proxy de autenticación y solicitar capacidad de distribución.

Esta topología de red no permite tanta flexibilidad como la topología VPN. sin embargo, aún proporciona una implementación de red segura que no expone la infraestructura del servidor IBM Domino ni a la zona de Internet ni a la zona DMZ.

IBM Notes Traveler se ha probado con varios productos proxy inversos, aunque en realidad la mayoría de los productos que proporcionan función estándar de proxy inverso deberían ser adecuados. Estos son algunos de los elementos a tener en cuenta cuando seleccione un proxy inverso:

• Compruebe que el proxy inverso es capaz de dar soporte a una cantidad de conexiones HTTP de larga duración igual al número de clientes de dispositivo móvil que hay en su red. Cuando se habilita la carga en los dispositivos móviles, estos abren una solicitud HTTP o HTTPS al servidor que permanece abierta hasta que transcurra el tiempo de espera o lleguen datos nuevos. En realidad esto significa que el número de conexiones HTTP o HTTPS es igual o ligeramente superior al número de dispositivos que haya en línea. Este modelo es distinto al navegador web, que suele abrir una conexión para recuperar una página web o imagen y luego cierra inmediatamente la conexión una vez que la solicitud se ha completado.
• Si el proxy inverso va a autenticar las credenciales del dispositivo móvil, debe ser capaz de devolver un código de respuesta HTTP 401 para una posible autenticación incorrecta de las credenciales del usuario. El proxy no debe devolver una página web orientada al usuario con una respuesta HTTP 200 (Correcto) a los dispositivos móviles. Esto debe ser así porque los clientes de sincronización en los dispositivos móviles no pueden interpretar una página o formulario web orientada al usuario; en su lugar, se basan en códigos de respuesta estándar de Internet que indican que la autorización ha sido incorrecta.
• Las conexiones entre el dispositivo y el servidor de IBM Traveler utilizan los métodos HTTP GET, POST, y OPTIONS. Compruebe si los tres métodos están permitidos.
• El cliente de administración web requiere los métodos HTTP GET, POST, PUT y DELETE. Verifique que estos cuatro métodos están permitidos si utiliza un proxy también para realizar la administración basada en web del servidor de IBM Traveler.
• Las conexiones HTTP o HTTPS del dispositivo pueden ser de larga ejecución (de hasta 30 minutos para enviar las conexiones), por lo que se debe de asegurar de que las conexiones sean excelentes para ese tiempo y no se desactiven antes de tiempo.
• Asegúrese de que la respuesta HTTP OPTIONS procede del servidor de IBM Traveler y no del servidor proxy inverso.
• Asegúrese de que la respuesta HTTP 449 no se cambia por una respuesta HTTP diferente (por ejemplo la 500).
• Evite respuestas HTTP 500, ya que algunos dispositivos resincronizarán todos los datos después de varias respuestas HTTP 500. Normalmente se pueden utilizar respuestas HTTP 503 en su lugar.
• Evite que HTTP 301 y 302 se redireccione, ya que los dispositivos, como respuesta, convierten los POST en GET. Por definición, un GET no contiene cuerpo, por lo que el cuerpo que había en el POST faltará.
• El servidor proxy no debe codificar ni descodificar URL. Cualquier URL a o desde un servidor de IBM Traveler ya debería estar adecuadamente codificado. Si se codifica un URL dos veces, puede dañar los argumentos del URL y hacerlo inutilizable.
• Algunas soluciones de gestión de dispositivos móviles (MDM - Mobile Device Management) utilizan un proxy para controlar las comunicaciones entre el dispositivo móvil y IBM Traveler. Si utiliza una solución de este tipo, compruebe con su proveedor de MDM que da soporte a todas las aplicaciones de IBM Traveler en dispositivos móviles o determine si hay restricciones conocidas a lo que da soporte el proveedor de MDM. Las aplicaciones soportadas de IBM Traveler utilizan diversos protocolos de comunicaciones, incluyendo Exchange ActiveSync y SyncML. Los proxy HTTP generales no examinan los flujos de datos subyacentes, pero algunas soluciones de MDM requieren un protocolo subyacente específico para dar soporte a esto. IBM Traveler para Android, Tareas de IBM Traveler para dispositivos iOS y Traveler Companion no utilizan el protocolo Exchange ActiveSync y es posible que no todos los proveedores de MDM que sólo dan soporte a aplicaciones compatible con Exchange ActiveSync les den soporte.
• /Microsoft-Server-ActiveSync*, /servlet/traveler*, /traveler* se deben pasar todos a IBM Traveler y no se deben correlacionar a nada en concreto (Domino HTTP realizará la correlación cuando sea necesario).