MENU

有关 NextTrace 的一些碎碎念

December 14, 2022 • 公告

好久不写博客了,再回来对面板已经略显生疏,不过马上就要年底了,还是来发一篇总结吧。

前言

今年做的最大的一个项目就是 NextTrace Project,可以说是把半年的绝大多数精力都投入在里面了,但真正的心里想要的那种效果也从这个月开始才慢慢体现出来,这个沉没成本高的有点让人无法接受,但是值得。

说实话,做的很痛苦(此处应有痛苦面具),或许是我朋友对于 NextTrace 抱有太高的期待,以至于我不仅要在基础功能上发力,还得在 IP 数据的精准度上发力,或许这也验证了想要脱离所有的外援,使用自己手里的资料,去尽力复刻 BestTrace 那样的体验是一件几乎不可能的事情,这里向坚持多年的 IPIP 团队致敬

不过话说回来,我最初做 NextTrace 也并没有把这个看的非常重要,毕竟对我来说,还是更乐意去研究一些实现路由跟踪背后的原理,实现好以后我自己的需求就已经是满足了,IP 地理位置只是一个附带的“玩具”,日常参考一下就可以了。

考虑到自己的朋友也都或多或少有这些需求,可以在 BestTrace 403 以后多一个备胎,早期的 NextTrace 版本也是奔着这个理念而去的。

变故

NextTrace 的发展有点出乎我所料的是,这类软件的受众群体似乎比我想象中的要广泛得多,很快就有朋友写信给我提出了对于骨干网 IP 地理位置精准度的更高要求。

当然,我没有直接回应对他的期待,只是说会“考虑一下”,因为我先前没有校准过此类骨干网的经验,网上也很难找到这方面的资料。我对于校准骨干网的兴致也没有那么大。

相比之下,我觉得我应该把事件多放在刷 LeetCode 上面,毕竟 2022 年又是一个求职的困难年,不刷面经,不刷题库可能意味着毕业即失业,相比于一个开源项目而言,自己的前途还是更重要,当时也没有放在心上。

这也是为什么,初期的 NextTrace 在骨干网上的精准度是一团糟的,因为我完全没有意愿去校准它们,毕竟有 BestTrace 这样的老大哥还在,去重复造轮子没有太大的意义。

这期间,一直有不少热心的朋友来贡献数据(在此表示感谢!),在有一次偶然的聊天中,我意外得知 NextTrace 已经成为开源路由跟踪软件中最被寄予厚望的一个时,我突然有点不胜惶恐,有好多朋友希望我在上面能做些什么,其中一位的话虽然我当时听着有点不大舒服,但是我还是接受了下来。

没有一个精准骨干网库的路由跟踪软件是不完整的

寻找一个媲美 IPIP 那样精准的骨干网库显然难如登天,我在最开始就没有抱有任何期望,想着寻找一个能对一半的 IP 库就已经知足了。只是我大大高估了对众多 IP 库的期待,现在市面上大部分的 IP 库都是不校准骨干网数据的,所以在测试骨干网时全都没有数据。最后终于找到 2 个有骨干网数据的了,但是其精准度和 IPIP 比实属逊色,但哪怕这样也是最好的结果了。

维护一个自己的微型骨干网库

在长时间的路由跟踪测试后,我发现不管是什么库,对于城域网的 IP 能够精准到省、州还是很容易的,但是对于骨干网通常只能精确到国家,到省份的数据就基本都是错的了。

PS:我今天做了一个小实验,拿我确定已经校对的 100 个骨干网 IP,和最初的几个库去做了一下对比测试,能够精确到国家的有 85%,精确到省/州的仅剩 36%,城市级别因为我自己也不能确保是对的,故不做比对。

这样的数据用在路由跟踪上虽然不尽如人意,但是他们至少还是在上面努力过了,毕竟我能校准的只是这里面不超过 10% 的全球骨干网数据,相比于其他那些直接在这上面“摆烂”的来说,已经算是负责任的。

估摸着如果可以在这些库的基础上,去校准一些,那样是不是就会好很多?我就是抱着这样的心态,开始跌跌撞撞地维护起一个自己的库。

想要确定一个骨干网 IP 的地理位置是否错了,主要有以下几种手段:

一、海量节点检测法

顾名思义,就是部署海量节点,在全世界范围内 Ping,延时 <2ms 的地方通常就是那个骨干网所在的地方了。

但是这样有几个问题:

  1. 成本极其高昂,因为需要全世界的节点,所以至少要买上百个 VPS 说不准才能勉强满足需求,不可持续。
  2. 骨干网节点哪怕就在监测节点所在城市,因为路由表的规则设置实际产生了绕路导致延时不能作为参考依据。
  3. 非常浪费时间,光是买服务器的沟通就要大把时间投入在内,对于现在的我不可接受。

这种方案可以作为辅助,但是不能成为主力军,虽然它后期最省事。

二、rDNS 正则提取法

一些 ISP 会在自己的骨干网 IP 上标注自己的一些信息,方便他们自己维护,这里面可能就包含节点的地理位置信息。

