Tools

Tools: Breaking: 23 Strangers Standing Between You and This Article

2026-04-24 0 views admin

Internet's Structure

How Traceroute Exploits This Network

The Ghosts, and Other Lies You clicked this link. Quite simple, right? But before these words appeared in your browser, they went on a little journey, hopping through routers, data centers, and cables you'll never see, operated by people you'll never meet. And you know what? You can see every one of those stops, and even trace the full path from your machine all the way to mine, or any server, really. The tool that lets you observe your route through the constellation of routers called the internet is traceroute (or tracert on Windows, I guess they wanted to be original). Let's run a traceroute: Looks like gibberish, right? But actually, it's easy to decipher. Let's analyze our data's journey: Each line is a stop. Let's walk through the journey. Your output will look different: different ISP, different city, maybe even different countries in between. But the story is the same: a chain of strangers, passing your data along. So in 11 hops, my request crossed my living room, my ISP, some of the thousand of internet backbones, crossed Germany, and landed on my server. All this in about 40 milliseconds. But how does traceroute even know all this? Well, it shouldn't. It's exploiting a small feature built into every router on the internet, originally designed to prevent flooding the network. The internet works a lot like the postal system. When you send a letter abroad, your local postman doesn't know the way to Germany, he just drops it at the sorting center. The sorting center sends it to the national hub. The national hub hands it to an international carrier. Nobody has the full map. Everyone just knows their next step. Your request leaves your home, climbs through your ISP, then through bigger and bigger backbone networks, like aorta.net or core-backbone.com from our traceroute, until it reaches the destination network, and works its way down to the target server. Each of those networks is owned by a different company, and they all just agreed to hand traffic to each other. All of this is coordinated by Border Gateway Protocol, a fascinating rabbit hole for another day. (Finish this article first.) What traceroute actually does is map every step your packet takes through the internet, and it does it by exploiting a feature that was never meant for this. To do that, it diverts the original purpose of TTL (Time To Live): as defined in the first IP spec (RFC 791), its intent was to "kill stale packets before they clog the network forever". Every IP packet has a TTL field that gets decremented each time it crosses a new router (transit point). When it reaches 0, the packet gets destroyed and the router that killed it warns the sender about it. You might already see the trick coming: by setting the TTL to 1, we can get the first router to drop the packet, and tell us it did. That gives us the first router's IP. Then we just repeat, incrementing the TTL each time to peel back one more hop. We keep going until the destination itself replies with either ICMP_ECHOREPLY or ICMP_DEST_UNREACH depending on the implementation, and that's our signal to stop. Here's the core loop in C, if you're curious: The full C code can be found on this gist. Remember hop 7, the one that went silent? And hop 8, the no-name one? They're not broken, they just don't want to be seen. Some routers are configured to drop ICMP packets (the ones traceroute uses to probe the network). They still forward the traffic just fine, but they don't want to play traceroute's little spy game. Others, like hop 8, simply don't have a reverse DNS record. And it gets worse. The route we just saw? It might not exist anymore. Run two traceroutes with a one-hour difference and you might see completely different routes, maybe even different countries. The internet reroutes itself constantly, reacting to routing metrics, failures, and countless other factors. There's no fixed path, but at least there will always be a path. Even the timings can lie. See how hop 4 shows 48 ms while hop 9 shows only 23 ms? A further hop that is faster than a closer one?! That's because routers prioritize "real" traffic over responding to ICMP probes. The latency numbers tell you something, but never everything. Remember that traceroute is a window into the internet, but not a clear one. Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to ? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse

Code Block

Copy

