Gør det selv-efterforskning: Hvis ping-tiden er under 80-90 millisekunder, så er ip-adressen ikke i USA

Ping og traceroute er værktøjer, der kan bruges til at komme det lidt nærmere, hvor en ip-adresse faktisk befinder sig.

Måske vil du gerne vide lidt mere om, i hvilket land server-ip-adressen bag en webshop befinder sig - eventuelt i forbindelse med opklaringen af, hvorvidt der er tale om en fup-butik.

Måske har du en helt anden grund til at ville vide lidt mere om, hvor en ip-adresse faktisk hører til, samt hvilken vej dine data bevæger sig på internettet, når du kommunikerer med ip-adressen.

Selvom du ikke har ressourcer som en politimyndighed, så kan frit tilgængelige værktøjer alligevel give dig et fingerpeg om, hvor en ip-adresse faktisk hører hjemme.

Forleden bragte Version2 en historie om, at amerikanske Homeland Security og politimyndigheden FBI tilsyneladende har byttet rundt på Schweiz og Swaziland i forbindelse med fastsættelsen af lokationen for flere ip-adresser, som myndighederne har offentliggjort sammen med en rapport om russiske hackerangreb mod USA.

Læs også: Swaziland eller Switzerland? FBI tavs om afvigelser i russerhack-dokumentation

Der er flere måder at fastsætte lokationen af ip-adresser på. Hvis der er tale om en politimyndighed som FBI, så kan det være en mulighed at kontakte andre myndigheder i for eksempel Danmark og få dem til at hjælpe med at fastslå, hvor en ip-adresse hører hjemme.

Har man ikke den mulighed, og er man alligevel nysgerrig efter, hvem der er i den anden ende af dataforbindelsen, så kan flere frit tilgængelige værktøjer måske give et praj.

Som en del Version2-læsere vil vide, så er det blandt andet muligt at slå ip-adresser op i åbne whois-registre på nettet for at få en idé om, i hvilket land en ip-adresse hører hjemme.

Ping-tider

Men der kan dog snige sig forkerte data ind i disse registre, påpeger direktør hos internetudbyderen Kviknet Yoel Caspersen. Og samtidig kan det være svært uden videre at verificere, hvorvidt whois-data faktisk er korrekte.

»Der er nogle helt håndfaste ting, man kan udlede, hvis man for eksempel kan se ping-tider,« fortæller Yoel Caspersen.

Ping-tiden fortæller, hvor lang tid det tager for en datapakke at bevæge sig frem og tilbage mellem en kilde til en destination. Og dermed kan ping-tiden også sige noget om den fysiske afstand mellem to ip-adresser.

»Generelt er det sådan, at hvis man laver et ping på tværs af Atlanterhavet, ja, så er ping-tiden 80-90 millisekunder bare for den strækning. Hvis man skal over på den vestlige side af USA, så lægger man fyrre millisekunder oveni,« siger Yoel Caspersen.

Med andre ord: Hvis ping-tiden er mindre end 70-80 millisekunder, så ligger den ip-adresse, der svarer, i hvert fald ikke i USA, påpeger Yoel Caspersen.

Mens ping-tiden sætter en øvre grænse for, hvor langt væk en ip-adresse fysisk kan befinde sig, så betyder en høj ping-tid ikke nødvendigvis, at ip-adressen også befinder sig langt væk.

»Ping-tiden kan godt være højere, end den fysiske afstand tilskriver. Det har noget at gøre med, at udstyr i mange tilfælde er sat op til at nedprioritere ping-forespørgsler. Men den kan under ingen omstændigheder være lavere, end den fysiske afstand tilskriver,« siger Yoel Caspersen.

Traceroute

En måde at se ping-tiderne på er, som en del Version2-læsere allerede vil vide, ved at anvende kommandoen ‘ping’ i både Windows og Linux i forhold til en given ip-adresse.

Hvis man også vil se, hvilken vej trafikken bevæger sig over internettet, kan en anden mulighed være kommandoen tracert på Windows og værktøjet traceroute på Linux.

Ud over pingtider viser værktøjerne også, hvilke andre ip-adresser trafikken går igennem på vej hen til destinationen.

Der kan være forskel i de ping-tider, som traceroute giver i forhold til en given ip-adresse, og så værktøjet ping. Yoel Caspersen påpeger, at det blandt andet afhænger af, hvilken protokol.

