关于网络安全:向xxxhub发了一个数据包发现了一些不可告人的秘密

38次阅读

共计 2953 个字符,预计需要花费 8 分钟才能阅读完成。

大家好,我是周杰伦。

那天,我忽然想到一个问题:

当我拜访那个让万千宅男程序员为之着迷的 GitHub 时,我电脑收回的数据包是如何到达大洋彼岸的 GitHub 服务器的呢,这两头又要通过哪些节点呢?

让咱们一起来探索下这个问题,请留神系好安全带,计算机网络慢车要发车了···

IP 报文

互联网把有数的手机、电脑、服务器、路由器、交换机等各种设施连贯在一块儿,那这些设施之间要通过网络通信,天然就须要一套通信协议,TCP/IP 就是这样一套协定。

包含浏览器在内的这些应用程序收回的数据,被 HTTP、TCP、IP 协定层层封装,最终造成一个个的 IP 报文,交给底层网卡收回去。

IP 报文通过网络中节点的一直路由转发,最终来到了指标服务器。

那如何晓得路由转发过程中,都通过了哪些网络节点呢?

Windows 上的 tracert 程序和 Linux 上的 traceroute 程序就可能做到。

它们是如何做到的呢?

IP 报文总不能无限度转发吧,万一搞了个循环转发,那不就没完没了了?网络中的 IP 报文有一个生存工夫的概念,位于 IP 报文头部字段中——

TTL:time to live。

每通过一次转发,TTL 的值就会减 1。如果某一个节点发现 TTL 变成了 0,就会丢掉这个 IP 报文,并给这个数据报文的发送者发一个超时的告诉音讯过来。

tracert 和 traceroute 正是利用了 IP 协定中的这个特点,将 TTL 的值从 1 开始递增,察看都是谁给本人发回了这个告诉,就能判断路由过程中经验了哪些节点了。

这两个程序的区别在于,tracert 发送的是 ICMP 报文,traceroute 发送的则是 UDP 报文。

路由跟踪

好了,基础知识交代结束,连忙来试一下,拜访 GitHub 的状况。

首先 ping 了一下,拿到了 GitHub 的 IP 地址:140.80.121.3。留神,这个地址,不同地区的人拿到的可能不一样。

接下来路由跟踪一下吧:

F:\work>tracert 140.82.121.3

通过最多 30 个跃点跟踪
到 lb-140-82-121-3-fra.github.com [140.82.121.3] 的路由:

  1    <1 毫秒   <1 毫秒   <1 毫秒 10.??.??.1
  2    <1 毫秒   <1 毫秒   <1 毫秒 10.??.??.??
  3     2 ms     1 ms     1 ms  182.150.63.1
  4     *        *        *     申请超时。5     1 ms     *        2 ms  171.208.199.81
  6     *       25 ms     *     202.97.29.45
  7     *        *        *     申请超时。8    36 ms    37 ms    36 ms  202.97.91.190
  9   184 ms   191 ms   185 ms  202.97.27.242
 10   195 ms   194 ms   194 ms  xe-10-0-0.mpr4.sjc7.us.zip.zayo.com [64.125.14.45]
 11   190 ms   190 ms   190 ms  ae16.cr2.sjc2.us.zip.zayo.com [64.125.31.14]
 12   324 ms   325 ms   324 ms  ae27.cs2.sjc2.us.eth.zayo.com [64.125.30.232]
 13     *        *      333 ms  ae16.cs2.den5.us.zip.zayo.com [64.125.28.215]
 14   334 ms     *        *     ae5.cs4.ord2.us.eth.zayo.com [64.125.29.217]
 15     *      327 ms   325 ms  ae3.cs2.lga5.us.eth.zayo.com [64.125.29.212]
 16     *        *        *     申请超时。17     *        *        *     申请超时。18   332 ms   332 ms   340 ms  ae0.cs1.lhr15.uk.eth.zayo.com [64.125.29.119]
 19     *        *        *     申请超时。20   343 ms   338 ms     *     ae4.cs1.ams17.nl.eth.zayo.com [64.125.28.36]
 21   355 ms   353 ms   353 ms  ae2.cs1.fra6.de.eth.zayo.com [64.125.29.58]
 22   335 ms   334 ms   338 ms  ae1.mcs1.fra6.de.eth.zayo.com [64.125.29.57]
 23   340 ms   341 ms   341 ms  82.98.193.31
 24     *        *        *     申请超时。25     *        *        *     申请超时。26   335 ms   343 ms   343 ms  lb-140-82-121-3-fra.github.com [140.82.121.3]

能够看到,通过了 26 个节点的转发后,最终达到了 GitHub 服务器。也就是说,你电脑收回的 IP 报文的 TTL 至多要大于等于 26 能力到达 GitHub,否则就会中道崩殂。

【配套技术文档】

接下来,咱们来看一下,这一路都去了哪里?

1-2

数据包从我的计算机收回后,遇到的第一个转发节点就是我的本地局域网网关:10.??.??.1。为了安全性,我把 IP 地址进行了脱敏,两头两段用? 代替。

这之后第二个节点还是局域网的地址,由此可见,我所在的网络格局,通过了两级局域网路由转发才上了公网。

3

第三个转发节点是一个公网地址:182.150.63.1,查了一下发现位于成都市武侯区,这和我的理论状况相符。

4

接下来的第四个路由节点就有点迷了,三个工夫点都是 *,tracert 显示申请超时。呈现这个意味着 tracert 程序在将 TTL 设置为 4 后,没有收到告诉,或者期待的工夫太久。网络中的有一些节点出于平安思考可能并不会发送超时告诉。

如此一来,tracert 便无奈晓得这第四个节点到底是谁。

5

第五个节点是:171.208.199.81,依然还在成都。

6

第六个节点时:202.97.29.45,到了北京了。

【配套技术文档】

7

第七个节点和第四个一样,也看不到。

8

第八个节点:202.97.91.190,来到上海了。

9

第九个节点:202.97.27.242,还在上海。

10

第十个节点:出国了,美国加利福尼亚州。

前面的咱就不看了,就是在美国境内各个节点的转发了。

接下来看一下,这是一条什么样的门路呢?

ChinaNet

网络数据包出了咱们本地的局域网后,就会通过电信运营商提供的城域网最终接入到更大的骨干网。

中国大陆地区的民用骨干网次要有四个:

    ChinaNet:中国电信 163 骨干网
    CN2:中国电信下一代承载网
    CHINA169:中国联通 169 骨干网
    CMNET:中国移动骨干网

其中中国电信的 163 骨干网和中国联通的 169 骨干网是最次要的两个骨干网,承载了中国互联网绝大多数的流量。

我所在的网络,最初接入的就是中国电信的 163 骨干网,上面是 163 骨干网的一个大抵网络拓扑图。

163 骨干网在全国总共有 9 个外围节点:

    超级外围:北京、上海、广州
    一般外围:天津、西安、南京、杭州、武汉、成都

9 个外围节点各自负责中国大陆的一部分区域。

在北京、上海、广州三个超级外围下还挂有国内网间互联设施(X 路由器),ChinaNet 通过 X 路由器与世界上其余运营商互联和流量互访。

因而,通过 163 网络出国,必然通过北上广三个外围节点之一。

GitHub 的服务器位于美国,对于一个要出国的数据包,它在出国前的大抵旅程是这样的:

本地局域网 -> 市级网络 -> 省级网络 -> 外围节点 -> 国内进口 -> 境外接入点

这个过程跟咱们下面 tracert 追踪到的门路是吻合的。

想不到吧,就那么一回车,数据包居然就跑了这么多中央,计算机网络真是一个神奇的玩意。

【配套技术文档】

正文完
 0