Rede

Rastrear problemas de rede enganosos

Christopher Stoneff

Visão geral:

• As causas habituais dos problemas de rede
• Indo além do óbvio
• Quando as ferramentas para solução de problemas não ajudarem
• Por que você precisa configurar limites de conexão

É provável que já tenho visto isso muitas vezes – a máquina não consegue se comunicar com as demais e você não sabe o porquê. O sistema de gerenciamento fica em um segmento de uma rede roteada conectada a outros segmentos de rede por meio de um roteador como, por exemplo, o Microsoft Internet

Security and Acceleration (ISA) Server ou outro dispositivo de hardware. Ao tentar gerenciar 10, 20 ou até mesmo 100 sistemas, você não enfrenta nenhum problema. Mas quando você tenta gerenciar 500, o computador não consegue se comunicar na rede, exceto com as máquinas com as quais ele já mantém conexões abertas. Não é possível se comunicar com qualquer outro sistema, acessar a Internet, ainda que mais ninguém na rede, inclusive o seu segmento, esteja diante desse fenômeno. Onde você começaria a olhar?

Diagnosticando o problema

A pressuposição mais comum nessa situação é a de que o software de gerenciamento apresenta defeito. Muitas ferramentas de gerenciamento proativas se conectam aos sistemas e os gerenciam, mas elas próprias podem, às vezes, causar o problema que você está tentando rastrear. Isso porque uma ferramenta de gerenciamento proativa pode gerar milhares de conexões para os dispositivos em nome de um melhor gerenciamento. O Windows® manterá essas conexões abertas durante dois minutos por padrão, mesmo quando elas estiverem ociosas, a menos que a ferramenta, o aplicativo ou o serviço as mantenham ativas por mais tempo. Isso significa que, mesmo que o sistema de gerenciamento não tenha falado com nenhuma máquina em dois minutos, talvez você ainda tenha mais de mil conexões abertas. (É possível exibir as conexões abertas executando NETSTAT em um prompt de comando. O comando NETSTAT mostrará a você todas as conexões abertas, pendentes e de fechamento para e do sistema, além de lhe dar seu status. As descrições das mensagens de status podem ser encontradas no RFC 793 em tools.ietf.org/html/rfc793.)

Para descartar o software de gerenciamento que não está funcionando corretamente, é possível criar um arquivo em lotes que estabelece conexões com sistemas remotos. Se o mesmo problema ocorrer durante a execução do arquivo em lotes, você conhecerá o software de gerenciamento e seus threads não deviam ser responsabilizados. Este é um exemplo do conteúdo do arquivo em lotes necessário:

Net use \\system01\ipc$ Net use \\system02\ipc$ Net use ...

Caso o programa de gerenciamento em questão implemente sua própria pilha de rede e de autenticação, talvez ele seja o culpado, mas em soluções sem agentes como a maioria desses pacotes de gerenciamento, a ferramenta usa as pilhas de rede e de autenticação do sistema operacional para realizar operações de rede. O uso de um arquivo em lotes que inicia qualquer número de conexões de rede sem causar a falha mostra que o problema não é resultado do uso do programa das pilhas de rede e de autenticação do sistema operacional, uma vez que o arquivo em lotes também as usa.

Logs e mensagens de erro que não ajudam

Você deve ter notado que, assim que as conexões começaram a falhar, você recebeu informações sobre falhas equivocadas: erro 53 – caminho de rede não encontrado, erro 64 – o nome da rede foi excluído e erro 1203 – nenhum provedor de rede aceitou o caminho de rede fornecido. Tudo isso pode normalmente indicar problemas de resolução de nomes, exceto por todas as demais máquinas que não estejam enfrentando problemas ao resolver nomes e se conectar aos mesmos sistemas. Para verificar se as configurações da máquina não apresentam alguma falha, basta executar ipconfig para confirmar se elas estão corretas.

Em seguida, como o fenômeno parece estar localizado no sistema de gerenciamento, você deve observar os logs de eventos. Uma pesquisa nos logs do aplicativo não traz muitos frutos, mas no log do sistema você encontra um evento de aviso 4226 do TCP/IP de origem do evento informando que o número máximo de conexões foi atingido (consulte a Figura 1).

