Di tanto in tanto gli utenti Linux e Unix affrontavano vari problemi di rete. Molti di questi problemi vengono presentati qui e in altri forum di risoluzione dei problemi, ma sono molto concreti e contengono molte informazioni tecniche aggiuntive, e talvolta è piuttosto difficile capire il punto principale e il vero motivo del comportamento del sistema buggy.
Facendo questa domanda, la mia intenzione è avviare un wiki della comunità pagina che consente di generalizzare la nostra esperienza di risoluzione dei problemi e debug della rete. Spero che gli utenti Linux e Unix possano riconoscere e risolvere più facilmente ("divide et impera") i loro problemi di rete utilizzando questa pagina.
Il genitore di questa pagina dovrebbe essere Best practice per diagnosticare i problemi. Ma qui dovremmo concentrarci sulla risoluzione dei problemi di rete da spazio utente e kernel.
Suppongo, se tu:
- Condividi le informazioni sull'utilizzo di un ottimo strumento diagnostico di rete con esempi concreti di utilizzo ed esempi di bug di rete, che aiutano a rilevare.
- Condividi il link al fantastico tutorial di rete connesso a questo argomento
- Raccontare un metodo o una ricetta generale che consente di affrontare alcuni tipi di problemi di rete
- Condividi informazioni sul tuo set di strumenti per il debug della rete e la risoluzione dei problemi
si adatterebbe perfettamente a questo argomento.
Inizierò condividendo il collegamento a vari strumenti diagnostici e un semplice tutorial di 12 anni. Anche il tutorial di archlinux sembra avere informazioni reali sul nostro argomento. E per immergerci nel networking linux dobbiamo assolutamente visitare Linux Networking-HOWTO.
Risposta accettata:
Penso che i principi generali della risoluzione dei problemi di rete siano:
- Scopri a quale livello di stack TCP/IP (o qualche altro stack) si verifica il problema.
- Capire qual è il comportamento corretto del sistema e qual è la deviazione dal normale stato del sistema
- Cerca di esprimere il problema in una frase o in più parole
- 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)
- Se fallisci, chiedi aiuto o qualche consiglio ad altre persone
Quanto a me, di solito ottengo tutte le informazioni richieste utilizzando tutti gli strumenti necessari e cerco di abbinare queste informazioni alla mia esperienza. Decidere quale livello di stack di rete contiene il bug aiuta a eliminare varianti improbabili. Usare l'esperienza di altre persone aiuta a risolvere i problemi velocemente, ma spesso porta alla situazione, che posso risolvere qualche problema senza che io lo capisca 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 chiamata 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 le utilità di questo set per il debug di rete:
ifconfig
(oip link
,ip addr
) – per ottenere informazioni sulle interfacce di reteping
– per la convalida, se l'host di destinazione è accessibile dalla mia macchina.ping
può anche essere utilizzato per la diagnostica DNS di base:potremmo eseguire il ping dell'host in base all'indirizzo IP o al suo nome host e quindi decidere se il DNS funziona. E poitraceroute
otracepath
omtr
per vedere cosa sta succedendo lungo la strada.dig
– diagnosticare tutto il DNSdmesg | less
odmesg | tail
odmesg | 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 dei filtri usando grep. Vedi anche il nuovoss
comando (daiproute2
il nuovo standard suite di strumenti di rete Linux) elsof
come inlsof -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 connettersi a qualche porta TCP.iptables-save
(su Linux) – per scaricare il completo tabelle iptablesethtool
– ottenere tutti i parametri della scheda di interfaccia di rete (stato del collegamento, velocità, parametri di scarico…)socat
– lo strumento dell'esercito svizzero per testare tutti i protocolli di rete (UDP, multicast, SCTP…). Particolarmente utile (più di telnet) con pochi-d
opzioni.iperf
– per testare la disponibilità della larghezza di bandaopenssl
(s_client
,ocsp
,x509
…) per eseguire il debug di tutti i problemi di SSL/TLS/PKI.wireshark
– il potente strumento per l'acquisizione e l'analisi del traffico di rete, che consente di analizzare e intercettare molti bug di rete.iftop
– mostra i grandi utenti sulla rete/router.iptstate
(su Linux) – visualizzazione corrente del monitoraggio della connessione del firewall.arp
(o il nuovo (Linux)ip neigh
) – mostra lo stato della tabella ARP.route
o il più recente (su Linux)ip route
– mostra lo stato della tabella di instradamento.strace
(otruss
,dtrace
otusc
a seconda del sistema) – è uno strumento utile che mostra quali chiamate di sistema eseguono il processo del problema, mostra anche i codici di errore (errno) quando le chiamate di sistema non riescono. Queste informazioni spesso dicono abbastanza per comprendere il comportamento del sistema e risolvere un problema. In alternativa, utilizzare i punti di interruzione su alcune funzioni di rete ingdb
può farti scoprire quando sono realizzati e con quali argomenti.- per indagare sui problemi del firewall su Linux:
iptables -nvL
mostra quanti pacchetti corrispondono a ciascuna regola (iptables -Z
azzerare i contatori). IlLOG
target inserito nelle catene di firewall è utile per vedere quali pacchetti li raggiungono e come sono già stati trasformati quando vi arrivano. Per ottenere ulterioriNFLOG
(associato aulogd
) registrerà il pacchetto completo.