Netwerkproblemen troubleshooten via ICMP-meldingen

Je bent beheerder en je netwerk vertoont kuren. Waar begin je met het zoeken naar de oorzaken? Onze tip: doorzoek je netwerk eens op ICMP-symptomen. Vele daarvan leiden direct naar de oorzaak. Misschien kun je de netwerkproblemen troubleshooten via ICMP-meldingen.

Als je een netwerkinfarct moet behandelen, is Wireshark een van de favoriete tools van netwerkbeheerders. Want verkeerd aange­sloten of foutief geconfigureerde servers kom je vaak op het spoor door het netwerk­verkeer te onderscheppen, wat je als beheerder het inloggen uitspaart op af­­delingsrouters of -switches. Als verantwoordelijke beheerder moet je de onderschepte pakketbrij alleen nog met een geschikt displayfilter zeven, om precies dat soort pakketten over te houden die aanwijzingen voor fouten makkelijk uitlichten, de ICMP-pakketten.

Hoe je dat doet, beschrijven we in het gedeelte ‘Verzamelpunten’, waar een klein Wireshark-kwisje op aansluit. Als je bekend bent met Wireshark en ICMP-foutmeldingen, zul je de kwis waarschijnlijk met twee vingers in je neus oplossen. Zo niet, dan kun je hier ontdekken wat er achter de foutmeldingen zit en hoe je die kennis kunt toepassen.

ICMP is een van de netwerkprotocollen in het OSI-layermodel; het is gebaseerd op layer 3, het Internet Protocol (IP). Met andere woorden, een ICMP-pakket bestaat van voor naar achter uit een ip-header, de ICMP-header en een gegevensgedeelte. Via ICMP-pakketten rapporteren ip-netwerkapparaten die deel uitmaken van een dialoog hun huidige status aan elkaar of verzenden ze controle-informatie, vandaar de naam Internet Control Message Protocol (ICMP). De IPv6-specificatie is te vinden in RFC 4443 en de specificatie voor IPv4 in RFC 792.

Voor analysedoeleinden kun je ICMP-pakketten versturen met tools als ping. Met de pakkettypes Echo Request en Echo Reply kun je bijvoorbeeld de netwerk­afstand (round trip time, RTT) van internet-hosts zoals routers, switches of pc’s bepalen. Dit is hebben we deels al eerder beschreven.

Minder bekend zijn de ICMP-pakketten van het type ‘destination unreachable’. In veel gevallen vergemakkelijken deze pakketten het oplossen van problemen, omdat doelapparaten zoals routers, switches of pc’s bij een fout de afzender moeten informeren over de status van de netwerkfout, zodat beheerders kunnen ingrijpen.

Fouten kunnen verschillende oorzaken hebben en een router, bijvoorbeeld, onthult waar de fout zit met een statuscode in zijn ICMP-bericht. Sommige klassieke netwerkfouten kun je direct aflezen uit de ‘destination unreachable’-berichten – als de beheerder die maar in handen kan krijgen. En dat is eenvoudiger dan je denkt. Je hebt geen klassieke en meestal tijdrovende troubleshooting nodig. Je hebt genoeg aan een tool voor het onderscheppen van het dataverkeer, zoals Wireshark of bijvoorbeeld de commandline-tool TCPDump.

Als je die data hebt, kun je je gebruikers informeren dat je met de probleem­oplossing bent begonnen. Dat brengt weer rust op de werkvloer en voorkomt zinloze verbindingspogingen die het netwerk on­­nodig belasten.

Hierna volgen de vier meest voor­komende fouten en hun oorzaken, uitgesplitst naar client- en serverzijde. Een fout aan de clientzijde treedt bijvoorbeeld op wanneer deze een TCP-verbinding tot stand wil brengen – hiervoor stuurt hij een SYN-pakket naar de bestemming – maar de totstandkoming mislukt en er komt een foutmelding retour. Een serverfout treedt op wanneer de server een antwoord op een clientverzoek verstuurt, maar dit niet aankomt.

Voor de volledigheid moet worden vermeld dat er nog een aantal andere foutcodes zijn, maar deze komen zelden voor. Een lijst van alle foutmeldingen inclusief links naar de respectievelijke RFC-specificaties wordt bijgehouden door de IANA.