Figure 1** TCP connection limit has been reached **

Realizar uma pesquisa completa na Base de Dados de Conhecimento Microsoft® em busca dos limites de conexão revelará o fato de que há limitações de conexão impostas para conexões incompletas, embora não haja nenhum limite para conexões completas. Você tem a possibilidade de ajustar as seguintes entradas do Registro em HKLM\System\CurrentControlSet\Services\TCPIP\Parameters para controlar os fatores já mencionados: TcpNumConnections é usado para definir o número máximo de conexões que o protocolo TCP é capaz de manter abertas simultaneamente (o padrão é 10). TCPTimedWaitDelay define o tempo durante o qual uma conexão permanece no estado TIME_WAIT quando está sendo fechada. O tempo médio padrão é de 120 segundos, o que significa que uma conexão está basicamente em uso durante 4 minutos. Por fim, MaxFreeTcbs também tem sua função no número máximo de conexões. Caso todos os blocos de controle TCP estejam sendo usados, o protocolo TCP deve liberar as conexões listadas com um estado TIME_WAIT para criar mais conexões, mesmo que TCPTimedWaitDelay ainda não tenha expirado. TCPTimedWaitDelay tem um intervalo de valores entre 30 e 300 segundos (0x1E a 0x12C).

Dependendo do cenário, você pode notar uma pequena melhora no desempenho geral com essas alterações feitas no Registro. Outra etapa que você pode tentar executar é corrigir o arquivo TCPIP.sys para remover esses limites, embora isso só apresente aperfeiçoamentos em aplicativos P2P.

Capturas de rede

Após outras tentativas malsucedidas de resolver os problemas de conexão, uma captura de rede das máquinas envolvidas parece um recurso promissor. Quando executei o Monitor de Rede da Microsoft (Netmon), ele produziu capturas que exibiam os resultados exatos em relação ao que eu estava vendo nas ferramentas de gerenciamento e nos scripts de teste: tudo funciona e deixa de funcionar, sem mais nenhuma indicação do erro.

A <Fig>Figura 2</Fig> mostra o resultado da execução de Netmon, que indicava a comunicação bem-sucedida entre os primeiros n sistemas. Observe que estou conseguindo confirmações das solicitações RCP. É isso o que você deseja ver – comunicação bidirecional bem-sucedida.

Figure 2** Successful communication in Netmon **(Clique na imagem para aumentar a exibição)

Agora você precisa observar as capturas do sistema de gerenciamento e das máquinas remotas que aparentam exibir o erro 53/1203. Como já se esperava, não há nada para ver, já que as máquinas não estão se comunicando. Na captura de rede da Figura 3, o sistema de gerenciamento resolveu o endereço IP e tentou se conectar ao sistema usando a porta 445 (a porta SMB Microsoft), mas jamais recebeu uma resposta.

Figure 3** Attempts to connect to the system over port 445 yield no response **(Clique na imagem para aumentar a exibição)

O erro exibido quando você tem mais threads do que a capacidade de conexão atual da máquina nem sempre é consistente. Em alguns casos, talvez você veja um erro 53 no sistema de origem, o que indica que recebeu a resolução de nomes, mas que o endereço IP simplesmente não pôde ser encontrado. Isso é um indício de que o DNS está fornecendo um endereço ao qual você não consegue se conectar. Você pode receber um erro 1203 indicando que nenhuma máquina respondeu ao nome ou ao endereço IP solicitado. O erro 1203, nesse caso, indica que o DNS não está disponível para você. Você verá se esse é o caso, se executar nslookup.

Neste ponto, você já está prestes a se sentir frustrado, mas há mais opções a serem consideradas. A maioria das pessoas sequer pensará em olhar a infra-estrutura de conexão por conta da forma com que esse problema se apresenta: como a sua máquina é a única incapaz de se conectar ao restante da rede e os logs de eventos mostram que essa máquina atingiu o número máximo de conexões permitidas, o problema não parece ser de natureza arquitetônica.

