Utilizar um proxy inverso, difusor de IP ou sistema de equilíbrio de volumes

Os diagramas neste tópico apresentam uma topologia de rede, em que um proxy inverso reside na DMZ e fornece serviços de autenticação para os clientes do dispositivo móvel.

O primeiro diagrama representa um servidor autónomo do IBM Traveler nesta topologia.

O segundo diagrama apresenta a mesma topologia de rede com um conjunto de elevada disponibilidade de servidores do IBM Traveler. Neste caso, a função de difusor ou balanceamento de carga dos pedidos do dispositivo é fornecida por um servidor em separado no domínio fidedigno.

O terceiro diagrama apresenta a topologia de rede com o proxy de autenticação, fornecendo também a possibilidade de difundir pedidos móveis para o conjunto de elevada disponibilidade de servidores do IBM Traveler. O IBM® Mobile Connect pode fornecer o proxy de autenticação e solicitar a função de difusor.

Esta topologia de rede não permite tanta flexibilidade como a topologia VPN. No entanto, fornece uma implementação de rede segura que não expõe qualquer infra-estrutura do servidor do IBM Domino à Internet ou a zonas DMZ.

O IBM Traveler foi testado com vários produtos de proxy inverso, mas a maioria dos produtos com uma função padrão de proxy inverso são adequados. Em seguida, são apresentados alguns aspectos a considerar ao seleccionar um proxy inverso:

• Verifique se o proxy inverso consegue suportar um número de ligações HTTP prolongadas igual aos clientes de dispositivo móvel existentes na rede. Quando o envio é activado nos dispositivos móveis, estes abrem um pedido de HTTP ou HTTPS para o servidor, que permanece aberto até ocorrer um tempo limite ou até chegarem novos dados. De facto, isto significa que o número de ligações HTTP ou HTTPS é igual ou ligeiramente superior ao número de dispositivos online. Este modelo é diferente de um navegador da Web, que normalmente abre uma ligação para obter uma imagem ou página da Web e fecha, imediatamente, a ligação após o pedido ter sido efectuado.
• Se o proxy inverso for efectuar a autenticação das credenciais do dispositivo móvel, tem de ter a capacidade de devolver um código de resposta HTTP 401 para uma autenticação com falha das credenciais do utilizador. O proxy não pode devolver uma página da Web orientada para o utilizador com uma resposta HTTP 200 (OK) aos dispositivos móveis. Isto deve-se ao facto de os clientes de sincronização nos dispositivos móveis não conseguirem interpretar um formulário ou página da Web orientada para o utilizador. Em alternativa, baseiam-se nos códigos de resposta padrão da Internet que indicam a falha da autorização.
• As ligações do dispositivo ao servidor do IBM Traveler utilizam os métodos HTTP GET, POST e OPTIONS. Verifique se os três métodos são permitidos.
• O cliente de administração da Web requer os métodos HTTP GET, POST, PUT e DELETE. Verifique se estes quatro métodos são permitidos, caso esteja a utilizar um proxy para efectuar igualmente a administração baseada na Web do servidor do IBM Traveler.
• As ligações HTTP ou HTTPS do dispositivo podem ser demoradas (até 30 minutos para ligações de envio), pelo que deve assegurar-se de que o proxy irá permitir que as ligações fiquem pendentes durante todo este tempo, não excedendo o tempo limite mais cedo.
• Certifique-se de que a resposta HTTP OPTIONS é recebida do servidor do Traveler e não do proxy inverso.
• Certifique-se de que uma resposta HTTP 449 não é alterada para uma resposta HTTP diferente (por exemplo, 500).
• Evite respostas HTTP 500, já que alguns dispositivos efectuam uma nova sincronização de todos os dados após várias respostas HTTP 500. Geralmente é possível utilizar respostas HTTP 503 como alternativa.
• Evite redireccionamentos HTTP 301 e 302, já que os dispositivos alteram frequentemente, na resposta, POSTs para GETs. Por predefinição, um GET não contém um corpo, pelo que o corpo no POST poderá estar em falta.
• O servidor proxy não deverá codificar ou descodificar URLs. Qualquer URL para ou de um servidor do IBM Traveler já deverá estar correctamente codificado. Se codificar um URL duas vezes, poderá danificar os argumentos do URL e este poderá tornar-se inutilizável.
• Algumas soluções do MDM (Mobile Device Management) utilizam um proxy para controlar comunicações entre o dispositivo móvel e o IBM Traveler. Se estiver a utilizar uma solução deste tipo, confirme com o fornecedor de MDM se esta tem a capacidade de suportar todas as aplicações do IBM Traveler em dispositivos móveis ou determine se existem restrições conhecidas relativamente ao que o fornecedor de MDM pode suportar. As aplicações suportadas do IBM Traveler utilizam vários protocolos de comunicações, incluindo Exchange ActiveSync e SyncML. Os proxies HTTP gerais não examinam os fluxos de dados subjacentes, mas algumas soluções de MDM requerem um protocolo subjacente específico para o suporte. O IBM Traveler para Android, o IBM Traveler To Do para dispositivos iOS e o Traveler Companion não utilizam o protocolo Exchange ActiveSync e poderão não ser suportados pelos fornecedores de MDM que apenas suportam aplicações com capacidade para Exchange ActiveSync.
• /Microsoft-Server-ActiveSync*, /servlet/traveler* e /traveler* devem ser passados para o IBM Traveler e não é necessário mapeá-los para qualquer local em particular (o Domino HTTP assegurará o mapeamento conforme necessário).