Introdução a engenharia reversa de aplicação com IAG

[アーティクル]
02/17/2010

Neste post vamos compartilhar uma experiência vivenciada em campo, advinda da necessidade de publicação da aplicação Office Communicator Web Access 2007 R2 (CWA) via IAG 2007. Alguma coisa mudou na aplicação CWA da versão 2007 para a 2007 R2 e sua publicação via IAG deixou de ser direta. E então, o que fazer?

Introdução

O Intelligent Application Gateway (IAG) é uma poderosa solução de acesso remoto que provê um vasto leque das tecnologias tal como VPN, VPN/SSL, port forwarding e proxy reverso para publicação de aplicações. Ele provê também controle de acesso incluindo mecanismos para autenticação de cliente, single-sign-on e uma variedade de políticas de acesso. A próxima geração desta solução é chamada Forefront Unified Access Gateway (UAG), a qual oferecerá mais tecnologias dentre as quais Windows 7 SSTP e Windows 2008 R2 Direct Access.

Com o uso do IAG, todas as aplicações Web são publicadas via mecanismos de proxy reverso. Isto permite ao IAG ver o que é transportado e tomar ações quando necessário, como por exemplo, reescrever links HTML em uma página, transformando nomes internos (como as https://finance.internal.private/logo.Gif) em nomes públicos para internet (como https://finance.mypublicname.com/logo.Gif).

No entanto, as “aplicações web” evoluíram e não são mais compostas simplesmente de páginas "HTML" estáticas. A maioria das aplicações web contém código executável que produz mudanças em conteúdo/comportamento em tempo de execução. Portanto, publicar tais aplicações web pode falhar quando se usa um proxy reverso (não importando o tipo ou marca). Proxies reversos podem reescrever links HTML numa página sem problemas, mas e se os links vêm de fomas não esperadas?

Qual é a questão técnica aqui? Bem, se na página você houver um pedaço de código, isso significa que a “renderização” desta página (feita pelo browser do cliente) será parcialmente gerada pela execução do código, o qual pode conter variáveis pré-definidas que fazem referência a nomes internos. O resultado é que, uma vez que a página é “renderizada” pelo browser (lembrando que o usuário está na Internet, fora da rede corporativa) alguns dos links permanecerão “links internos”, provocando falhas no browser quando este tenta fazer a conexão. Mas na maioria das vezes, erros randômicos serão gerados dependendo do framework usado no desenvolvimento.

E o que pode ser feito para corrigir isso? A maioria dos proxies reversos não tem mecanismos nativos para fazê-lo. A “engine” é preparada para alterar somente código HTML e a extensão de tal funcionalidade normalmente é tratada via SDK, cujo uso normalmente requer habilidades avançadas em C++. No caso do IAG, o mecanismo para realização deste trabalho já está disponível para IT Pros e é chamada de “ApplicationWrapping/SRA”. Com este recurso, pode-se mudar praticamente tudo num fluxo de dados: cabeçalho, HTML, javascript, java, etc. Esta “engine” requer um arquivo de configuração, baseado em XML, e utiliza uma linguagem de macro que é descrita no manual de administração avançada do IAG.

O Office Communicator Web Access 2007 R2 (CWA), liberado em meados de 2009, infelizmente tem problemas na publicação e apresenta o comportamento descrito acima. Por algum motivo (que vamos descrever na sequência) o CWA 2007 R2 não estava funcionando através do IAG.

O sintoma

Quando iniciamos os testes do CWA publicado através do IAG notamos um comportamento estranho: primeiro algumas figuras estavam faltando na página de login e então apresentava o erro “Error code: 1‑0‑400”, como pode-se ver abaixo:

A metodologia

A metodologia para analisar e corrigir este comportamento envolve, basicamente, capturar o tráfego HTTP e observar a transação. Ao olhar o tráfego HTTP precisamos identificar:

Qual é o problema e onde ele ocorre,
o motivo,
e então, como corrigir usando as “engines” do IAG (“AppWrap/SRA”).

O papel do IAG, neste caso, será mudar o que está provocando o problema, ao passo que o nosso papel (IT Pros) será dizer ao IAG o que mudar.

Um recurso imprescindível na busca pelo problema é um analisador HTTP, como o “HttpWatch”, ao invés de analisadores de rede como “Wireshark” ou “Netmon”.

O problema

Vamos então reproduzir o problema e capturar o tráfego. Neste exemplo nós usamos o “HttpWatch” para capturar o tráfego HTTP. Observando o quadro abaixo com a captura, já podemos identificar o problema:

Nesta captura de tela pode-se ver que as primeiras cinco requisições HTTP (no retângulo amarelo com número “1”) funcionaram bem. Podemos verificar isso na coluna “Result” correspondente às requisições GET, as quais geraram HTTP status “200”, que significa sucesso.

A partir de certo momento (requisição 6) podemos ver que as requisições retornam erro (neste caso, uma mensagem referindo-se a problema de resolução de nome). Ao olhar as requisições HTTP que falham (no retângulo vermelho com número “2”), vemos que a URL requisitada pelo Internet Explorer (IE) não é mais a URL internet que se usava para chegar ao IAG, mas sim a URL da aplicação interna. E agora que sabemos qual é o problema, vamos tentar encontrar a causa...

Identificando a causa

O primeiro erro ocorre quanto o IE tenta fazer o download de um arquivo chamado “detailbar_up_hover.gif”.

Então, tentamos identificar a fonte do problema, localizando o elemento que anteriormente instruiu o IE a fazer o download deste arquivo, o que poderia ser tanto uma tag HTML (mas isso sabemos que o proxy reverso pode tratar e reescrever sem problemas) ou um pedaço de código baixado anteriormente.

O que fazemos é uma busca (usando a ferramenta “find” do HttpWatch) pela palavra “detailbar_up_hover.gif“, a partir da requisição que falhou, no sentido do início (upward). E com isso encontramos a requisição e a resposta contendo tal palavra. O que obtemos é:

Request:

GET /whalecom754aec20c6043b78fe481a84322ae50e153495e7/whalecom1/cwa/client/Resource.aspx?param=1-2-13825|2-2-5|4-2-17409 HTTP/1.1

Se olharmos então para a resposta de tal requisição, que é basicamente “dê-me o conteúdo de resource.aspx file” (detalhe no quadro abaixo), podemos encontrar alguns códigos javascript contendo variáveis que guardam links com nomes internos. E isso é um problema!

E por que o proxy reverso não pode mudá-las? Simplesmente porque são programados para analisar somente código HTML, buscando por tags “HREF”.

Segue abaixo um recorte da página “resource.aspx”, com o código gerador do problema, destacando a referência a links internos:

var L_Menu_UpArrow = "https://ocs-cwa.fabrikam.com/cwa/Client/3.5.6907.0000/Loc/Image/detailbar_up_hover.gif";var L_Menu_DownArrow = "https://ocs-cwa.fabrikam.com/cwa/Client/3.5.6907.0000/Loc/Image/detailbar_down_hover.gif";var L_Presence_FreeImg = "https://ocs-cwa.fabrikam.com/cwa/Client/3.5.6907.0000/Loc/Image/presence_icons/online.png";var L_Presence_IdleFreeImg = "https://ocs-cwa.fabrikam.com/cwa/Client/3.5.6907.0000/Loc/Image/presence_icons/idle.png";var L_Presence_BusyImg = "https://ocs-cwa.fabrikam.com/cwa/Client/3.5.6907.0000/Loc/Image/presence_icons/busy.png";var L_Presence_IdleBusyImg = https://ocs-cwa.fabrikam.com/cwa/Client/3.5.6907.0000/Loc/Image/presence_icons/idlebusy.png

Agora que sabemos a causa do problema: o CWA 2007 R2 está usando javascript que gera HTTP GET para a aplicação e o IAG não pode reescrever estes links por padrão, temos que dizer ao IAG como fazer a correta substituição destes links.

Como corrigir

Estamos entrando na etapa final da solução. Como dissemos anteriormente, o IAG contém uma “engine” capaz de modificar basicamente tudo. Só precisamos dizer a ele o que fazer, utilizando sua linguagem.

No caso do CWA 2007 R2 temos que fazer um “search and replace” do código HTML quando a requisição for “GET Resource.aspx”.

Para fazer isso, criamos um arquivo de configuração para o portal do IAG no TRUNK que publica o CWA 2007 R2 e aqui vão os passos para configurar o IAG:

Vá ao diretório C:\Whale-Com\e-Gap\von\conf\WebSites\<Portal>\Conf
Crie um diretório “CustomUpdate”. O arquivo de configuração será colocado aqui.
Crie um arquivo chamado “WhlFiltAppWrap_HTTPS.xml”.
Copie o texto abaixo no arquivo criado:

<APP_WRAP ver="3.0" id="RemoteAccess_HTTPS.xml">

<DATA_CHANGE>

<URL case_sensitive="false">.*/Resource\.aspx.*</URL>

<SAR>

<SEARCH encoding="base64">BASE64 ENCONDING for the internal name</SEARCH>

<REPLACE encoding="base64" using_variables="false">BASE64 ENCONDING for the external name </REPLACE>

</SAR>

</DATA_CHANGE>

</MANIPULATION>

</APP_WRAP>

IMPORTANTE: Aqui vão algumas substituições que precisam ser feitas :

Coloque a URL do nome interno de sua aplicação no “Search”
Coloque a URL com o nome internet (publicada pelo IAG) no “replace”. Esta URL tem que conter o FQDN incluindo o “HOST ADDRESS TRANSLATION (HAT)” da aplicação CWA 2007 R2 no IAG (ex: whalecom754ae…).
Com os valores substituídos, é necessário codificá-los “BASE64” (pode-se fazer isso online usando a ferramenta https://webnet77.com/cgi-bin/helpers/base-64.pl)

Após as substituições apropriadas, seu código deverá parecer com o exemplo abaixo:

Uma dica: após salvar o arquivo, clique duas vezes no respectivo arquivo XML. Com isso o IE irá “renderizar” e validar se o arquivo está correto (do ponto de vista exclusivo de sintaxe XML), pois se houver algum erro o IAG não carregará o arquivo e não o avisará disso. Simplesmente não funcionará

Uma vez que o arquivo estiver pronto e no lugar, é necessário ativar a configuração do IAG. Não se esqueça de marcar a opção “Apply changes made to external configuration settings” ou o IAG não tratará a customização.

Conclusão

O IAG provê todas as características de um proxy reverso e, adicionalmente, uma “engine” chamada AppWrap que pode substituir tudo em um tráfego HTTP. Isso permite que aplicações com problemas na publicação possam funcionar como esperado.

O CWA 2007 R2 é um exemplo prático e bom pois foi simples de corrigir. Algumas outras aplicações podem ser mais complexas, embora a metodologia de correção permaneça a mesma.

Por Lucimara Desiderá (MS Consultant, São Paulo) & Frédéric ESNOUF (MS Pre-sales IDA, Paris).

次の方法で共有