Een router op het traject naar het doel verwerpt een ip-pakket omdat in zijn routeringstabel de entry voor het doelnetwerk ontbreekt. Hij kan het pakket daarom niet doorsturen en meldt ‘no route to destination’ aan de afzender, bijvoorbeeld een pc. Dit kan alleen gebeuren met internetrouters die in plaats van de default route de default free zone hebben.

Maar waarom zou een apparaat eigenlijk een ip-pakket naar een onbereikbaar adres sturen? Een eenvoudige verklaring is, dat de gebruiker van de client het ip-adres verkeerd ingetypt heeft en dus een gebied opgeeft dat op internet niet bestaat. Of de gebruiker wilde toegang tot een hostnaam waarbij de beheerder van het DNS een typefout heeft gemaakt waardoor het A- of AAAA-record op de authoritative DNS-­server een onjuist ip-adres bevat.

Het komt minder vaak voor dat het adres van het doelnetwerk wel geldig is, maar dat het doel tijdelijk niet beschikbaar is. Dit kan worden veroorzaakt doordat het ip-doelnetwerk of de router ervan technische problemen heeft waardoor BGP-routingupdates niet beschikbaar zijn op het internet. In zulke gevallen wordt het doelnetwerk simpelweg uit de globale routeringstabellen verwijderd. Een router die een pakket voor zo’n bestemming ontvangt, heeft geen andere keuze dan het te verwerpen en de afzender van het pakket via een ICMP-bericht te informeren dat zijn doorstuurpoging mislukt is.

Een speciaal geval doet zich voor bij antwoordpakketten die door servers naar de client worden gestuurd. Staat er in de ip-pakketten van de client een onjuist bronadres (opzettelijk of onopzettelijk), dan wordt dit beschouwd als een netwerk­aanval van het type ‘source address spoofing’. Het verzoek aan de server bereikt die wel, maar het antwoord gaat verloren in het netwerk. Een aanvaller kan dan nog steeds zijn doel hebben bereikt, het belasten van de server, bijvoorbeeld als onderdeel van een DDoS-aanval (Distributed Denial of Service).

In het Engels wat langdradig geformuleerd gaat het bij de melding ‘communication with destination administratively prohibited’ om een klassieke firewallblokkade. Als een client toegang probeert te krijgen tot een bron die door de firewallbeheerder is geblokkeerd, dan verwerpt de firewall het pakket en geeft eventueel dit als antwoord.

Eventueel, want een moderne firewall laat je standaard niet weten dat hij zojuist een pakket heeft geweigerd. Als hij namelijk in gebruik is als perimeterfirewall, zou hij zich zo onopvallend en transparant mogelijk moeten gedragen. Alleen als interne segmentatiefirewall moet hij interne gebruikers informeren over blokkades. Zou de firewall het pakket stilletjes verwerpen, dan zouden gebruikers anders op de timeout moeten wachten, soms ettelijke tergende seconden lang. Maar een hacker wil je met de foutmelding niet wijzer maken, namelijk dat zijn pakket ergens op is gestuit en het de moeite waard zou kunnen zijn om verder te neuzen.

Het is ook nuttig om te weten dat alleen UDP-pakketten deze foutcode kunnen triggeren. Wanneer op TCP gebaseerde diensten worden geblokkeerd, stuurt een firewall namelijk een TCP-resetpakket naar de afzender. Aangezien UDP als verbindingsloos protocol geen bevestigingen zoals ACK of RST stuurt, biedt ICMP uitkomst.

Aan de serverzijde zou deze fout vrijwel nooit moeten opduiken. Staan er een of meer firewalls tussen de client en de server, dan hebben deze meestal de verbinding al geautoriseerd. Op dezelfde manier laten alle firewalls van de laatste decennia antwoordpakketten door – ze werken ‘state­ful’ en houden actieve ip-sessies bij in een tabel.

