Solução de problemas e depuração de rede do Linux

68

Ocasionalmente, usuários de Linux e Unix enfrentam vários problemas de rede. Muitos desses problemas são apresentados aqui e em alguns outros fóruns de solução de problemas, mas eles são muito concretos e contêm muitas informações técnicas adicionais, e às vezes é bastante difícil entender o ponto principal e a verdadeira razão do comportamento do sistema com bugs.

Ao fazer esta pergunta, minha intenção é que inicie uma wiki na comunidade página que permita generalizar nossa solução de problemas de depuração e depuração de rede. Espero que os usuários de Linux e Unix possam reconhecer e resolver ("dividir e conquistar") seus problemas de rede com facilidade usando esta página.

O pai desta página deve ser Prática recomendada para diagnosticar problemas . Mas aqui devemos nos concentrar em solucionar os problemas de rede do espaço do usuário e do kernel.

Suponho que, se você:

  1. Compartilhe as informações sobre o uso de uma excelente ferramenta de diagnóstico de rede com exemplos concretos de uso e exemplos de erros de rede, que eles ajudam a entender.
  2. Compartilhe o link para o ótimo tutorial de rede conectado a este assunto
  3. Conte sobre um método ou receita geral que permite resolver alguns problemas de rede
  4. Compartilhe informações sobre seu conjunto de ferramentas para depuração de rede e solução de problemas

seria perfeitamente adequado para este tópico.

Vou começar compartilhando o link com varios ferramentas de diagnóstico e < a href="http://www.ruf.rice.edu/~rlug/help/net-debug.html"> tutorial simples de 12 anos . Também o tutorial do archlinux parece ter informações reais sobre o nosso assunto. E para mergulhar na rede linux nós definitivamente precisamos visitar Linux Networking-HOWTO .

    
por dr. 06.10.2012 / 15:55

3 respostas

98

Acho que os princípios gerais de solução de problemas de rede são:

  1. Descubra em que nível pilha TCP / IP (ou alguma outra pilha) ocorre o problema.
  2. Entenda qual é o comportamento correto do sistema e qual é o desvio do estado normal do sistema
  3. Tente expressar o problema em uma frase ou em várias palavras
  4. Usando informações obtidas do sistema de buggy, sua própria experiência e experiência de outras pessoas (google, vários fóruns, etc.), tente resolver o problema até o sucesso (ou falha)
  5. Se você falhar, pergunte a outras pessoas sobre ajuda ou algum conselho

Quanto a mim, geralmente obtenho todas as informações necessárias usando todas as ferramentas necessárias e procuro relacionar essas informações com a minha experiência. Decidir qual nível de pilha de rede contém o bug ajuda a eliminar variações improváveis. Usar a experiência de outras pessoas ajuda a resolver os problemas rapidamente, mas muitas vezes leva à situação, que posso resolver algum problema sem o seu entendimento e se esse problema ocorrer novamente, é impossível para mim resolvê-lo novamente sem a Internet.

E, em geral, não sei como resolvo problemas de rede. Parece que há alguma função mágica no meu cérebro chamada SolveNetworkProblem(information_about_system_state, my_experience, people_experience) , que às vezes poderia retornar exatamente a resposta certa, e também poderia falhar algumas vezes (como aqui TCP morre em um laptop Linux ).

