Resolução de problemas do Website dentro da rede local

6

Tenha um site externo que abre bem em alguns PCs, mas parece que o tempo limite (ou os sintomas de tempo limite, mas nunca chega) em outros.

Parece afetar apenas alguns dos nossos mais recentes Estações de trabalho do HP Pro 3305 MT . Todos os que estão executando o Win7 32bit SP1 com todas as atualizações. PCs mais antigos (Win7 32bit SP1 e WinXP) não são afetados.

Usando o Google Chrome & O Firefox não faz diferença. Abrir o site no modo de compatibilidade do IE9 tem exatamente os mesmos sintomas.

Todos os PCs estão na mesma rede local (grupo de trabalho) usando o mesmo servidor DNS & gateway (inhouse) na mesma conexão à Internet, na mesma sub-rede. Não há nenhum servidor proxy, nenhum filtro de conteúdo, nenhum balanceamento de carga, etc. etc. Apenas a diretiva de grupo em vigor (localmente) é para Agendamento de atualização. Firewalls locais são todos iguais (Kaspersky WP4) e nosso firewall externo não possui configurações específicas de IP.

Eu não tenho controle sobre o site externo, o traceroute mostra o mesmo destino em todos os PCs. É um site bastante popular em nossa indústria (Horticultura) e eu não tenho conhecimento de nenhuma outra pessoa (mesmo outros sites dentro de nossas empresas-irmãs) com o mesmo problema.

Atualização: Usou o Fiddler2 para monitorar a requisição HTTP, parece que ela não está sendo cumprida por algum motivo?!

Pedido enviado:

GET http://www.rhs.org.uk/ HTTP/1.1
Host: www.rhs.org.uk
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.47 Safari/536.11
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

Faça login no Fiddler 2 da solicitação:

This session is not yet complete. Press F5 to refresh when session is complete for updated statistics.

Request Count:   1
Bytes Sent:      567        (headers:567; body:0)
Bytes Received:  0      (headers:0; body:0)

ACTUAL PERFORMANCE
--------------
ClientConnected:    17:02:33.720
ClientBeginRequest: 17:02:39.118
GotRequestHeaders:  17:02:39.118
ClientDoneRequest:  17:02:39.118
Determine Gateway:  0ms
DNS Lookup:         0ms
TCP/IP Connect: 46ms
HTTPS Handshake:    0ms
ServerConnected:    17:02:39.165
FiddlerBeginRequest:    17:02:39.165
ServerGotRequest:   17:02:39.165
ServerBeginResponse:    00:00:00.000
GotResponseHeaders: 00:00:00.000
ServerDoneResponse: 00:00:00.000
ClientBeginResponse:    00:00:00.000
ClientDoneResponse: 00:00:00.000


RESPONSE BYTES (by Content-Type)
--------------
~headers~:  0

Registro de um pedido bem-sucedido de um PC funcional (feito esta manhã, desculpe o registro de data e hora diferente do anterior):

Request Count:   1
Bytes Sent:      493        (headers:493; body:0)
Bytes Received:  20,413     (headers:525; body:19,888)

ACTUAL PERFORMANCE
--------------
ClientConnected:    08:22:47.766
ClientBeginRequest: 08:22:47.766
GotRequestHeaders:  08:22:47.766
ClientDoneRequest:  08:22:47.766
Determine Gateway:  0ms
DNS Lookup:         26ms
TCP/IP Connect: 30ms
HTTPS Handshake:    0ms
ServerConnected:    08:22:47.828
FiddlerBeginRequest:    08:22:47.828
ServerGotRequest:   08:22:47.828
ServerBeginResponse:    08:22:48.905
GotResponseHeaders: 08:22:48.905
ServerDoneResponse: 08:22:48.905
ClientBeginResponse:    08:22:48.905
ClientDoneResponse: 08:22:48.905

    Overall Elapsed:    00:00:01.1388020

RESPONSE BYTES (by Content-Type)
--------------
text/html:  19,888
~headers~:  525

Então, minha pergunta evoluiu para:

Qual é a diferença entre as 2 solicitações e como eu determino por que 1 PC não está obtendo uma resposta para sua requisição GET?

Atualização 2 :

Veja minha resposta abaixo. Posso aceitá-lo no futuro, mas sem poder reproduzir o problema (ou a correção), gostaria de deixar esta questão em aberto.

    
por HaydnWVN 06.07.2012 / 13:18

7 respostas

0

A partir desta manhã, esta edição é 'fixa'.

Eu trabalhei (via e-mail) com Piers Karsenbarg em vários caminhos diferentes de resolução, tudo sem sucesso . Nada foi alterado no site e nada foi alterado nas máquinas - exceto algumas atualizações do Windows. Não posso agradecer a Piers o suficiente para se envolver com o problema e gastar muito do seu tempo de qualidade tentando resolvê-lo!

A Piers me vinculou ao este que tem todos os sintomas (mas nenhuma das causas) nessas máquinas em questão (isto é, sem fontes Tipo 1). Mas é possível um Windows Update (ou alguma atualização da Adobe) corrigido o problema - estou pensando em substituir ou remover as fontes Type 1. Mais informações podem ser encontradas aqui e < a http://www.digiblog.de/2012/06/ie9-bug-using-postscript-type-1-base-fourteen-fonts/ "> aqui .

    
por 29.08.2012 / 17:37
1

Se você quiser saber a diferença na solicitação HTTP GET, baixe o ZAP (Zed Attack Proxy) do OWASP ou algum outro proxy que permita inspecionar cada pacote antes de enviá-lo ao servidor. Isso vai responder à pergunta "qual é a diferença entre os 2 pedidos".

Se as solicitações forem as mesmas, tente outra NIC.

O mais provável é que sua NIC esteja on-board. Tente instalar uma NIC PCI com drivers apropriados e veja se você pode chegar lá. Soa como problema de hardware / driver neste momento.

    
por 12.07.2012 / 18:07
1

Eu nunca usei o Fiddler antes, mas com base no "ServerGotRequest" sendo desmarcado no cenário de falha, implica em uma de três coisas:

  1. O servidor não recebeu a solicitação completa da estação de trabalho (isto é, o HTTP GET não foi concluído)
  2. O servidor recebeu a solicitação, mas não respondeu devido a um erro ou outro problema no servidor.
  3. O servidor respondeu, mas o pacote de resposta não retornou.

Eu sei que este é um servidor hospedado, você tem acesso para ver os logs do servidor ou a capacidade de executar um sniffer nele (por exemplo, WireShark) para capturar dados enquanto está testando? Em caso afirmativo, observe os arquivos de log do servidor em busca de erros e execute o sniffer até obter um cenário de falha na estação de trabalho. Em seguida, verifique se o servidor recebeu a resposta completa e tentou responder.

Depois disso, verifique os logs do firewall Kapersky para ver se ele descartou algum pacote. É possível configurar um sniffer na frente do firewall e ver se a resposta do servidor está voltando tão longe? Se chegar ao firewall, e o Kaspersky não notar a queda de qualquer coisa, provavelmente é seguro assumir que isso aconteceu.

Durante esses testes, sugiro usar o WireShark em uma das máquinas que falham. Ele mostrará as conexões de saída, além de mostrar também as respostas recebidas pelo NIC. Se for um problema da NIC, o rastreio do sniffer deve mostrar o pacote que está sendo recebido e, a partir daí, você pode determinar se isso garante uma atualização da NIC e / ou do driver.

Como você não consegue conectar um sniffer ao lado de fora do seu firewall, você precisará trabalhar com seu ISP para que ele configure o monitoramento dos pacotes que saem do seu roteador, mas nunca receba uma resposta.

Uma vez que o ISP confirmou ou refutou sua hipótese sobre onde os pacotes estão indo, existem duas opções: Opção 1: O pacote chega ao firewall, mas NÃO sai para o ISP durante uma tentativa de falha na conexão da web. Opção 2: O pacote passa pelo firewall para a rede do ISP, mas a resposta nunca chega.

A opção 1 pode ser mais fácil de substituir e / ou reinstalar o firewall, se possível. Se for um dispositivo provido pelo ISP, você vai querer que eles salvem a configuração atual, mas apliquem uma configuração muito básica no novo sistema para garantir que não seja um problema relacionado à configuração.

A opção 2 seria legal, porque coloca o problema nelas resolvido, mas se elas não tiverem tempo para investigar, você fica com a resposta. Nesse caso, pode ser que ele saia da rede e vá para o provedor de Internet - que entra em uma lata inteira de worms tentando rastrear onde um pacote morreu.

    
por 06.08.2012 / 16:51
0

Você pode confirmar se o nic em máquinas de trabalho versus não-trabalho são da mesma marca / modelo. Você também pode confirmar que o seu ipv6 é o mesmo em todas as máquinas (em um lan interno eu desabilitaria o ipv6 por completo). Também como última verificação - verifique se não há nada no arquivo host que possa interromper o acesso à rede (c: \ windows \ drivers \ etc)

O fato de você ter descartado o navegador e o hardware (usando um live cd) me faz pensar que deve ser relacionado ao adaptador de rede.

Se tudo isso falhar - definitivamente troque os discos rígidos e veja se o problema segue o disco rígido ou o nic.

    
por 10.07.2012 / 17:41
0

Eu compararia as máscaras de rede e os endereços de gateway nos sistemas problemáticos e compararia isso com os sistemas de trabalho.

Eu já vi o problema antes e esta foi a causa - um endereço de gateway errado (mas ainda um pouco funcionando).

    
por 10.07.2012 / 17:47
0

Comece com o básico - você tem duas séries diferentes de máquinas que provavelmente têm duas séries diferentes de NICs. Os dois lados estão prontos para a negociação automática e, em caso afirmativo, estão concordando com a velocidade apropriada? Tente codificar os dois lados como um experimento para ver se ele melhora (ou se está codificado em ambos os lados atualmente, então deixe ambos os lados negociarem).

    
por 06.08.2012 / 16:21
0

Há uma grande lacuna entre

ClientConnected:    17:02:33.720

... e ...

ClientBeginRequest: 17:02:39.118

Você está perdendo pacotes ou o software de segurança do lado do cliente está quebrado. É trivial testar o primeiro com o Wireshark - e mesmo que você não veja o pacote a menos (retransmite), você pode determinar a direcionalidade da latência injetada.

    
por 07.08.2012 / 00:33