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

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

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

O pai desta página deve ser uma prática recomendada para diagnosticar problemas . Mas aqui devemos nos concentrar na solução de problemas de rede a partir 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 detectar.
2. Compartilhe o link para o ótimo tutorial de rede conectado a este assunto
3. Fale sobre um método ou receita geral que permita resolver alguns tipos de problemas de rede
4. Compartilhe informações sobre seu conjunto de ferramentas para depuração e solução de problemas de rede

seria perfeitamente adequado para este tópico.

Começarei compartilhando o link para ferramentas de diagnóstico varios e um tutorial simples de 12 anos . O tutorial do archlinux também parece ter informações reais sobre o assunto. E para mergulhar na rede linux, definitivamente precisamos visitar o Linux Networking-HOWTO .

Eu acho que os princípios gerais da solução de problemas de rede são:

1. Descubra em que nível da pilha TCP / IP (ou 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 as informações obtidas no sistema de buggy, sua própria experiência e a 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 tento associá-las à minha experiência. Decidir qual nível da pilha de rede contém o erro ajuda a eliminar variantes improváveis. Usar a experiência de outras pessoas ajuda a resolver os problemas rapidamente, mas muitas vezes isso leva à situação, que eu posso resolver algum problema sem o seu entendimento e, se esse problema ocorrer novamente, é impossível 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 pode retornar exatamente a resposta certa e também pode falhar (como aqui o TCP morre em um laptop Linux ).

Eu normalmente uso utilitários deste conjunto para depuração de rede:

• ifconfig(ou ip link, ip addr) - para obter informações sobre interfaces de rede
• ping- para validar, se o host de destino estiver acessível na minha máquina. pingtambém pode ser usado para o diagnóstico básico do DNS - podemos executar ping no host pelo endereço IP ou pelo nome do host e depois decidir se o DNS funciona. E então tracerouteou tracepathou mtrpara ver o que está acontecendo no caminho para lá.
• dig - diagnosticar tudo DNS
• dmesg | lessou dmesg | tailou dmesg | grep -i error- para entender o que o kernel do Linux pensa sobre algum problema.
• netstat -antp+ | grep smth- meu uso mais popular do comando netstat, que mostra informações sobre conexões TCP. Freqüentemente eu realizo alguma filtragem usando o grep. Veja também o novo sscomando (do iproute2novo conjunto padrão de ferramentas de rede Linux) e lsofcomo em lsof -ai tcp -c some-cmd.
• telnet <host> <port> - é muito útil para se comunicar com vários serviços TCP (por exemplo, em protocolos SMTP, HTTP), também podemos verificar a oportunidade geral de conectar-se a alguma porta TCP.
• iptables-save(no Linux) - para despejar as tabelas iptables completas
• ethtool - obtenha 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 -dopções.
• iperf - para testar a disponibilidade da 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 erros de rede.
• iftop - mostre grandes usuários 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.
• routeou o mais recente (no Linux) ip route- mostra o status da tabela de roteamento.
• strace(ou truss, dtraceou tuscdependendo do sistema) - é uma ferramenta útil que mostra quais chamadas do sistema processa o problema, também mostra códigos de erro (errno) quando as chamadas do sistema falham. Essas informações costumam dizer o suficiente para entender o comportamento do sistema e resolver um problema. Como alternativa, o uso de pontos de interrupção em algumas funções de rede gdbpode permitir que você descubra quando elas são criadas e com quais argumentos.
• para investigar problemas de firewall no Linux: iptables -nvLmostra quantos pacotes são correspondidos por cada regra ( iptables -Zpara zerar os contadores). O LOGdestino inserido nas cadeias de firewall é útil para ver quais pacotes os alcançam e como eles já foram transformados quando chegam lá. Para ir além NFLOG(associado a ulogd) registrará o pacote completo.

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

Depois de verificar a conectividade IP e roteamento, nslookup, hoste digpode produzir informações. Lembre-se de que "travar" pode indicar que o tempo limite do DNS está 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, eles entendem errado ou, se o espaço em disco é pequeno, uma atualização pode não ocorrer.

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

Remotamente, você precisa depender ethtoole 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 detectado: sim" é bom, mas 10 Mb / s e Half duplex não são bons, pois a NIC nesse computador pode fazer melhor. Preciso descobrir se a NIC está enganada ou o cabo está. Outro computador conectado ao mesmo roteador diz 100Mb / s, Full duplex.