Embora as milhares de conexões geradas pela solução em gerenciamento não sejam iniciadas simultaneamente, keep alives de transmissão e tempos limites de conexão podem indicar que você tem mais conexões abertas a qualquer momento do que pode imaginar. Por isso, você também deve examinar esses sistemas que se conectam ao restante da rede.

Deixe-me explicar. Como eu disse anteriormente, na medida em que passa pela rede, o tráfego passa por comutadores, roteadores e, quem sabe, firewalls. Em qualquer um desses pontos, normalmente o roteador ou o firewall, você pode encontrar sistemas de detecção de intrusões. Comutadores e roteadores gerenciados também podem usar a filtragem de tráfego. Você, ou quem tiver controle sobre esses dispositivos, precisará verificar os logs em busca de erros ou de avisos. O problema de comunicação pode muito bem estar nesses sistemas.

Por estar se conectando de um sistema interno a outros sistemas internos, você talvez ache que não há alertas sendo gerados, uma vez que o alerta não está configurado no dispositivo ou porque o problema não se qualifica como intrusão ou ataque de negação de serviço (DoS). Mais uma vez, você deve começar pelos logs. Usando o ISA Server como exemplo, esses logs podem ser encontrados no console Gerenciamento do ISA Server em Matrizes\<Nome_da_Matriz>\Monitoramento\Log.

Caso haja uma diretiva lhe impedindo, você pode (no caso do ISA Server) procurar os seguintes códigos resultantes em que o protocolo IP de origem é o seu computador de gerenciamento:

• 0xc0040037 FWX_E_TCP_RATE_QUOTA_EXCEEDED_DROPPED
• 0xc004000d FWX_E_POLICY_RULES_DENIED
• 0xc0040017 FWX_E_TXP_SYN_PACKET_DROPPED

Caso encontre esses resultados, você identificou a raiz dos problemas de conectividade.

Implementando a solução

Agora que você identificou o problema, a solução pode ser simples, mas a política do departamento pode dificultar sua implementação. Antes de fazer qualquer alteração, verifique se você tem as permissões apropriadas para isso, já que a criação de exclusões nas configurações de segurança dos firewalls, roteadores e/ou sistemas de detecção de intrusões nem sempre é permitida.

Novamente, usando o ISA Server como exemplo, as seguintes etapas mostram como aumentar o número máximo de conexões de um determinado host ou de todas as máquinas na rede (como mostra a Figura 4). Abra o console Gerenciamento do ISA Server e navegue até Matrizes\<Nome_da_Matriz>\Configuração\Geral\Definir Configurações de Redução de Inundação.

Figure 4** Increase the maximum number of connections for one host or all machines using ISA Server **

As duas configurações importantes são as conexões TCP simultâneas máximas por endereço IP e solicitações de conexão TCP máximas por minuto para cada endereço IP. As conexões TCP simultâneas máximas por endereço IP costumam ser definidas em um valor que seria o suficiente onde não houvesse nenhum gerenciamento ativo, o que significa que nenhum computador está ativamente se conectando a milhares de outras máquinas rapidamente. No ISA Server, o limite padrão para conexões TCP máximas é de 160. As solicitações de conexão TCP máximas por minuto para cada endereço IP foram projetadas para limitar os danos e a visibilidade dos exames da rede. O limite padrão é de 600 solicitações de conexão por minuto para cada IP.

Conforme dito anteriormente, o Windows manterá uma conexão ativa durante um período padrão de dois minutos, desde que mais nada esteja tentando fazer o mesmo, ainda que a conexão não esteja sendo usada. Isso significa que, muito embora você já tenha conseguido gerenciar um computador com êxito e não precise mais se comunicar com ele, a conexão permanecerá ativa. Essa conexão aberta é contabilizada para o número total de conexões alocadas. Repita esse processo mais de 160 vezes sem remover as conexões, e você verá que todas as tentativas de conexão estão sendo negadas pelo roteador. Mesmo que o programa de gerenciamento finalize uma sessão de maneira ativa, o Windows pode muito bem manter a conexão em um estado time_wait ao aguardar o consentimento de uma máquina de destino para desconectar a sessão.