Een paar uitzonderingen die al lang in het museum thuishoren bevestigen echter de regel. Want af en toe zijn er op oude routers nog access control lists (ACL’s) die niet sessiegebaseerd werken (stateful), maar puur gericht zijn op bron- en bestemmingsadressen zonder rekening te houden met de status van een sessie.

Het kan dan gebeuren dat een antwoordpakket van de server door een ACL wordt geblokkeerd kort voordat het de client bereikt en vervolgens het versturen van deze foutcode naar de server triggert.

In dit scenario is het ip-pakket bijna aan het einde van zijn traject – het bevindt zich in de laatste router voor de bestemming en moet alleen nog worden afgeleverd via het lokale (wifi-)netwerk. Hiervoor bepaalt de laatste router het ethernetadres van de doelhost via het neighbour solicitation (IPv6) of address resolution protocol (IPv4). Als dit mislukt, wordt het een ‘address unreachable’.
Wellicht is de link down, d.w.z. de LAN-kabel kan beschadigd zijn, of het wifi kan haperen. Of het adres bestaat niet, wat weer zou duiden op een typefout van de gebruiker of de DNS-beheerder, vergelijkbaar met geval 1.

In beide gevallen kan de router niets doen met het ip-pakket en moet het verwerpen – gelukkig niet zonder de bron te informeren. Wanneer een server deze fout krijgt, zitten er dezelfde oorzaken achter, ofwel de client bevindt zich niet meer in het netwerk of heeft geen correct bron-ip-adres doorgegeven. Een onjuist adres is vergelijkbaar met geval 1, met het verschil dat in dit geval de host-ID van het ip-adres onjuist is en niet de netwerk-ID.

Deze foutsituatie komt in grote net­werken, die uit meerdere segmenten bestaan die door switches met elkaar zijn verbonden, in twee varianten voor. Clients kunnen dan op de verkeerde switchpoort zijn aangesloten of in het verkeerde VLAN zitten. Ze melden dan wel een correct bron-ip-adres, maar het MAC-adres is dan toch niet te vinden.

De router noteert de mislukte match in zijn ARP-cache met de statusmelding ‘incomplete’. Maar dit is zelden de eerste plaats om te zoeken bij het trouble­shooten, vooral omdat de beheerder niet altijd toegang heeft tot elke router in een bedrijf. Dit is nog een reden waarom het raadzaam is om ICMP-foutmeldingen te onder­scheppen en te analyseren.

Het ip-pakket heeft zijn doelhost (layer 3) bereikt, yay! Het is alleen jammer als de serverbeheerder de service niet correct heeft geconfigureerd of als de service is gecrasht. Dan luistert er niemand naar de doelpoort op layer 4. Het ip-pakket kan bijvoorbeeld bedoeld zijn voor een DNS-server die op poort 53 DNS-queries moet ontvangen. Maar als er op de server geen service is toegewezen aan doelpoort 53 vanwege een fout in de configuratie, dan moet het besturingssysteem het pakket verwerpen.

Ook in dit geval kan er een ICMP-fout retour komen. Hiermee kan de netwerk­beheerder geruchten op de werkvloer weerleggen. Want als ‘het netwerk’ als oorzaak voor het probleem wordt genoemd, dan bewijst deze foutmelding dat zowel de server als de poort zijn bereikt, waar het verantwoordelijkheidsgebied van de netwerkbeheerder ophoudt. Misschien heeft de client door een typefout bij de hand­matige invoer een verkeerd ip-adres opgegeven? Of is de service tijdelijk uitgevallen door een crash? Het probleem zit niet altijd in het netwerk.

Als je bij routineanalyses veel meldingen van ‘port unreachable’ tegenkomt, kan het om een poortscan gaan in de zin van een hackaanval, maar dat hoeft niet. Mogelijk is een interne securitytester bezig met een poortscan; of een inventarisatie­systeem is vrolijk het netwerk aan het scannen. Als een server op tientallen TCP- en UDP-poorten gescand wordt, reageert hij met veel TCP-RST- of ICMP-(‘port un­­reachable’) meldingen.

