Pokud by existovala jedna síťová utilita, o které bych si přál, aby byla pro mě jako podpůrného inženýra demystifikována, je to tcpdump nářadí. Nemohu spočítat, kolikrát jsem se dostal do situace, kdy jsem jej potřeboval použít k odstraňování problémů, ale plně jsem tomu nerozuměl nebo jaké možnosti jsem potřeboval vědět. Dnes se hluboce ponořím do tcpdump nástroj – k čemu se používá a co potřebujete vědět. Také vás provedu maketou situace, ve které jsem se dříve ocitl. Pojďme do toho.
Co je tcpdump?
tcpdump Tento nástroj byl vyvinut koncem 80. let 20. století a od té doby je základním prvkem řešení problémů se sítí. Je distribuován pod licencí BSD a je zdarma ke stažení a použití. Funguje na většině operačních systémů *nix a má portovanou verzi pro Windows. Na nejzákladnější úrovni tcpdump je nástroj pro zachytávání paketů používaný k řešení problémů s připojením k síti. Asi nejvíce se to přirovnává k Wiresharku. Je však mnohem lehčí a je pouze z příkazového řádku (podle mých znalostí není k dispozici žádné GUI).
Instalace
Než se začneme hrabat v příkazu, podívejme se na jeho instalaci. Obvykle se dodává s většinou moderních operačních systémů Linux, takže jej pravděpodobně již máte. Můžete to ověřit spuštěním which tcpdump . Pokud není nainstalován, nemějte obavy – instalace je jednoduchá. Spusťte následující příkaz:
$ sudo yum install -y tcpdump Základní použití
Nyní, když máme nástroj připravený k použití, pojďme se podívat na nejzákladnější funkce. Abychom mohli začít zachycovat pakety přes rozhraní, musíme vidět síťová rozhraní dostupná pro zachycení. K tomu používáme:
$ sudo tcpdump -D Zde je ukázka z mého počítače 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] Tento příkaz je mimořádně užitečný v podnikových prostředích, kde se k přesunu určitých typů dat používají specifická rozhraní. Na tuto situaci se podíváme trochu blíže v pozdějších částech tohoto článku. Nyní zachytíme nějaké pakety, abychom viděli výstup a jaké informace zde shromažďujeme.
Pro základní zachycení použijte následující:
[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
Zde používáme -i příznak pro označení rozhraní, any , v tomto případě, kterému chceme naslouchat. Všimněte si, že tcpdump pokračuje v zachycování paketů až do signálu přerušení se zadává pomocí Ctrl+C . Další možností, kterou můžete použít, je -c příznak pro omezení počtu zachycených paketů. Tento limit je podle mého názoru upřímně jedním z nejlepších způsobů použití příkazu, protože většinu času se snažíte zjistit konektivitu (kterou lze diagnostikovat poměrně rychle).
[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
Mám další rychlý tip pro odstraňování problémů s tcpdump . Ve výchozím nastavení překládá IP adresy a čísla portů na názvy (viz výše). Ve velkých prostředích, kde jsou schémata pojmenování trochu komplikovaná, můžete toto rozlišení zakázat, abyste získali IP adresy a čísla portů. Z hlediska technického řešení problémů to považuji za mnohem méně matoucí. Také to trochu usnadňuje vyhledávání ve výstupu vašeho zachycení. Používáme -nn příznakem zakážete rozlišení názvů a portů :
[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 Další užitečné filtry
Filtrování podle IP adresy:
$ sudo tcpdump host x.x.x.x Chcete-li filtrovat podle rozhraní:
$ sudo tcpdump eth0 Chcete-li filtrovat podle zdroje:
$ sudo tcpdump src x.x.x.x Chcete-li filtrovat podle cíle:
$ sudo tcpdump dst x.x.x.x Chcete-li filtrovat podle protokolu:
$ sudo tcpdump icmp Existuje velké množství možností a filtrů, které skutečně zdokonalí vaše záběry pouze na nejužitečnější provoz. Pokud potřebujete více informací, podívejte se na manuálovou stránku nebo jiné online zdroje.
Praktická aplikace
Jak jsem uvedl dříve, během doby, kdy jsem pracoval jako technik podpory, jsem strávil značné množství času při odstraňování problémů s replikací dat od produkčního až po prostředí zotavení po havárii. Zákazník má často nastavené replikační rozhraní pro odesílání provozu ze svého produkčního serveru na cílový server replikace. Pojďme si projít, jak to vypadá na základní úrovni, a použijeme tcpdump k ověření provozu z našeho zdrojového rozhraní do cíle.
Předběžné podmínky
- Zdrojový server – 172.25.1.5
- Cílový server – 172.25.1.4
- Rozhraní replikace – enp0s8
Teoreticky, když spustíme úlohu replikace dat, měli bychom vidět tok provozu od 172.25.1.5 do 172.25.1.4.
Spustil jsem rychlou „replikaci“ (ping ) úloha na pozadí na zdrojovém serveru. Dále spustíme tcpdump na zdrojovém a cílovém serveru, abychom zjistili, zda přijímáme provoz.
Ze zdroje:
[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 Můžete vidět, že výše uvedený provoz je pouze žádostí – od cíle nedostáváme odpověď. V reálném scénáři by to znamenalo problém v cíli, protože můžeme jasně vidět provoz odesílaný přes zdrojové rozhraní.
Poté, co jsem znovu zapnul cílové rozhraní...
Zde jsou zachyceny návštěvnosti ze zdroje a cíle poté, co byl problém identifikován a vyřešen.
Zdroj:
[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 Cíl:
[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 Bližší pohled na výstup ukazuje, že provoz je odeslán ze zdrojového serveru na cílový server úspěšně.
Shrnutí
Dozvěděli jsme se, co a proč tcpdump dnes, stejně jako možnosti vědět. Dokonce jsme se podívali na případ použití v reálném světě. Je zřejmé, že v živém prostředí existují jiná hlediska. Selhání může způsobit vše od výpadku rozhraní (jako v tomto příkladu) až po špatná hesla po drátě. Tyto lekce vás naučí pouze zkušenost, ale nyní alespoň víte, jak začít s identifikací problému. Můj další článek prozkoumává možnosti filtrování o něco dále, jak vytisknout zachycené snímky do souboru a použít grep najít jehlu v kupce sena. Dejte si na to pozor.
Podrobnější informace o používání tcpdump najdete v tomto úvodu k používání tcpdump na příkazovém řádku Linuxu na Opensource.com a podívejte se na oficiální dokumentaci na zákaznickém portálu Red Hat, kde najdete lepší pochopení tcpdump v systému Red Hat Enterprise Linux. prostředí.
[ Síť se vymkla kontrole? Podívejte se na Automatizaci sítě pro každého, bezplatnou knihu od Red Hat. ]