Ved brug af traceroute eller tracert påpeger Yoel Caspersen, at oplysningerne fra de enkelte hops, som dataforbindelse går igennem, godt kan være vildledende.

»En router kan i bund og grund svare med en hvilken som helst ip-adresse på en traceroute. Det vil sige, at der ikke er nogen garanti for, at den ip-adresse, man får retur, er korrekt. Men ofte er det sat sådan op, at ip-adresser, som bliver besvaret med en traceroute, de vil have en reverse DNS-registrering, som giver et fingerpeg om, hvor udstyret står henne,« fortæller Yoel Caspersen.

Et reverse DNS-lookup vil sige et opslag på ip-adresse, der bliver oversat til et domænenavn som eksempelvis version2.dk

»Det er typisk store ISP'er, som vælger at inkludere bynavne eller noget andet for reverse DNS-entry for deres ip-adresser,« siger Yoel Caspersen.

Skjulte hops

Mens traceroute i udgangspunktet giver et overblik over, hvilken rute datatrafikken tager på internettet, så kan flere elementer godt være skjulte i oversigten.

»Hvis de flere brugere på en DSL-forbindelse forsøger at lave en traceroute til et nyhedssite eller andet i Danmark, så vil de typisk kun se nogle få hops inden trafikken kommer ud af deres udbyders netværk, men faktum er, at rigtig mange DSL-brugeres trafik går via TDC's netværk, hvor der er adskillige hops nedenunder, men det bliver maskeret at netværket,« fortæller Yoel Caspersen.

En anden forklaring på, hvorfor outputtet fra en traceroute kan ende med at se mærkeligt ud, kan ifølge Yoel Caspersen være, hvis der er en eller anden form for data-tunnel involveret. Eksempelvis i form af en VPN-forbindelse.

»Det kunne betyde, at man lige pludselig ser meget lang pingtid mellem to hops, som umiddelbart ser ud til ikke at ligge så langt fra hinanden. VPN-tunnelen kan skjule nogle af de fysiske hops, som trafikken bevæger sig via.«

Og her kan en høj ping-tid et sted på ruten måske være en indikator på, at trafikken et sted i forløbet bevæger sig over et helt andet land og omkring langt flere hops, end det umiddelbart fremgår af et traceroute output.

»Hvis jeg har en Openvpn-forbindelse oppe at køre og laver en traceroute på den, så vil det kun vise et hop mellem mig og VPN-serveren, selvom forbindelsen jo alt andet lige går hen over det offentlige internet, og der måske er 10 forskellige routere involveret i trafikken,« forklarer Yoel Caspersen.

Han understreger, at ping-tider og antallet af hops kun kan give et praj om, hvor en ip-adresse befinder sig, og at det altså ikke er noget endegyldigt bevis. Men når det er sagt, så mener Yoel Caspersen også, at værktøjer som traceroute og tracert ofte vil give et mere retvisende billede end blot et whois-opslag på nettet.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (8)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Baldur Norddahl

Prøv https://geotraceroute.com

Virker bedst på lidt længere afstande.

Du kan også bruge RIPE Atlas https://atlas.ripe.net/ til at lave ping eller tracerotue fra et større antal noder rundt omkring. Så kan man simpelt sortere efter ping tid og finde den node der er tættes på det du søger.

I øvrigt kan det anbefales at bruge "mtr" (Linux/MacOS) eller "winmtr" (Windows) i stedet for traceroute.

Hvis der er noget i mangler i artiklen, så er det lidt omtale omkring anycast og content delivery netværk.

Anycast betyder at en IP adresse kan være mange steder i verden på samme tid, hvilket gør det noget svært at vide præcis hvorfra din trafik kommer. Et eksempel på det er Googles anycast DNS severer der hedder 8.8.4.4 og 8.8.8.8 som altid går til en lokal server tæt på dig.

Content delivery netværk eller CDN er en tjeneste hvor websider bliver gemt på en lokalt placeret server. Hvis du laver en traceroute på et amerikansk nyhedssite som cnn.com, så er de tilsyneladende placeret på en server et sted i Danmark - hvordan? Simpelt de har købt plads på et CDN som så har en cache af deres site i mange lande inklusiv Danmark.

Yoel Caspersen Blogger

Prøv https://geotraceroute.com

Virker bedst på lidt længere afstande.

Ud over at være et fedt værktøj, viser Geotraceroute også, hvor langt fra en eksakt videnskab, det er at afgøre, hvor en IP-adresse hører hjemme.

Fx mener Geotraceroute, at kviknet.dk hører hjemme i Köln, mens gigabit.dk hører hjemme i Odense. Jeg kan forestille mig, at gigabit.dk bliver mapped til Odense gennem firma-adressen i whois-opslaget, men der må foregå noget sort magi, siden kviknet.dk bliver mapped til Köln. Mon Bundesnachrichtendienst sidder og sniffer vores trafik? ;-)

God pointe om anycast og CDN.

Martin Jensen

Jeg synes tit man hører, at "icmp nedprioriteres" - men så vidt jeg ved er det kun tilfældet når man pinger en SVI/noget på en router, eller rammer det ifm en trace hvor ttl sænkes og man effektivt ender med at ramme en routers cpu.

Omvendt, hvis man pinger en fra/mellem windows/linux maskiner, så vil der typisk end-to-end ikke blive skelnet til hvad pakken indeholder. Jeg har mig bekendt ikke selv set at nogen har ulejliget sig af at lave QoS på ICMP på internet transit/peeringer på noget der ikke var en slut-bruger installation.

Mit spørgsmål: Har nogen af Jer set et ikke-slutbruger kredsløb, hvor icmp som ikke vedrørte selve routens udstyr/ddos mitigering mm. er blevet prioriteret ned eller ratelimited?

Yoel Caspersen Blogger

Mit spørgsmål: Har nogen af Jer set et ikke-slutbruger kredsløb, hvor icmp som ikke vedrørte selve routens udstyr/ddos mitigering mm. er blevet prioriteret ned eller ratelimited?

For mit vedkommende: Umiddelbart nej.

Vi har af og til kunder, som sætter smokeping op og pinger deres default gateway, som i vores tilfælde er en ZTE-router. De undrer sig over de svingende resultater, og vi plejer at henvise dem til at teste mod en af vores Linux-servere, netop for at få et pålideligt resultat.

Morten Brørup

Martin og Yoel gør ovenfor opmærksom på, at ping (ICMP ECHO) til en switch/router skal håndteres af switchens/routerens CPU, og her kan svartiden både være relativt lang og varierende - nogle gange helt op til 50-100 ms. Det skyldes, at en switch/router kun har en relativt lille CPU, og når den har travlt med noget andet, fx at indsamle statistik eller vedligeholde timere på en MAC-tabel, kan der gå nogle millisekunder, før den tildeler CPU-tid til den systemproces, der svarer på ping.

Ved "traceroute" (ICMP- eller UDP-pakker med stigende TTL) er det routing-chippen (dvs. data-planet) i routerne undervejs, der tæller TTL ned, når pakken bliver ekspederet videre, og det går lige så hurtigt som at sende normale datapakker videre. Men når pakkens TTL når 0, bliver "traceroute"-pakken ikke sendt videre, men derimod sendt op til routerens CPU (dvs. kontrol-planet). Her bliver pakken i store træk behandlet på samme måde som en ping-pakke til routeren selv, og derfor kan man se samme fænomener med høje og svingende svartider fra routerne undervejs i en traceroute, som ved ping til routeren.

For at overvåge svartid, pakketab og jitter på en internetforbindelse er det derfor mere retvisende at teste mod en server (med en kraftig CPU) end mod en router (med en relativt langsom CPU) - præcis som Yoel også anbefaler sine kunder.

Vi anbefaler, at man overvåger svartid/pakketab/jitter mod remote gatewayen (dvs. routeren hos internetudbyderen), mod de relevante servere hos sine cloud-/hosting-leverandører (IP-PBX, webserver, windows-server, osv.) og mod kendte offentlige servere, fx www.google.com og www.microsoft.com. Så får man også overvåget sin internetudbyders peering-forbindelser videre ud til resten af internettet samt til sine cloud-leverandører.

Med venlig hilsen

Morten Brørup
CTO, SmartShare Systems

Mogens Bluhme

Det er vel typisk svartider på webapplikationer, man er interesseret i. Dem er der ingen, som er interesseret i at underprioritere. Der kan dog også være fejlkilder her, eksempelvis CDN-providere, der bruger Destination NAT. En god idé er at bruge eksemplvis Selenium der kan emulere rigtige browsere idet User-Agent : Python kan misfortolkes som en (uønsket/ukendt) bot.

Log ind eller Opret konto for at kommentere