Eu geralmente uso utils deste conjunto para depuração de rede:

  • ifconfig (ou ip link , ip addr ) - para obter informações sobre interfaces de rede
  • ping - para validação, se o host de destino estiver acessível em minha máquina. ping também pode ser usado para diagnósticos básicos de DNS - nós poderíamos pingar o host pelo endereço IP ou pelo seu nome de host e então decidir se o DNS funciona. E então traceroute ou tracepath ou mtr para ver o que está acontecendo no caminho até lá.
  • dig - diagnostica tudo DNS
  • dmesg | less ou dmesg | tail ou dmesg | grep -i error - para entender o que o kernel Linux pensa sobre alguns problemas.
  • netstat -antp + | grep smth - meu uso mais popular do comando netstat, que mostra informações sobre conexões TCP. Freqüentemente eu faço alguma filtragem usando o grep. Veja também o novo comando ss (de iproute2 o novo conjunto padrão de ferramentas de rede Linux) e lsof como em lsof -ai tcp -c some-cmd .
  • telnet <host> <port> - é muito útil para se comunicar com vários serviços TCP (por exemplo, em SMTP, protocolos HTTP), também pudemos verificar a oportunidade geral de se conectar a alguma porta TCP.
  • iptables-save (no Linux) - para descarregar as tabelas completas iptables
  • ethtool - obtém todos os parâmetros da placa de interface de rede (status do link, velocidade, parâmetros de descarregamento ...)
  • socat - a ferramenta do exército suíço para testar todos os protocolos de rede (UDP, multicast, SCTP ...). Especialmente útil (mais do que telnet) com algumas opções -d .
  • iperf - para testar a disponibilidade de largura de banda
  • openssl ( s_client , ocsp , x509 ...) para depurar todos os problemas SSL / TLS / PKI.
  • wireshark - a ferramenta poderosa para capturar e analisar o tráfego de rede, que permite analisar e capturar muitos bugs de rede.
  • iftop - mostra usuários grandes na rede / roteador.
  • iptstate (no Linux) - visão atual do rastreamento de conexão do firewall.
  • arp (ou o novo (Linux) ip neigh ) - mostra o status da tabela ARP.
  • route ou o mais recente (no Linux) ip route - mostra o status da tabela de roteamento.
  • strace (ou truss , dtrace ou tusc dependendo do sistema) - é uma ferramenta útil que mostra quais chamadas de sistema o problema processa, também mostra códigos de erro (errno) quando as chamadas do sistema falham. Esta informação geralmente diz o suficiente para entender o comportamento do sistema e resolver um problema. Como alternativa, usar pontos de interrupção em algumas funções de rede em gdb pode permitir que você descubra quando elas são feitas e com quais argumentos.
  • para investigar problemas de firewall no Linux: iptables -nvL mostra quantos pacotes são correspondidos por cada regra ( iptables -Z para zerar os contadores). O LOG target inserido nas cadeias de firewall é útil para ver quais pacotes os alcançam e como eles já foram transformados quando chegam lá. Para obter mais NFLOG (associado a ulogd ), registrará o pacote completo.
por 06.10.2012 / 15:55
14

Um número surpreendente de "problemas de rede" se resume a problemas de DNS de um tipo ou outro. A solução de problemas inicial deve usar ping -n w.x.y.z para deixar de fora a resolução de DNS de um nome de host e apenas verificar a conectividade IP. Depois disso, use route -n para verificar a rota IP padrão sem a resolução de DNS.

Após verificar a conectividade IP e o roteamento, nslookup , host e dig podem gerar informações. Lembre-se que o "bloqueio" pode indicar que os tempos limite do DNS estão ocorrendo.

Não se esqueça de verificar a existência e o conteúdo de /etc/resolv.conf . Os clientes DHCP alteram esse arquivo a cada concessão e, às vezes, cometem erros ou, se o espaço em disco for curto, uma atualização pode não acontecer.

    
por 06.10.2012 / 18:25
7

Problemas de cabeamento podem existir. Se você tiver acesso ao hardware, verifique se todos os cabos estão conectados e mecanicamente conectados. Se você puder ver roteadores ou interfaces Ethernet, verifique se as luzes de link estão acesas.

Remotamente, você precisa depender de ethtool e mii-tool .

[root@flask ~]# ethtool eth0
Settings for eth0:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
        Advertised pause frame use: Symmetric
        Advertised auto-negotiation: Yes
        Speed: 10Mb/s
        Duplex: Half
        Port: MII
        PHYAD: 24
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: g
        Wake-on: d
        Current message level: 0x00000001 (1)
                               drv
        Link detected: yes

"Link detected: yes" é bom, mas 10Mb / se Half-duplex não são bons, pois a NIC nesse computador pode ser melhor. Eu preciso descobrir se o NIC está maluco ou o cabo está. Outro computador conectado ao mesmo roteador diz 100Mb / s, Full duplex.

    
por 07.10.2012 / 01:46