Wireshark jest jednym z najlepszych narzędzi do dyspozycji admina, nie jest tylko “graficznym tcpdumpem” jak niektórzy sądzą. Zamierzam opisać parę przydatnych zastosowań tego narzędzia w debugowaniu (nie)typowych problemów

Nie będzie to tutorial typu “jak kliknąć button ‘start capture'” albo “jak zrobić apt-get install” (w sumie jeżeli komuś potrzebne coś takiego powinien się poważnie zastanowić nad zmianą zawodu na np. zbieracz truskawek) tylko raczej “jak zdalnie nagrać rozmowy SIP” albo “jak zanalizować latencję łącza”.

Podstawy: Filtrowanie danych

Debugowanie czegokolwiek jest łatwiejsze gdy poziom “szumu” (części analizowanych danych która nas nie interesuje bo wiemy że jest dobra lub tyczy się innego fragmentu systemu) jest jak najniższy, dlatego zwykle robienie dumpu przez tcpdump -i any -s 0 -w dump na ruchliwym serwerze podczas gdy nas obchodzi parę requestów HTTP dobrym pomysłem nie jest ;]. Więcej info nt. filtrów tcpdumpa w manie ale podstawy:

  • not port 22
  • port 80 or port 8080 – np. gdy mamy proxy/lb które słucha na 80 i wysyła req. do backendu na
  • host 1.2.3.4

warto znać. Ofc. lepiej przechwycić za dużo niż za mało ;]

Podobne filtrowanie można zastosować potem w wiresharku, ale składnia jest inna. Oraz trzeba uważać na parę rzeczy np. ip.addr != 192.168.1.1 zadziała trochę inaczej niż podpowiada common sense. Naprawdę warto poznać te filtry (po kliknięciu w expression pokazuje się ładna lista po czym z każdego protokołu można filtrować) bo wtedy zamiast żmudnie przeglądać pakiety wystarczy wpisać np.

http.request.uri contains "admin" and http.request.method == POST and http.host == devrandom.pl

i od razu mamy to co potrzebujemy;]

Żeby nie było nudno (za dużo teorii jest nużące ;]) zróbmy mały eksperyment. Najpierw dump. Można odpalić lokalnie ale jeżeli masz własny serwer (ja zainstalowałem tcpdumpa na routerku z Tomato ;) ) pokażę jak robić zdalny live capture używając wireshark + ssh + tcpdump ;].

ssh root@192.168.1.1 /jffs/tcpdump -i vlan0 -s 0 -U -n -w - not port |tee /tmp/dump | wireshark -k -i -

czyli “ssh gdzieśtam, odpal tcpdump (ścieżka niekonieczna gdy to “normalny” serwer), ignoruj ruch na porcie 22 (WAŻNE inaczej będziemy nagrywać “sami siebie”), kopiuj dump do /tmp/dump, nakarm stdin wiresharka”

A teraz coś do popatrzenia, odpalamy np.mplayer http://listen.di.fm/public3/liquiddnb.pls i podsłuchujemy ;]. Rezultat(u mnie w tle leciał jeszcze streaming z last.fm):

Możemy zatrzymać już capture. Co tu widać ? Chcę znaleźć strumień mp3 więc użyłem Statistics -> Conversations i posortowałem po ilości bajtów. Jeżeli jesteśmy na zakładce TCP to wystarczy kliknąć na Follow Stream i mamy ładny widok tego co latało między sieciówkami. Teraz na dole wybieramy kierunek konwersacji na “od serwera do klienta”, “zapisz jako” i mamy mp3jkę z tym co leciało w radiu netowym (troche się będzie ciąć bo takie raw data to nie do końca jest 100% kompatyblina mp3jka) ;].

Klikając na dowolny pakiet prawym i wywołując “Follow xyz stream” wireshark nam łądnie wyfiltruje wszystkie pakiety należące do danego  “strumienia” czyli w przypadku HTTP jeden request, w przypadku DNS jedno query itd. Jest tam pare innych ciekawych opcji ale o tym w kolejnej części ;].

Wykorzystajmy ten trick do zobaczenia co było słuchane w last.fm:

Na screenshocie

  • zapytania które zawierają “Host: .*last.fm.*
  • RTT i transfer dla jednego ze strumieni z lastfm
  • shoutcast (blue) i kolejne 3 utwory na last.fm

I teraz podstawowe pytanie “no i co z tego wynika?” :].  Patrząc na wykres z prawej strony można odczytać bitrate streamingu jak i to że player shoutcasta ma większy bufor sieciowy niż player last.fm (i mniejszy bitrate), widać to po dużym piku na początku transferu. Patrząc na RTT można wywnioskować że łącze między serwerem jest nieobciążone bo RTT jest zarówno małe jak i bez wielkich fluktuacji.

Analiza pojedyńczych pakietów

Jak na razie nie tknęliśmy nawet najbardziej “niskopoziomowej” części analizy czyli panelu ze szczegółowymi informacjami o klikniętym pakiecie. Przyjrzyjmy się takiemu np. pakietowi DNS:

Po lewej (zależy od ustawień, można zmieniać kolejność i layout paneli w miarę dowolnie) mamy pakiet rozłożony na warstwy, od ethernetu aż po rozkodowany DNS, po prawej hexdump, po kliknięciu w pole po lewej po prawej zaznacza nam się miejsce w pakiecie w którym jest dana wartośc zapisana.

Na koniec (dokładnie o right click menu w następnej części) kliknij w jakieś połączenie TCP, kliknij którąś z opcji TCP prawym, potem
Protocol Preferences -> Analyze TCP Sequence numbers na on
poczekaj aż się odświeży, do listy pól TCP powinna się dodać [SEQ/ACK analysis]

Teraz kliknij prawym na Number of bytes in flight i daj “Apply as column”. Voila, mamy nową kolumnę z parametrem który nas zainteresował (no, może jest parę innych bardziej przydatnych niż akurat ten ;) ). W części kolejnej jeszcze więcej filtrowania, opis wspaniałego right click menu ;) i parę tricków ułatwiających pracę, a będzie to kiedyś (prawdopodobnie za tydzień-dwa) Część 2

Related Posts: