Re: strange ping and traceroute results

[Shachar Shemesh]

On 20/11/16 07:01, Shlomo Solomon wrote:
> When I try ping or traceroute to www.google.com, I get strange results.
> Both utilities "think" that www.google.com is at 213.57.*.*, but those
> addresses belong to my Internet provider - Hotnet.
>
> What am I missing?
>
> [solomon@shlomo1]$ ping www.google.com
> PING www.google.com (213.57.23.29) 56(84) bytes of data.
> 64 bytes from 213.57.23.29: icmp_seq=1 ttl=59 time=17.1 ms
> 64 bytes from 213.57.23.29: icmp_seq=2 ttl=59 time=16.8 ms
> 64 bytes from 213.57.23.29: icmp_seq=3 ttl=59 time=17.1 ms
>
> [solomon@shlomo1]$ sudo traceroute www.google.com
> traceroute to www.google.com (213.57.24.55), 30 hops max, 60 byte packets 
> 1  router-1.solomon (10.0.0.138)  1.010 ms  1.007 ms  1.006 ms
> 2  core-213-57-3-7.ptr.hotnet.net.il (213.57.3.7)  15.379 ms  15.741 ms  
> 16.551 ms 
> 3  ae7.101.hfa.mx-lns.con.hotnet.net.il (213.57.3.221) 36.177 ms  36.182 ms  
> 36.178 ms 
> 4  core-213-57-3-217.ptr.hotnet.net.il (213.57.3.217)  17.736 ms  17.736 ms  
> 17.733 ms 
The DNS resolving google.com guesses your gegraphical location, and
gives you an answer that is nearest where you are. If you use another
DNS to query the domain, you will get a different IP:


216.58.218.196 from
http://mxtoolbox.com/SuperTool.aspx?action=a%3awww.google.com=toolpage
74.125.22.103 from https://www.ultratools.com/tools/dnsLookupResult
216.58.209.68 from http://ping.eu/nslookup/

If you are dead set on using a different IP than your local one, you can
use this trick to do this.

Shachar
___
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il

Re: strange ping and traceroute results

[Shlomo Solomon]

On Sun, 20 Nov 2016 10:18:37 +0200
shimi  wrote:

Thanks for your very detailed reply. As you correctly assumed, I did
learn about traceroute before re-inventing the wheel, so most of what
you wrote was familiar. But I didn't know about the -I parameter.
 
traceroute -I www.google.com does, as you wrote, get to the target. 

Since I think that that's more than I'm expected to emulate, I
added a more "friendly" error message to my program in the case of a
(FW caused) timeout.




-- 
Shlomo Solomon
http://the-solomons.net
Sent by Claws Mail 3.11.1 - KDE 4.14.5 - LINUX Mageia 5


___
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il

Re: strange ping and traceroute results

[Amos Shapira]

Google.com is not one computer. Google spreads their locations all over the
world including pops in many ISP's.

https://peering.google.com/#/

On 20 November 2016 at 19:18, shimi  wrote:

>
>
> On Sun, Nov 20, 2016 at 9:38 AM, Shlomo Solomon 
> wrote:
>
>> On Sun, 20 Nov 2016 08:25:18 +0200
>> shimi  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
>
>
>
> ___
> Linux-il mailing list
> Linux-il@cs.huji.ac.il
> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>
>


-- 

___
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il

Re: strange ping and traceroute results

[shimi]

On Sun, Nov 20, 2016 at 9:38 AM, Shlomo Solomon 
wrote:

> On Sun, 20 Nov 2016 08:25:18 +0200
> shimi  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
___
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il