› tracert 152.53.236.228 Tracing route to theserver.life [152.53.236.228] over a maximum of 30 hops: 1 3 ms 1 ms 1 ms 192.168.1.1 2 20 ms 18 ms 11 ms 77-56-216-1.dclient.hispeed.ch [77.56.216.1] 3 15 ms 14 ms 13 ms 217-168-61-145.static.cablecom.ch [217.168.61.145] 4 48 ms 41 ms 27 ms carbsm101-be-2.aorta.net [84.116.211.21] 5 15 ms 15 ms 13 ms ch-otf01b-rc2-ae-54-0.aorta.net [84.116.202.225] 6 25 ms 13 ms 18 ms zur01lsr01.ae1.bb.sunrise.net [212.161.150.164] 7 * * * Request timed out. 8 39 ms 54 ms 14 ms 213.46.171.182 9 23 ms 20 ms 20 ms ae2-2015.nbg60.core-backbone.com [80.255.15.250] 10 23 ms 22 ms 24 ms ae12-500.nbg40.core-backbone.com [80.255.9.21] 11 36 ms 24 ms 45 ms theserver.life [152.53.236.228] Trace complete. › tracert 152.53.236.228 Tracing route to theserver.life [152.53.236.228] over a maximum of 30 hops: 1 3 ms 1 ms 1 ms 192.168.1.1 2 20 ms 18 ms 11 ms 77-56-216-1.dclient.hispeed.ch [77.56.216.1] 3 15 ms 14 ms 13 ms 217-168-61-145.static.cablecom.ch [217.168.61.145] 4 48 ms 41 ms 27 ms carbsm101-be-2.aorta.net [84.116.211.21] 5 15 ms 15 ms 13 ms ch-otf01b-rc2-ae-54-0.aorta.net [84.116.202.225] 6 25 ms 13 ms 18 ms zur01lsr01.ae1.bb.sunrise.net [212.161.150.164] 7 * * * Request timed out. 8 39 ms 54 ms 14 ms 213.46.171.182 9 23 ms 20 ms 20 ms ae2-2015.nbg60.core-backbone.com [80.255.15.250] 10 23 ms 22 ms 24 ms ae12-500.nbg40.core-backbone.com [80.255.9.21] 11 36 ms 24 ms 45 ms theserver.life [152.53.236.228] Trace complete. › tracert 152.53.236.228 Tracing route to theserver.life [152.53.236.228] over a maximum of 30 hops: 1 3 ms 1 ms 1 ms 192.168.1.1 2 20 ms 18 ms 11 ms 77-56-216-1.dclient.hispeed.ch [77.56.216.1] 3 15 ms 14 ms 13 ms 217-168-61-145.static.cablecom.ch [217.168.61.145] 4 48 ms 41 ms 27 ms carbsm101-be-2.aorta.net [84.116.211.21] 5 15 ms 15 ms 13 ms ch-otf01b-rc2-ae-54-0.aorta.net [84.116.202.225] 6 25 ms 13 ms 18 ms zur01lsr01.ae1.bb.sunrise.net [212.161.150.164] 7 * * * Request timed out. 8 39 ms 54 ms 14 ms 213.46.171.182 9 23 ms 20 ms 20 ms ae2-2015.nbg60.core-backbone.com [80.255.15.250] 10 23 ms 22 ms 24 ms ae12-500.nbg40.core-backbone.com [80.255.9.21] 11 36 ms 24 ms 45 ms theserver.life [152.53.236.228] Trace complete. 192.168.1.1 cablecom.ch sunrise.net core-backbone.com core-backbone.com ICMP_ECHOREPLY ICMP_DEST_UNREACH for (int ttl = 1; ttl <= MAX_HOPS; ttl++) { // Set the TTL to the current iter ttl setsockopt(send_sock, IPPROTO_IP, IP_TTL, &ttl, sizeof(ttl)); char buf[BUF_SIZE]; struct sockaddr_in from; socklen_t from_len = sizeof(from); // Ping the target router 3 times to get the 3 delays for (int i = 0; i < PROBE_COUNT; i++) ms[i] = ping(send_sock, recv_sock, buf, &dest, &from, &from_len); /* print stats Skipped it for this example */ if (icmp_hdr->type == ICMP_ECHOREPLY && from.sin_addr.s_addr == dest.sin_addr.s_addr) break; } for (int ttl = 1; ttl <= MAX_HOPS; ttl++) { // Set the TTL to the current iter ttl setsockopt(send_sock, IPPROTO_IP, IP_TTL, &ttl, sizeof(ttl)); char buf[BUF_SIZE]; struct sockaddr_in from; socklen_t from_len = sizeof(from); // Ping the target router 3 times to get the 3 delays for (int i = 0; i < PROBE_COUNT; i++) ms[i] = ping(send_sock, recv_sock, buf, &dest, &from, &from_len); /* print stats Skipped it for this example */ if (icmp_hdr->type == ICMP_ECHOREPLY && from.sin_addr.s_addr == dest.sin_addr.s_addr) break; } for (int ttl = 1; ttl <= MAX_HOPS; ttl++) { // Set the TTL to the current iter ttl setsockopt(send_sock, IPPROTO_IP, IP_TTL, &ttl, sizeof(ttl)); char buf[BUF_SIZE]; struct sockaddr_in from; socklen_t from_len = sizeof(from); // Ping the target router 3 times to get the 3 delays for (int i = 0; i < PROBE_COUNT; i++) ms[i] = ping(send_sock, recv_sock, buf, &dest, &from, &from_len); /* print stats Skipped it for this example */ if (icmp_hdr->type == ICMP_ECHOREPLY && from.sin_addr.s_addr == dest.sin_addr.s_addr) break; } - The first one, 192.168.1.1, is my own router, still in my living room. The first stranger is actually myself. - Hops 2 and 3 are my ISP: the entrance to the highway. You can even see it in the hostnames: cablecom.ch, a Swiss internet provider, handing my data off to the wider world. - Hops 4 through 6 are that highway. aorta.net, sunrise.net are transit backbones you've probably never heard of, but your data uses constantly, every single day. - Hop 7 is a ghost. Three * instead of a response. Looks like someone doesn't want to be seen. We'll come back to that. - Hop 8 is another silent one, no hostname, just a raw IP. Not hiding, but not introducing itself either. - And then 9 and 10 are another backbone, core-backbone.com, and if you squint at the hostname you can see nbg: Nuremberg, Germany. My data just crossed a border. - 11 is home, well, my home. The server.

Share this article

Twitter Facebook LinkedIn Reddit

🏷️ Tags

toolsutilitiessecurity toolsbreakingstrangersstandingbetweenarticle

More from Tools

Tools: 💻 Windows vs Linux Dedicated Server: A Technical Breakdown for 2026 - Guide

2026-04-24 0

Tools: IPTV Systems Architecture: The Brutal Realities of Scaling - Complete Guide

2026-04-24 0

Tools: Update: Step-by-Step Guide: Setting Up IPTV on Enigma2 with XtreamTV

2026-04-24 0

Tools: Building an AI API Gateway with One-API: A Practical Guide - Analysis

2026-04-24 0

Trending

1

CVE-2025-61481: Critical Remote Code Execution Vulnerability in MikroTik RouterOS & SwitchOS

2025-10-27 • 189 views

2

CVE-2025-43939: Dell Unity OS Command Injection (High)

2025-10-30 • 148 views

3

Google disputes false claims of massive Gmail data breach

2025-10-30 • 130 views

4

Microsoft: DNS outage impacts Azure and Microsoft 365 services

2025-10-30 • 88 views

5

3.5B Accounts, 1 Critical Flaw: Meta Closes WhatsApp Data-Harvesting

2025-11-25 • 81 views