Servers ontvangen deze errors zelf bij defecte client-implementaties. Een bijzonder drastisch voorbeeld deed zich onlangs voor op Internet of Things-gebied. De NTP-client (Network Time Protocol) van een IoT-apparaat stuurde massaal verzoeken voor de actuele tijd naar een NTP-server met de UDP-doelpoort 123 en een dynamisch geselecteerde bronpoort. De server antwoordde plichtsgetrouw daarop met een kort pakket en het correcte gebruik van de doelpoort 51680, die de client had gebruikt, en zijn NTP-bronpoort 123. Maar geen van de antwoordpakketten bereikte de NTP-client, omdat deze poort 51680 steeds afsloot voordat het NTP-antwoord arriveerde. Het besturingssysteem van de client moest daarom alle NTP-antwoorden verwerpen en aan de server melden via ICMP dat er geen service was om diens pakketten aan af te leveren.

Uiteindelijk was alle communicatie tevergeefs; de client ontving geen tijdinformatie, de server kon alleen zijn ICMP-schouders ophalen en de netwerkprovider moest een hoop nutteloze pakketten verzenden.

Hoe kom je nu aan ICMP-foutmeldingen? De basis is altijd het onderscheppen van pakketten die geanalyseerd kunnen worden met tools zoals Wireshark. Dit kan een live opname zijn of een door een ander apparaat opgenomen PCAP-bestand. Een pc bijvoorbeeld kan dit doen met tcpdump, of een router of firewall doet het met een ingebouwde packet capture.

Standaard markeert Wireshark ICMP-­fouten met lichtgroene tekst op een zwarte achtergrond. Als je op zo’n pakket klikt, krijg je de benodigde details te zien, zoals een van de hierboven beschreven fouten en het oorspronkelijke ip-pakket dat de fout veroorzaakte.
Met deze gegevens kun je precies achterhalen waar het pakket vandaan kwam en kun je het dus toewijzen aan een netwerk, een apparaat, een gebruiker of zelfs een sessie. Een bijzonder handige functie van Wireshark is dat displayfilters met betrekking tot datapakketten van gebruikers ook de bijbehorende ICMP-foutpakketten laten zien, want deze bevatten het originele pakket en zijn zo makkelijk te identifi­ceren. Om in een capture alle fouten weer te geven, voer je als display filter in:

of:

Als je wilt oefenen maar geen capture bij de hand hebt, kun je de ‘Ultimate PCAP’ gebruiken (download het bestand hier).

Tip: als je geïnteresseerd bent in statistieken voor grote captures, laat Wireshark dan voorlopig links liggen (spoiler: zelfs de beste computer bereikt zijn grenzen met bestanden die aanzienlijk groter zijn dan 1 GB). Gebruik in plaats daarvan de command-line tool van Wireshark, tshark. Om bijvoorbeeld een lijst te genereren met alle IPv6 foutcodes en hoe vaak ze voorkomen, voer je het volgende commando in:

Meer informatie over het gebruik van tshark vind je ook op de tshark manual page.

In tegenstelling tot wat je misschien zou denken, liggen er bij het onderscheppen van netwerkverkeer een paar valkuilen op de loer. Als routers of pc’s op vol vermogen werken, kunnen er soms pakketten verloren gaan.

Ook de positie in het netwerk kan van belang zijn voor het vinden van een fout. We hebben eerdere gedetailleerd be­­schreven hoe je optimale captures maakt en met welke apparaten.

In dit geval een kleine waarschuwing vooraf; het is wel gebruikelijk om met capture-filters alleen zoveel data te onderscheppen als je echt nodig hebt, omdat je de netwerkkaart en de computer niet wilt overbelasten. Maar het capture-filter moet wel aangepast zijn aan de situatie.

In eerste instantie gaat het er bijvoorbeeld om, om alleen het verkeer van de endpoints van een verbinding vast te leggen. Dit kun je doen met het onderstaande capture filter:

Dit filter onderschept pakketten die de IPv4-host en de publieke DNS-server van Google met elkaar uitwisselen. Het voordeel is dat dan in Wireshark alleen de pakketten verschijnen die nodig zijn voor je huidige troubleshooting-sessie!

Is dat wel echt zo? Helaas niet! Dit komt omdat ICMP-errors meestal verzonden worden door de routers langs het traject en hun ip-adressen normaal niet bekend zijn voor het capturen. Met een capture-filter van dit type vallen dus nuttige foutcodes door de zeef en krijg je ze niet te zien.

Maar je kunt het filter eenvoudig uitbreiden om die foutmeldingen ook te onderscheppen. Voeg gewoonweg or icmp6 or icmp toe. Op deze manier komen wel alle ICMP-berichten in het filter terecht, maar ook die welke betrekking hebben op het netwerkverkeer van je twee hosts. Een capture is slechts zo goed als wat wordt vastgelegd. En nog even om te recapituleren, capture-filters hebben te maken met het commando tcpdump en moeten niet verward worden met de gelijknamige display-filters in de Wireshark GUI. Display-filters zoals

houden namelijk ook rekening met ICMP-errors. Maar dan moeten die wel in de capture aanwezig zijn.

ICMP-foutmeldingen geven niet alleen informatie over specifieke oorzaken, maar geven ook een indruk van hoe goed een bepaalde technologie op internet is geïmplementeerd.

Dat kwam aan het licht bij een intern onderzoek met een publieke NTP-server als onderdeel van het NTP Pool Project.

Gedurende een periode van twee maanden werden zowel IPv6 als IPv4 NTP-requests en de bijbehorende resultaten geregistreerd. Op basis hiervan is het dan mogelijk om vragen te beantwoorden zoals hoeveel netwerkfouten er vanuit internet naar de NTP-server worden gestuurd. Het waren er verbazingwekkend veel, zoals de tabel hieronder laat zien.

Statistieken van NTP-fouten

De statistieken laten in eerste instantie zien dat elk van de beschreven fouten op internet voorkomt en dat de routers de fouten meldden.

Het is echter verrassend dat veel meer dan één procent van de NTP-antwoorden niet wordt afgeleverd. De fout­meldingen zijn afhankelijk van het ip-protocol verschillend verdeeld; NTP-pakketten die werden aangevraagd en afgeleverd via IPv6 liepen in bijna 90 procent van de gevallen dood in het layer 3-­netwerk – blijkbaar faalde in deze gevallen de neighbor discovery. Dit zou veroorzaakt kunnen worden door bugs in de MAC-adresresolutie.

Bij NTP-pakketten die via IPv4 worden verzonden gaat de MAC-adresresolutie veel vaker goed. De meeste IPv4-fouten treden hier op bij de allerlaatste overdrachtsstap, namelijk het afleveren van de NTP-antwoorden aan de requesting clients. Hier zijn mogelijk de NTP-implementaties buggy.

Als je je Wireshark-vaardigheden wilt testen, dan hebben we een paar uitdagingen voor je. In het ‘Ultimate PCAP’-bestand (dat je hier vindt) zitten een aantal bugs waarmee je kunt oefenen en je vaardigheden kunt trainen.

Download het zipbestand naar je pc en open het met Wireshark. Voer vervolgens drie verschillende filters in en leid uit de Wireshark-weergave af welke oorzaken tot de respectievelijke resultaten hebben geleid.

En tot slot nog een tshark-uitdaging: Analyseer alle ‘destination unreachables’ van het type ‘port unreachable’ die zijn verzonden naar het IPv4-adres 194.247.5.12. Maak een lijst van alle IPv4-bronadressen en verwijder dubbele vermeldingen automatisch.

ICMP-mogelijkheden zijn bij veel beheerders misschien onbekend, maar het netwerk meldt daarmee in sommige gevallen de onderliggende oorzaak van een fout; de beheerder hoeft ze alleen maar te voorschijn te toveren en kan zo zijn diagnoses vaak drastisch beperken.

Deze shortcut is zowel te gebruiken voor haperingen in het lokale netwerk als op internet. Als de oorzaak binnen jouw verantwoordelijkheidsgebied ligt, leidt dit bijna altijd direct naar de oplossing.

Een struikelblok is de handmatige analyse – routers en zelfs moderne firewalls ­leveren geen ICMP-statistieken, laat staan duidelijke tekstuele informatie over mislukte ip-dialogen. Tijd voor een persoonlijke schoonmaak in je netwerk.