Comece fazendo os ajustes no mais provável culpado: as conexões TCP simultâneas máximas por endereço IP. Você deve definir isso de forma que a máquina de gerenciamento possa criar todas as conexões necessárias ao gerenciamento dos sistemas sem que haja a negação do acesso. Clique no botão Editar próximo da configuração e altere os valores.

A próxima solicitação (consulte a Figura 5) tem uma caixa Limite que representa o limite padrão, aplicável a todos os clientes. O limite Personalizado se aplica a todas as máquinas, redes etc. definidas na guia Exceções de IP da caixa de diálogo de redução de inundação. Caso você queira que todas as máquinas tenham permissão para criar mais conexões, altere o valor de Limite. Para configurar a exceção apenas para a sua máquina de gerenciamento, ajuste o limite Personalizado e adicione a máquina à guia Exceções de IP. Costuma ser melhor permitir a exceção apenas para a sua própria máquina.

Figure 5** Default connection limit and custom connection limit **

Caso você queira usar o limite personalizado para modificar esse valor apenas para sistemas específicos, altere o valor no campo Limite personalizado e clique em OK. Em seguida, adicione a máquina à guia Exceções de IP da caixa de diálogo de redução de inundação. Para adicionar o seu único computador à lista de exceções, em Exceções de IP, clique em Adicionar para abrir a caixa de diálogo Conjuntos de Computadores. Clique em Novo para criar um novo conjunto de redes que conterá o(s) sistema(s) se ainda não houver um conjunto contendo essas máquinas. Selecione o conjunto de redes, clique em Adicionar para adicionar o conjunto Redes Internas e em Fechar. Selecione novamente o conjunto de redes Redes Internas e clique em Editar. Isso abrirá as propriedades de Redes Internas (consulte a Figura 6). Clique em Adicionar na caixa de diálogo para exibir um submenu em que é possível optar por adicionar um computador, um intervalo de endereços ou uma sub-rede; escolha o computador. Digite um nome para identificar a entrada, o endereço IP da máquina e uma descrição para que qualquer um que esteja vendo essa entrada mais tarde não se sinta tentado a remover o sistema (consulte a Figura 7). Clique em OK para adicionar o sistema e clique nele novamente para adicionar a exceção. Agora que já fez essas alterações, você deve aplicar as configurações.

Figure 6** Internal networks properties settings **

Figure 7** Enter computer name, IP address, and description to ensure your system is not removed **

Tente usar a ferramenta de gerenciamento proativa novamente, e você deve notar que o desempenho está muito melhor, além da conexão não apresentar nenhuma falha – pelo menos não em decorrência do tráfego de rede. No final das contas, acontece que o problema não foi o número de conexões iniciadas pelo software, e sim a falta de planejamento apropriado para elas a responsável pela interrupção.

Lições aprendidas

Uma das maiores dores de cabeça da TI é enfrentar e resolver os problemas realmente enganosos. Trata-se de problemas que não foram criados pelo usuário final ou pela equipe do servidor, que o suporte técnico desconhece e que, infelizmente, é de sua responsabilidade resolvê-los. Existem algumas ferramentas disponíveis que podem lhe ajudar a solucionar, isolar e resolver problemas, mas, às vezes, elas não são o suficiente. Às vezes, elas estão erradas. E, em outras, você apenas precisa ser mais esperto do que elas.

Na próxima vez em que você se encontrar incapaz de estabelecer conexões com algumas máquinas da sua rede sem nenhuma razão aparente, tente executar as etapas que descrevi aqui. Há uma boa chance de, seguindo as etapas, observando o software de gerenciamento mais atentamente e configurando as conexões permitidas corretamente, conseguir resolver o problema com êxito.

Christopher Stoneff é gerente de produtos da Lieberman Software (liebsoft.com), uma desenvolvedora de softwares de segurança e de gerenciamento de sistemas. Chris tem mais certificações técnicas do que qualquer pessoa sã é capaz. A sua principal motivação não é apenas saber como algo funciona de uma determinada forma, mas por quê.

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida..