Se ci fosse un'utilità di rete che vorrei fosse stata demistificata per me come ingegnere di supporto, è il tcpdump attrezzo. Non riesco a contare il numero di volte in cui mi sono imbattuto in una situazione in cui dovevo utilizzarlo per la risoluzione dei problemi ma non l'ho capito completamente o quali opzioni dovevo conoscere. Oggi faccio un tuffo nel tcpdump strumento:a cosa serve e cosa devi sapere. Ti guido anche attraverso un modello di una situazione in cui mi sono trovato in precedenza. Diamoci dentro.
Cos'è tcpdump?
Il tcpdump strumento è stato sviluppato alla fine degli anni '80 e da allora è stato un punto fermo per la risoluzione dei problemi di rete. È distribuito con una licenza BSD ed è gratuito da scaricare e utilizzare. Funziona sulla maggior parte dei sistemi operativi *nix e ha una versione trasferita per Windows. Al livello più elementare, tcpdump è uno strumento di acquisizione dei pacchetti utilizzato per risolvere i problemi di connettività di rete. Probabilmente è più vicino a Wireshark. Tuttavia, è molto più leggero ed è solo da riga di comando (nessuna GUI disponibile per quanto ne so).
Installazione
Prima di iniziare a curiosare con il comando, diamo un'occhiata all'installazione. Di solito viene fornito con la maggior parte dei moderni sistemi operativi Linux, quindi probabilmente lo hai già. Puoi verificarlo eseguendo which tcpdump . Se non è installato, non preoccuparti:l'installazione è semplice. Esegui il seguente comando:
$ sudo yum install -y tcpdump Utilizzo di base
Ora che abbiamo lo strumento pronto per l'uso, diamo un'occhiata alle funzioni più basilari. Per iniziare a catturare i pacchetti attraverso un'interfaccia, dobbiamo vedere le interfacce di rete disponibili per l'acquisizione. Per fare ciò, utilizziamo:
$ sudo tcpdump -D Ecco un esempio dalla mia macchina Red Hat Enterprise Linux:
[tcarrigan@server ~]$ sudo tcpdump -D
[sudo] password for tcarrigan:
1.enp0s3 [Up, Running]
2.enp0s8 [Up, Running]
3.lo [Up, Running, Loopback]
4.any (Pseudo-device that captures on all interfaces) [Up, Running]
5.virbr0 [Up]
6.bluetooth-monitor (Bluetooth Linux Monitor) [none]
7.nflog (Linux netfilter log (NFLOG) interface) [none]
8.nfqueue (Linux netfilter queue (NFQUEUE) interface) [none]
9.usbmon0 (All USB buses) [none]
10.usbmon1 (USB bus number 1)
11.virbr0-nic [none] Questo comando è estremamente utile negli ambienti aziendali in cui vengono utilizzate interfacce specifiche per spostare particolari tipi di dati. Esamineremo questa situazione un po' più da vicino nelle parti successive di questo articolo. Ora, catturiamo alcuni pacchetti in modo da poter vedere l'output e quali informazioni stiamo raccogliendo qui.
Per un'acquisizione di base, utilizza quanto segue:
[root@server ~]# tcpdump -i any
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
18:42:10.914742 IP server.example.com.55018 > 216.126.233.109.ntp: NTPv4, Client, length 48
18:42:10.915759 IP server.example.com.59656 > router.charter.net.domain: 1974+ PTR? 109.233.126.216.in-addr.arpa. (46)
18:42:10.959920 IP router.charter.net.domain > server.example.com.59656: 1974 ServFail 0/0/0 (46)
18:42:10.960089 IP server.example.com.42825 > router.charter.net.domain: 1974+ PTR? 109.233.126.216.in-addr.arpa. (46)
*** Shortened output ***
^C
17 packets captured
18 packets received by filter
1 packet dropped by kernel
Qui utilizziamo il -i flag per indicare l'interfaccia, any , in questo caso che vogliamo ascoltare. Nota che tcpdump continua a catturare i pacchetti fino a quando un segnale di interruzione viene dato tramite Ctrl+C . L'altra opzione che puoi usare è -c flag per limitare il numero di pacchetti acquisiti. Questo limite è onestamente uno dei modi migliori per utilizzare il comando secondo me, perché la maggior parte delle volte stai cercando di capire la connettività (che può essere diagnosticata piuttosto rapidamente).
[root@server ~]# tcpdump -i any -c 3
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
18:51:54.509439 IP server.example.com.58249 > 216.126.233.109.ntp: NTPv4, Client, length 48
18:51:54.510413 IP server.example.com.46277 > router.charter.net.domain: 9710+ PTR? 109.233.126.216.in-addr.arpa. (46)
18:51:54.570112 IP 216.126.233.109.ntp > server.example.com.58249: NTPv4, Server, length 48
3 packets captured
10 packets received by filter
1 packet dropped by kernel
Ho un altro suggerimento rapido per la risoluzione dei problemi con tcpdump . Per impostazione predefinita, risolve gli indirizzi IP e i numeri di porta in nomi (vedi sopra). In ambienti di grandi dimensioni in cui gli schemi di denominazione sono un po' complicati, puoi disabilitare questa risoluzione per ottenere indirizzi IP e numeri di porta. Dal punto di vista della risoluzione dei problemi tecnici, lo trovo molto meno confuso. Inoltre, rende un po' più semplice la ricerca nell'output dell'acquisizione. Usiamo il -nn flag per disabilitare il nome e la risoluzione della porta :
[root@server ~]# tcpdump -i any -c3 -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
19:56:12.804327 IP 10.0.3.15.41153 > 64.79.100.196.123: NTPv4, Client, length 48
19:56:12.867789 IP 64.79.100.196.123 > 10.0.3.15.41153: NTPv4, Server, length 48
19:56:13.739885 IP 10.0.3.15.50968 > 216.126.233.109.123: NTPv4, Client, length 48
3 packets captured
3 packets received by filter
0 packets dropped by kernel Altri filtri utili
Per filtrare per indirizzo IP:
$ sudo tcpdump host x.x.x.x Per filtrare per interfaccia:
$ sudo tcpdump eth0 Per filtrare per fonte:
$ sudo tcpdump src x.x.x.x Per filtrare per destinazione:
$ sudo tcpdump dst x.x.x.x Per filtrare per protocollo:
$ sudo tcpdump icmp Ci sono un gran numero di opzioni e filtri per affinare davvero le tue acquisizioni fino al traffico più utile. Se hai bisogno di maggiori informazioni, controlla la pagina man o altre fonti online.
Applicazione pratica
Come ho affermato in precedenza, durante il mio periodo come ingegnere di supporto, ho dedicato molto tempo alla risoluzione dei problemi relativi alla replica dei dati dalla produzione agli ambienti di ripristino di emergenza. Un cliente disporrebbe spesso di un'interfaccia di replica designata configurata per inviare il traffico dal proprio server di produzione a un server di destinazione della replica. Esaminiamo come appare a livello di base e utilizziamo tcpdump per verificare il traffico dalla nostra interfaccia di origine alla destinazione.
Condizioni preliminari
- Server di origine - 172.25.1.5
- Server di destinazione - 172.25.1.4
- Interfaccia di replica - enp0s8
In teoria, quando avviamo un processo di replica dei dati, dovremmo vedere un flusso di traffico da 172.25.1.5 a 172.25.1.4.
Ho avviato una rapida "replica" (ping ) lavoro in background sul server di origine. Successivamente, eseguiamo tcpdump sui server di origine e di destinazione per vedere se stiamo ricevendo il traffico.
Dalla fonte:
[root@server ~]# tcpdump -i enp0s8 -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp0s8, link-type EN10MB (Ethernet), capture size 262144 bytes
23:17:55.347648 ARP, Request who-has 172.25.1.4 tell 172.25.1.5, length 28
23:17:56.378194 ARP, Request who-has 172.25.1.4 tell 172.25.1.5, length 28
23:17:57.398294 ARP, Request who-has 172.25.1.4 tell 172.25.1.5, length 28
23:17:58.422946 ARP, Request who-has 172.25.1.4 tell 172.25.1.5, length 28
23:17:59.448412 ARP, Request who-has 172.25.1.4 tell 172.25.1.5, length 28
^C
5 packets captured
5 packets received by filter
0 packets dropped by kernel Puoi vedere che il traffico di cui sopra è solo una richiesta:non stiamo ricevendo una risposta dal target. In uno scenario reale, ciò indicherebbe un problema sulla destinazione, poiché possiamo vedere chiaramente il traffico inviato tramite l'interfaccia di origine.
Dopo aver riattivato l'interfaccia di destinazione...
Ecco le acquisizioni di traffico dalla fonte e dalla destinazione dopo che il problema è stato identificato e risolto.
Fonte:
[root@server ~]# tcpdump -i enp0s8 -c3 -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp0s8, link-type EN10MB (Ethernet), capture size 262144 bytes
23:22:04.694919 IP 172.25.1.5 > 172.25.1.4: ICMP echo request, id 7168, seq 911, length 64
23:22:04.695346 IP 172.25.1.4 > 172.25.1.5: ICMP echo reply, id 7168, seq 911, length 64
23:22:05.724968 IP 172.25.1.5 > 172.25.1.4: ICMP echo request, id 7168, seq 912, length 64
3 packets captured
3 packets received by filter
0 packets dropped by kernel Destinazione:
[root@client ~]# tcpdump -i enp0s8 -c3 -nn
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp0s8, link-type EN10MB (Ethernet), capture size 262144 bytes
23:22:13.916519 IP 172.25.1.5 > 172.25.1.4: ICMP echo request, id 7168, seq 920, length 64
23:22:13.916569 IP 172.25.1.4 > 172.25.1.5: ICMP echo reply, id 7168, seq 920, length 64
23:22:14.935720 IP 172.25.1.5 > 172.25.1.4: ICMP echo request, id 7168, seq 921, length 64
3 packets captured
4 packets received by filter
0 packets dropped by kernel Uno sguardo più attento all'output mostra che il traffico viene inviato correttamente dal server di origine al server di destinazione.
Riepilogo
Abbiamo imparato cosa e perché di tcpdump oggi, così come le opzioni da sapere. Abbiamo anche dato un'occhiata a un caso d'uso nel mondo reale. Ovviamente, ci sono altre considerazioni in un ambiente dal vivo. Tutto, dalle interfacce inattive (come in questo esempio) alle password errate via cavo, può causare errori. Solo l'esperienza ti insegna queste lezioni, ma almeno ora sai come iniziare a identificare un problema. Il mio prossimo articolo esplora un po' più a fondo le opzioni dei filtri, come inviare le tue acquisizioni in un file e usare grep per trovare l'ago nel tuo pagliaio. Assicurati di tenerlo d'occhio.
Per informazioni più dettagliate sull'utilizzo di tcpdump, consulta questa introduzione all'uso di tcpdump dalla riga di comando di Linux su Opensource.com e consulta la documentazione ufficiale nel Red Hat Customer Portal per una migliore comprensione di tcpdump all'interno di un Red Hat Enterprise Linux ambiente.
[ Rete fuori controllo? Dai un'occhiata all'automazione della rete per tutti, un libro gratuito di Red Hat. ]