Conexão http do Ubuntu 12.04 recusada

1

Hoje, todas as nossas instalações do Ubuntu 12.04 desenvolveram um bug estranho. Sempre que você tentar acessar a Internet em um navegador (testado no Chrome e no Firefox), o apt-get / Software Center ou o comando wget / curl it emitirá erros de "Conexão recusada".

Pode ser intermitente; se eu desligar e reconectar a rede, ele funciona uma ou duas vezes e morre. O HTTPS também parece funcionar bem ou, pelo menos, está falhando menos.

O problema é o mesmo em 4 máquinas Ubuntu; temos Mint (11 & amp; 13) e Windows (Server 2003, XP, Vista e 7) na mesma rede que estão funcionando perfeitamente. Isso é completamente específico do Ubuntu.

Coisas que tentei:

  • Nenhuma das instalações do Ubuntu tem pacotes não-essenciais semelhantes instalados e nenhum parece ter sido atualizado nos últimos três dias (o problema começou em algum momento nas últimas 10 horas)
  • Nada é relatado como errado nos logs
  • O Netstat -s (veja abaixo) informa um grande número de tentativas de conexão com falha, esse é o único "erro" que posso rastrear
  • O DNS está resolvendo 100%, o que não parece ser um problema (se eu tentar acertar IPs diretamente, eles exibem o mesmo erro).
  • A única ressalva é que os nomes de host locais são totalmente acessíveis (por exemplo, server1.theoffice.domain é acessível, mas não via IP)
  • Não há semelhanças em hardware e a infraestrutura de rede foi trocada por um kit de trabalho conhecido
  • Eu corri wireshark para ver se eu poderia engolir um erro lá. Tudo parecia ser A-OK (ou seja, enviar pacotes corretamente). Eu vi muitos pacotes (ACK, RST) voltando, mas não consegui rastrear se isso era uma questão importante ou não.

Alguma coisa que eu perdi? Algum problema conhecido aparecendo no último dia ou mais?

Saída Netstat para TCP:

Tcp:
    3325 active connections openings
    3 passive connection openings
    2393 failed connection attempts
    167 connection resets received
    4 connections established
    52388 segments received
    36962 segments send out
    246 segments retransmited
    0 bad segments received.
    230 resets sent
TcpExt:
    153 TCP sockets finished time wait in fast timer
    1045 delayed acks sent
    Quick ack mode was activated 126 times
    5 packets directly queued to recvmsg prequeue.
    10 bytes directly received in process context from prequeue
    36099 packet headers predicted
    2718 acknowledgments not containing data payload received
    1136 predicted acknowledgments
    5 times recovered from packet loss by selective acknowledgements
    Detected reordering 1 times using time stamp
    1 congestion windows fully recovered without slow start
    1 congestion windows partially recovered using Hoe heuristic
    96 congestion windows recovered without slow start after partial ack
    6 TCP data loss events
    TCPLostRetransmit: 1
    1 timeouts after SACK recovery
    10 fast retransmits
    5 forward retransmits
    13 retransmits in slow start
    156 other TCP timeouts
    126 DSACKs sent for old packets
    44 DSACKs received
    42 connections reset due to unexpected data
    30 connections reset due to early user close
    8 connections aborted due to timeout
    TCPDSACKIgnoredNoUndo: 16
    TCPSpuriousRTOs: 3
    TCPSackShifted: 4
    TCPSackMerged: 14
    TCPSackShiftFallback: 23
    IPReversePathFilter: 92

outras informações

  • O Telnet na porta 80 tem o mesmo problema (conexão recusada).
por Errant 31.10.2012 / 14:44

1 resposta

1

etapa 1

Suponho que você tenha feito testes bem-sucedidos com ping . traceroute e telnet .

Com telnet somehost 80 , o acessível do serviço http deve ser garantido.

Se tudo isso funcionar, o problema deve ser um problema de proxy. Assumindo que as instalações não-ubuntu estejam funcionando, uma configuração incorreta do proxy ocorrerá localmente nas instalações do ubuntu.

etapa 2

O telnet com falha mostra que o problema está abaixo da camada de aplicativo . Ping está funcionando?
Você pode verificar com nmap quais portas estão acessíveis?
Você pode verificar suas regras de firewall locais com ufw status .

Resolução

  

"o firewall estava desativado em todas as unidades, o ping estava funcionando e o nmap não mostrava nada anormal. Rastreamos isso em um bug na camada do aplicativo que cria pacotes malformados e levou ao monitoramento de abuso de rede a interceptar HTTP solicita & interrompe-os. Quase me matou ao descobrir isso! Obrigado por suas respostas "

    
por H.-Dirk Schmitt 31.10.2012 / 16:28