这些地理位置信息通常是使用三位 IATA (机场)码来表示的,骨干网节点通常以最近的大型的国际机场来命名,比如 FRA = Frankfurt International Airport(法兰克福国际机场),只需要提取到这些信息,然后直接转化为对应的地理位置就可以了。

这么做也有几个问题:

  1. 在同一个城市,不同 ISP 可能使用不同的机场作为位置标识使用,也有 ISP 遵守自己的地理位置规则,如把法兰克福简写为 FKT。
  2. 很多 ISP 根本就没有 rDNS,其内部是完全黑箱的,只能根据延时去推测。
  3. 一些 ISP 的 rDNS 更新很不及时,一些 IP 明明已经用在了新的地方,但是 rDNS 没更新。

所以这个方案可以使用,但是应该只对有限的几个 T1 ISP 使用,他们对于 rDNS 更新相对勤快一些,对于一些 T2 乃至 T3 的 ISP 在没有更好的数据来源之前虽然也可以使用,但是仍旧应该注意他们的写法未必会遵守规范,可能导致一些地理位置的判断错误。

三、路由日志推测法

既然一些 ISP 的地理位置信息不能通过 rDNS 来获得,我们也可以通过历史的路由日志来推测。我们之前也提到了,对于 ISP 的精准度在城域网上一直很好,这里我们可以通过城域网倒退骨干网的最后一跳的地理位置。

这种方案需要我们知道,IX、PoP、Transit、Peer 、Cust 在哪里发生,有些我们可以通过 rDNS 上面来判断,有些我们可以通过 ISP 的边缘路由 IP 段来判断。

下面是一个非常简单的例子(注意,这是为了方便理解,实际没有那么简单)

root@nl-leo:~# mtr -r -z 5.101.218.1
Start: 2022-12-13T22:54:40-0500
HOST: nl-leo                      Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS208046 185.99.135.2         0.0%    10    0.2   0.4   0.2   1.2   0.3
  2. AS49981  109.236.95.224       0.0%    10    0.3   0.4   0.3   0.5   0.0
  3. AS49981  109.236.95.108       0.0%    10    1.5   1.5   1.4   1.5   0.0
  4. AS???    mx01.Amsterdam.gldn  0.0%    10    3.3   2.2   1.8   3.9   0.7
  5. AS???    pe01.Vladivostok.gl  0.0%    10  148.6 148.6 148.4 148.8   0.1
  6. AS???    169.254.0.14         0.0%    10  149.5 149.8 149.5 150.0   0.2
  7. AS210756 gw.gcore.lu          0.0%    10  151.8 151.8 151.7 152.0   0.1

从上面的 mtr 报告中,假设我们对第一跳和第七跳的地理位置是已知的,我们可以得知第 2、3、6 跳的地理位置信息,我们可以看到第 5 跳已经是在海参崴了,第 7 跳也在海参崴,所以第 6 跳也应该在海参崴,第一跳在阿姆斯特丹,第 4 跳还在阿姆斯特丹,所以 2、3 跳也在阿姆斯特丹。

四、海底光缆推测法

这种方法通过登陆点去推测跨国后的落地跳可能在哪里,但是有一定的局限性,仅在有需要的时候辅助使用。

未来展望

很多朋友以为我开始维护自己的微型骨干网 IP 库以后 NextTrace 就会变得十分无敌,但是我想我的初衷没有太大改变,这个的骨干网库最多只能算上是微型的,也只是用来辅助 NextTrace 能够更好的展示地理位置信息使用,并非是去真的完整维护一整套骨干网库,那样对我来说成本实在太高。

我也没有任何让它用于商业用途的想法,如果你是为了追求更准的 IP 地理位置服务,不用多想,还是应该选择 IPIP 家的 BestTrace,作为一款商业公司的产品肯定要比开源项目要强大太多。

NextTrace 的定位就是给那些对热爱网络的朋友准备的一份真挚的礼物,但是我们也不欢迎一些用户将此类软件用在一些不合法合规的用途上,如果发现试图滥用我们服务的行为,必要时我们会采取一些极端措施,彻底切断对外服务。

Other

NextTrace 只是一个开源项目,它没有收到任何一方的赞助。我也更希望能有社区的力量去推动整个项目的良好发展,毕竟在未来我可能不再有那么多时间去全力支持项目的运转。如果您有意愿参与整个项目,请您务必发邮件告诉我,谢谢!

Leave a Comment

2 Comments
  1. 第一个方法倒也不是那么不可行,白嫖ipip的全球监测点资源就可以,他们的监测点还是很丰富的hhh https://tools.ipip.net/traceroute.php
    (话说大佬写得特别好的那篇骨干网介绍为什么知乎和这里都删掉了啊?

    1. Leo Leo

      @Zhouii其实 IPIP 的监测点早就有每日限制了,额度给的很少,每天测20次一般是上限,这不够用。

      而且 NextTrace 现在从一开始就是尽可能少使用 IPIP的数据集,防止产生一些版权问题,所以一般不会用 IPIP 家的服务来做校准,现在用的比较多的还是 Misaka 家的 ping.sx 。

      骨干网介绍那篇文章争议很大,一直有人来“指点江山”,给我带来了很多不必要的麻烦,所以还是直接删了省事。