Dead Packets

04/03/2011

Troubleshooting de conexão RPC

Filed under: troubleshooting — drak @ 8:49 AM

Um problema de comunicação que não passa por um firewall é mais difícil de ser analisado pois você não tem prontamente um jeito de realizar o dump dos pacotes, seria necessário espelhar a porta do switch e capturar em outra porta, o que geralmente não é tão simples dependendo do ambiente que você está (datacenter, portas livres, etc).

Nesse caso temos que analisar o caso confiando nos testes entre as pontas. Um caso interessante que eu peguei foi o seguinte: Os clients Outlook da uma determinada localidade não conseguiam conectar no servidor de Exchange, acessível por uma rede MPLS a partir desta localidade, não haviam firewalls nesse caminho.

Os testes começaram com conectividade básica, ping de um lado para outro funcionavam normalmente, foi solicitado o tracert do cliente até o servidor, o que não agregou nada relevante, seguimos para teste de conexão na TCP/135 (conforme indicado pelo KB da Microsoft na seção “Communication between Exchange Client computers and Exchange Server computers”) e o teste de conexão também teve sucesso, a conexão fechava normalmente.

A equipe de Messaging procedeu para testes com o utilitário PortQry que testa a conexão RPC de maneira completa, ou seja, após abrir a conexão na porta TCP/135 também realiza a chamada ao serviço portmapper que lista todos os programas que se registraram no serviço RPC remoto. Durante este teste era possível ver que embora a conexão fosse estabelecida, como esperado, ocorria um erro, veja o log:

Querying target system called:
srv_exchange
Attempting to resolve name to IP address...
Name resolved to 192.168.10.20
querying...
TCP port 135 (epmap service): LISTENING
Using ephemeral source port
Querying Endpoint Mapper Database...
Server's response:
RPC query failed (6bf).
Querying target system called:
srv_exchange
Attempting to resolve name to IP address...
Name resolved to 192.168.10.20
querying...
TCP port 11020 (unknown service): LISTENING
TCP port 11021 (unknown service): NOT LISTENING
TCP port 6001 (unknown service): LISTENING

Com essa nova informação procuramos levantar se no ambiente havia algum dispositivo que pudesse influenciar na aplicação mas não na conectividade, um exemplo disso seria um IPS na rede, antivírus da estação de trabalho ou no servidor ou algum firewall desconhecido no caminho, depois de eliminadas estas possibilidades iríamos começar a analisar o pacote em cada ponto por onde ele passava, para isso foi re-verificado o tracert do desktop para o servidor Exchange e outro no sentido contrário, com o resultado desses tracerts notou-se que o número de hops era diferente, após revisão desta informação constatamos que os pacotes do cliente para o servidor estavam indo pelo link principal, porém a volta estava pelo link backup, devido a este comportamento assimétrico estava ocorrendo o problema com a aplicação RPC.

Como não havia nenhum dispositivo statefull no caminho existia conectividade, porém quando a aplicação efetivamente entrava no tráfego a mesma não se comportava como deveria. Após a correção das tabelas de roteamento o problema foi resolvido.

Referências
TCP ports and Microsoft Exchange: In-depth discussion
Analyzing Exchange RPC traffic over TCP/IP
How to Use Portqry to Troubleshoot Active Directory Connectivity Issues

Anúncios

Deixe um comentário »

Nenhum comentário ainda.

RSS feed for comments on this post. TrackBack URI

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

Blog no WordPress.com.

%d blogueiros gostam disto: