Netwerkproblemen oplossen met Wireshark: Deel 2

Traag internet, geen verbinding, er kunnen talloze oorzaken zijn voor dit soort netwerkproblemen. Wireshark is een veelzijdige tool voor het opsporen van dit soort zaken. In dit artikelen nemen we wat praktijkvoorbeelden met je door.

Lees eerst: Netwerkproblemen oplossen met Wireshark: Deel 1

Prestaties meten

Stel, je merkt dat bepaald netwerkverkeer opvallend traag verloopt. In dit geval zou je een sessie kunnen starten waarbij je bijvoorbeeld een aanzienlijk bestand van een website downloadt. Vervolgens open je het menu Statistics en selecteer je Capture File Properties. Bij Statistics, Average (M)bits/s lees je de doorvoersnelheid af.

Of je klikt met de rechtermuisknop op een geschikt datapakket en je kiest Conversation filter / TCP (om het tcp-verkeer tussen twee machines te isoleren), waarna je per protocol of applicatie de doorvoersnelheid afleest via het menu Statistics / Protocol Hierarchy.

Een niet onbelangrijk aspect van de netwerkprestatie is tevens de ‘latency’: de vertraging tussen de aanvraag en de ontvangst van de eerste pakketten. Ook in dit geval kan Wireshark van pas komen. Maak een extra kolom die de ‘deltatijden’ weergeeft: ga naar Edit, kies Preferences, open de rubriek Appearance en klik op Columns.

Voeg een kolom toe met het plus-knopje, dubbelklik op (Number) en kies Delta time in het uitklapmenu. De gevaagde kolom verschijnt en je ziet meteen waar eventuele bottlenecks zich voordoen. Vanuit het contextmenu kun je zo’n kolom overigens altijd verwijderen met de optie Remove This Column.

Wireshark

© PXimport

DNS-problemen aanpakken

Ander probleem: op een bepaald moment bleek bij een gebruiker geen enkele site nog bereikbaar en ook e-mailen lukte niet meer. Vermoedelijk ging het om een dns-probleem aangezien we bijvoorbeeld wel nog konden pingen naar een adres als 8.8.8.8 (de Google dns-server), maar niet naar een webadres als www.pcmweb.nl. Een snelle controle van de extern gehoste dns-servers zoals die in de router waren opgegeven, leerde ons dat die dns-servers nog prima functioneerden.

We startten een Wireshark-sessie, terwijl we (zonder resultaat) naar een site probeerden te surfen. Vervolgens openden we Analyze / Expert Information: vaak vind je hier nuttige informatie terug over de oorzaak van problematische netwerkverbindingen, maar dat leverde in ons geval niets op. Een weergavefilter met dns leverde vreemd genoeg een leeg scherm op, maar opvallend was wel het aantal broadcast-arp-requests.

Wanneer je zo’n arp-request aanklikt, krijg je automatisch extra informatie te zien in het venster met pakketdetails. Hieruit bleek dat de Wireshark-machine vruchteloos op zoek was naar adres 192.168.0.253. Opvallend waren ook de arp-requests van de router die zijn eigen ip- en mac-adres kenbaar maakte (192.168.0.254).

De uiteindelijke conclusie: blijkbaar was ergens het adres 192.168.0.253 als dns-server ingevuld in plaats van het router-adres. Een snelle controle van het eigenschappenvenster van de netwerkadapter bevestigde ons vermoeden en na de adreswijziging was het probleem opgelost.

Wireshark

© PXimport

Verdacht verkeer opsporen

Ook als je de indruk hebt dat er verdacht (veel) netwerkverkeer wordt gegenereerd, kan Wireshark je helpen. Een prima vertrekpunt is het weer het menu Statistics / Protocol Hierarchy. Immers, hier zie je per protocol en applicatie hoeveel verkeer er is voorbijgekomen.

Heeft Wireshark geen geschikte ‘dissector’ gevonden (lees: de tool kan niet vaststellen om welke applicatie of protocol het gaat), dan worden die data in de rubriek Data ondergebracht. Erg handig is dat je maar met de rechtermuisknop hoeft te klikken op een item in dit venster, waarna je het via Apply as Filter / Selected meteen als een weergavefilter instelt.

Vervolgens klik je met de rechtermuisknop op een pakket en kies je Follow / TCP Stream. Of je selecteert een pakket en zoomt vanuit het venster met pakketdetails in op de verdachte communicatie. Dat geldt trouwens ook voor de rubriek Data: wellicht geeft het onderste venster (pakketbytes) dan iets prijs over de uitgewisselde gegevens.

Het kan natuurlijk gebeuren dat bepaald netwerkverkeer (blijkbaar) niet via de standaardpoort verloopt. Zulk verkeer verdient automatisch je scherpe aandacht, want het zou wel eens om verdachte pakketten kunnen gaan, bijvoorbeeld met de bedoeling een firewall te omzeilen. Het kan in dat geval wel handig zijn om het poortnummer handmatig aan een specifiek protocol toe te kennen. Dat kan via Edit / Preferences / Protocol. Wil je bijvoorbeeld een poort toevoegen of wijzigen aan het http-protocol, selecteer dan HTTP en voer de nodige aanpassingen uit. Bevestig met OK.

Wireshark

© PXimport

Naamresolutie en locatie

Wellicht vind je het bij verdachte communicatie ook interessant om te weten welke hosts precies achter de ip-adressen schuilgaan. In dat geval kun je bij Edit / Preferences / Name Resolution een vinkje plaatsen naast Resolve network (IP) addresses. Het menu Statistics / Resolved Addresses bezorgt je dan een mooi overzicht van de vastgestelde hostnamen.

Wireshark kan ook de MaxMind GeoLite-databases gebruiken om ipv4- en ipv6-adressen aan een geografische locatie te koppelen. Ga naar deze site, download de binaire databases GeoLite Country (IPv6) en GeoLite City (IPv6), pak de archieven uit en plaats beide dat-bestanden in dezelfde map.

Open Wireshark en ga naar Edit / Preferences / Name Resolution. Klik op de onderste knop Edit (naast GeoIP database directories) en verwijs via het plusknopje naar de betreffende map. Bevestig je keuze en herstart Wireshark. Test het uit door naar Statistics / Endpoints te gaan en het tabblad IPv4 (of IPv6) te openen: als het goed is tref je hier land, stad evenals de coördinaten van de hosts. Via de knop Map krijg je die bovendien netjes uitgetekend op een wereldkaart.

Wireshark

© PXimport

Werken met tcp

Zoals je weet verzorgt het tcp-protocol (transmission control protocol) het transport tussen twee hosts. In tegenstelling tot het verbindingsloze udp (waar het wegvallen van bits doorgaans niet zo erg is, denk aan mediastreaming) tracht tcp de data op een zo betrouwbaar mogelijke manier te versturen. Tcp heeft daarom enkele controlemechanismes ingebouwd, waaronder de driedelige handshake: SYN / SYN,ACK / ACK. Deze wetenschap kan je helpen bij het bepalen van problemen.

Probeer als experiment maar een ftp-sessie op te zetten, bijvoorbeeld met behulp van FileZilla, met een server die poort 21 gesloten houdt. Je zult merken dat meteen na het uitsturen van het SYN-pakket door de client een RST, ACK-pakket van de server volgt: een reset dus die de verbinding abrupt verbreekt. Overigens vind je deze informatie ook terug via Analyze / Export Information, bij Warning, Connection reset (RST). Dat maakt je al duidelijk dat de service niet bereikbaar is, wellicht wegens een foutief adres of een gesloten poort.

Het valt echter niet uit te sluiten dat de data-uitwisseling onderweg plotseling stokt. In dat geval zul je wellicht een reeks TCP ZeroWindow-pakketjes voorbij zien komen. Wanneer je de tcp-header van zo’n pakket in detail bekijkt, dan zul je een Window size met waarde 0 zien. Deze venstergrootte geeft aan hoeveel data de machine tijdens een tcp-sessie kan ontvangen; een soort buffer dus. Krijg je tijdens de datatransfer geregeld met zulke pakketten te maken, dan is er blijkbaar een probleem aan clientzijde. Wellicht zijn er hier teveel processen actief en (daardoor) te weinig systeembronnen beschikbaar.

Wireshark

© PXimport

Deel dit artikel
Voeg toe aan favorieten