Risoluzione dei problemi e debug della rete Linux

Di tanto in tanto gli utenti Linux e Unix hanno dovuto affrontare vari problemi di rete. Molti di questi problemi sono presentati qui e in altri forum per la risoluzione dei problemi, ma sono molto concreti e contengono molte informazioni tecniche aggiuntive, e talvolta è piuttosto difficile comprendere il punto principale e la vera ragione del comportamento del sistema difettoso.

Ponendo questa domanda, la mia intenzione è quella di avviare una pagina wiki della comunità che consenta di generalizzare la nostra esperienza di risoluzione dei problemi e debug della rete. Spero che gli utenti Linux e Unix possano facilmente riconoscere e risolvere ("dividere e conquistare") i loro problemi di rete usando questa pagina.

Il genitore di questa pagina dovrebbe essere la migliore pratica per diagnosticare i problemi . Ma qui dovremmo concentrarci sulla risoluzione dei problemi di rete dallo spazio utente e kernel.

Suppongo, se tu:

1. Condividi le informazioni sull'utilizzo di alcuni fantastici strumenti di diagnostica di rete con esempi concreti di utilizzo ed esempi di bug di rete, che aiutano a catturare.
2. Condividi il link al fantastico tutorial di rete collegato a questo argomento
3. Racconta un metodo o una ricetta generale che consente di affrontare alcuni problemi di rete
4. Condividi le informazioni sul tuo set di strumenti per il debug della rete e la risoluzione dei problemi

si adatterebbe perfettamente per questo argomento.

Comincerò dalla condivisione del link con varios strumenti diagnostici e un semplice tutorial di 12 anni . Anche il tutorial di archlinux sembra avere informazioni reali sul nostro argomento. E per immergerci nella rete Linux dobbiamo assolutamente visitare Linux Networking-HOWTO .

Penso che i principi generali della risoluzione dei problemi di rete siano:

1. Scopri a quale livello di stack TCP / IP (o qualche altro stack) si verifica il problema.
2. Comprendi qual è il comportamento corretto del sistema e qual è la deviazione dal normale stato del sistema
3. Cerca di esprimere il problema in una frase o in più parole
4. Utilizzando le informazioni ottenute dal sistema buggy, la tua esperienza e l'esperienza di altre persone (google, vari forum, ecc.), Prova a risolvere il problema fino al successo (o al fallimento)
5. Se fallisci, chiedi ad altre persone aiuto o consigli

Per quanto mi riguarda, di solito ottengo tutte le informazioni richieste utilizzando tutti gli strumenti necessari e provo ad abbinare queste informazioni alla mia esperienza. Decidere quale livello di stack di rete contiene il bug aiuta a eliminare le varianti improbabili. L'uso dell'esperienza di altre persone aiuta a risolvere rapidamente i problemi, ma spesso porta alla situazione, che posso risolvere qualche problema senza la sua comprensione e se questo problema si ripresenta, è impossibile per me affrontarlo di nuovo senza Internet.

E in generale, non so come risolvo i problemi di rete. Sembra che ci sia una funzione magica nel mio cervello SolveNetworkProblem(information_about_system_state, my_experience, people_experience), che a volte potrebbe restituire esattamente la risposta giusta, e talvolta potrebbe anche fallire (come qui TCP muore su un laptop Linux ).

Di solito uso utils di questo set per il debug della rete:

• ifconfig(o ip link, ip addr) - per ottenere informazioni sulle interfacce di rete
• ping- per la convalida, se l'host di destinazione è accessibile dalla mia macchina. pingpotrebbe anche essere utilizzato per la diagnostica DNS di base: potremmo eseguire il ping dell'host per indirizzo IP o per nome host e quindi decidere se DNS funziona affatto. E poi tracerouteo tracepatho mtrper vedere cosa sta succedendo lì.
• dig - diagnostica tutto DNS
• dmesg | lessoppure dmesg | tailoppure dmesg | grep -i error- per capire cosa pensa il kernel Linux di qualche problema.
• netstat -antp+ | grep smth- il mio utilizzo più popolare del comando netstat, che mostra informazioni sulle connessioni TCP. Spesso eseguo alcuni filtri usando grep. Vedi anche il nuovo sscomando (dalla iproute2nuova suite standard di strumenti di rete Linux) e lsofcome in lsof -ai tcp -c some-cmd.
• telnet <host> <port> - è molto utile per comunicare con vari servizi TCP (ad es. su protocolli SMTP, HTTP), inoltre potremmo verificare l'opportunità generale di connetterci ad alcune porte TCP.
• iptables-save(su Linux) - per scaricare le tabelle complete di iptables
• ethtool - ottenere tutti i parametri della scheda di interfaccia di rete (stato del collegamento, velocità, parametri di offload ...)
• socat- lo strumento dell'esercito svizzero per testare tutti i protocolli di rete (UDP, multicast, SCTP ...). Particolarmente utile (più che telnet) con alcune -dopzioni.
• iperf - per verificare la disponibilità della larghezza di banda
• openssl( s_client, ocsp, x509...) per eseguire il debug tutte le questioni SSL / TLS / PKI.
• wireshark - il potente strumento per acquisire e analizzare il traffico di rete, che consente di analizzare e rilevare numerosi bug di rete.
• iftop - mostra i grandi utenti sulla rete / router.
• iptstate (su Linux): vista corrente del tracciamento della connessione del firewall.
• arp(o il nuovo (Linux) ip neigh) - mostra lo stato della tabella ARP.
• routeo il più recente (su Linux) ip route: mostra lo stato della tabella di routing.
• strace(o truss, dtraceo in tuscbase al sistema) - è uno strumento utile che mostra quali chiamate di sistema eseguono il problema, mostra anche codici di errore (errno) quando le chiamate di sistema falliscono. Queste informazioni spesso dicono abbastanza per comprendere il comportamento del sistema e risolvere un problema. In alternativa, l'utilizzo di punti di interruzione su alcune funzioni di rete gdbconsente di scoprire quando sono stati creati e con quali argomenti.
• per indagare sui problemi del firewall su Linux: iptables -nvLmostra quanti pacchetti corrispondono a ciascuna regola ( iptables -Zazzerare i contatori). Il LOGtarget inserito nelle catene di firewall è utile per vedere quali pacchetti li raggiungono e come sono già stati trasformati quando arrivano lì. Per ottenere ulteriormente NFLOG(associato a ulogd) verrà registrato il pacchetto completo.

Un numero sorprendente di "problemi di rete" si riduce a problemi DNS di un tipo o di un altro. La risoluzione iniziale dei problemi dovrebbe essere utilizzata ping -n w.x.y.zper escludere la risoluzione DNS di un nome host e controllare semplicemente la connettività IP. Successivamente, utilizzare route -nper verificare la route IP predefinita senza risoluzione DNS.

Dopo aver verificato la connettività IP e il routing, nslookup, hoste digin grado di fornire informazioni. Ricordare che il "blocco" può indicare che si stanno verificando timeout DNS.

Non dimenticare di controllare l'esistenza e il contenuto di /etc/resolv.conf. I client DHCP cambiano quel file con ogni lease e talvolta lo sbagliano o se lo spazio su disco è limitato, potrebbe non avvenire un aggiornamento.

Possono esserci problemi di cablaggio. Se hai accesso all'hardware, assicurati che tutti i cavi siano collegati e collegati meccanicamente. Se riesci a vedere i router o le interfacce Ethernet, assicurati che le spie dei collegamenti siano accese.

In remoto, devi dipendere da 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

"Collegamento rilevato: sì" è buono, ma 10 Mb / se Half duplex non sono buoni, poiché la scheda di rete su quel computer può fare di meglio. Ho bisogno di capire se la scheda NIC è ingigantita o il cavo lo è. Un altro computer collegato allo stesso router dice 100 Mb / s, Full duplex.