strange ping and traceroute results

[shimi]

On Sun, Nov 20, 2016 at 9:38 AM, Shlomo Solomon <shlomo.solomon at gmail.com>
wrote:

> On Sun, 20 Nov 2016 08:25:18 +0200
> shimi <linux-il at shimi.net> wrote:
>
> > I believe it's called a CDN and/or local compute clusters and the
> > purpose of it is to give you a better user experience, which is a
> > Good Thing (TM).
> >
> snip ... snip ... snip
> >
> > Why do you think it's a problem and are trying to avoid it?
> >
>
> Thanks. I agree that this is "normally" a Good Thing (TM). So I guess I
> have to explain my problem. For a course I'm doing, I had to write
> traceroute in Python   -   re-invent the wheel :-)
>
> My program works, but I noticed it never reaches www.google.com so I
> checked the "real" traceroute and found the same behaviour.
>
> It seems that neither my program nor the real traceroute handle this
> properly - i.e. they never report that they've reached the final hop.
> I've included traceroute www.godaddy.com and traceroute www.google.com
> for comparison. You can see that traceroute www.google.com never
> reaches the address it's trying to reach - 213.57.24.49
>
>
I do not believe the fact that you "can't reach it" has anything to do with
www.google.com resolving to an IP in Israel.

Since I am assuming that for your re-inventing the wheel exercise, you did
learn and understood what traceroute does; But let me explain it anyway for
the answer to your question lies within...

What traceroute does is essentially send packets to the destination IP by
certain protocol. Popular choices include UDP (I believe that's what the
Linux one does by default), ICMP (I believe that's what the Windows one
does by default) and TCP.

However, it doesn't send the packet as one normally would, with a large TTL
(Time To Live) value which is expected to reach anywhere on the Internet
(typical values: >= 64), rather than it starts of with setting a minimal
value for TTL, for the purpose of _not_ getting into the target IP, rather
than the packet being dropped by the very first router (hop) on the chain,
resulting in error in packet  delivery.

Per the IP specification, such a packet discarding SHOULD produce an
ICMP (Internet
Control Message Protocol) message being sent by the hop that has discarded
the packet towards the originator of the original packet, telling it that
"TTL expired in transit". The original idea was to avoid packets travelling
to infinitum in routing loops - by decreasing the TTL by 1 on every hop the
packet passes, eventually it will zero out, and the packet will be
discarded, not causing a bandwidth storm.

So, I said SHOULD. Does it always? Well, no. Some hosts on the Internet
employ something called "a firewall", which blocks ICMP for various reasons
(you'll hear the word "security" in some places); As a regular user who
opens his browser and types in 'https://www.google.com/' - you don't really
care. ICMP is not typically used when establishing a connection to a server
on the Internet (well, that's not accurate; lack of PMTU discovery is an
excellent way to get your IT people to pull some hairs out when any tunnel
is involved, including dialup and Israeli "MPLS" connections, a.k.a.
"dialer-less HOT"... but for the sake of discussion and to explain how did
they ended up deciding to filter those packets and affect you - probably
not knowing what else they break - then "it's not typically used")

Sometimes the filtering is not of ICMP at all, rather than the original
protocol you're trying to probe with; A random UDP port at the area of
30,000 typically has no business traversing their network, so your original
packet (if you're using UDP packets for your traceroute program) may have
been firewalled and never reached a router to lower its TTL by 1 and expire
it in transit to produce the ICMP message you're expecting... In that case,
where ICMP is not actually block, rather your UDP connection is, you might
find out that running:

traceroute -I 213.57.24.49

(I for ICMP Echo based traceroute)

Does actually get you to the target. However, you'll have to run this as
root, because generating ICMP packets is not something the regular user can
do. Of course, you can opt to chmod +s your traceroute binary...

Hope this helps,

-- Shimi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20161120/eefb61ba/attachment-0001.html>