能否将国家代码和ASN结合处理网段信息？
Opened this issue · 11 comments
你好！我在做类似的研究，旨在优化梯子的选路规则，然后搜索看到了这个项目，十分棒的想法！对我帮助很大。同时我也希望交流分享一下思路，或许这有点用。同时我也在尝试将这个项目生成的路由表引入到我的方案中，由于这个项目生成的路由表并不大，叠加之后不会增加太多路由条目，所以似乎效果不错。
首先我是个网工而不是程序员，也看不懂代码(抱歉)，我的关注点是在被墙掉的服务和一些容易被重点照顾的CDN(例如akamai)，将这些IP段指向梯子的隧道接口，就可以实现大部分的被墙服务翻墙，剩下的走本地默认路由。这个想法很久之前有人提过（例如“是否存在GFW的黑名单IP”一类的话题），但由于被墙地址池经常变动且不容易验证等等多数原因，这个并不好实现。
我的思路是，被墙的公司（eg. Google, Facebook, Twitter etc.）的公司往往拥有自己的ASN，通过 bgp.he.net 网站或者类似服务可以查到该公司的ASN以及所宣告的prefix。
例如Google：
https://bgp.he.net/irr/as-set/AS-GOOGLE
在其prefixes v4中，可以获取其宣告的网段，其中连续的网段可以聚合成一个更大的网段，例如 AS36492 ：
| Prefix | Description |
|---|---|
| 64.9.224.0/24 | Google, Inc. |
| 64.9.225.0/24 | Google, Inc. |
| 64.9.236.0/22 | Google, Inc. |
| 64.9.240.0/24 | Google, Inc. |
| 64.9.241.0/24 | Google, Inc. |
| 64.9.242.0/24 | Google, Inc. |
| 64.9.243.0/24 | Google, Inc. |
| 64.9.244.0/22 | Google, Inc. |
| 64.9.248.0/22 | Google, Inc. |
| 64.9.252.0/22 | Google, Inc. |
| 192.119.28.0/24 | Google Fiber Inc. |
都是连续的，可以聚合成
64.9.224.0/19
192.119.28.0/24
又如另一种情况，大的网段包含小的段，只需要保留最大的段：
| Prefix | Description |
|---|---|
| 172.217.0.0/16 | |
| 172.217.0.0/24 | Google Inc. |
| 172.217.16.0/24 | Google Inc. |
| 172.217.24.0/24 | Google Inc. |
| 172.217.28.0/24 | Google Inc. |
| 172.217.30.0/24 | Google Inc. |
| 172.253.0.0/16 | |
| 173.194.0.0/16 | American Registry for Internet Numbers |
| 173.194.7.0/24 | American Registry for Internet Numbers |
| 173.194.32.0/24 | This network range is not allocated to APNIC. |
得到：
172.217.0.0/16
172.253.0.0/16
173.194.0.0/16
经过这样处理，AS-GOOGLE所有路由条目被简化到76条，Google这已经算多了，Facebook只有14条，Twitter只有11条... 属于比较容易接受的范围。
由于BGP表的大网段比较少变动且数量不算太大（我个人整理的常见的服务加起来不到300条）所以可以用静态路由的方式在国外的一台VPS上引入，并将其指向VPS的网关，这对VPS来说没有任何意义，因为与VPS的默认路由的下一跳相同。然后与国内的路由器建立隧道，并在隧道之上运行OSPF协议。之后通过将静态路由引入OSPF的方式，将这些网段信息传递给国内的路由器，这些没什么意义的静态路由就会发挥作用了，因为根据子网掩码匹配原则，这些路由会优先匹配到，并从interface tunnel出去。
这样也有缺点，有一些托管的网站或者论坛被墙了，但并不属于某个公司(eg. igfw.net ; hkgolden)之类的，如果解析出地址之后加静态路由，这网段又太小不划算，而且也增加了管理难度，所以我考虑将这个项目生成的路由表也加进来。
之后我将你的bestroutetb生成的vpn路由表也转为静态路由的方式加入到国外的VPS上，再将net路由表加到国内路由器上。叠加之后的效果是，目的IP匹配到了你的vpn路由表或者我的路由表，都会从int tun出去，大大减少了漏网之鱼。但实际上我也发现，这个叠加后的路由表还可以继续压缩，因为有大量重叠的部分。以及同时也存在问题，那就是OSPF协议与静态路由协议的协议优先级不对等，如果匹配到了国内静态路由，那么OSPF学习到的相同掩码长度的条目就无效了，虽然这种情况比较少。
抱歉自说自话了这么多，大致来说，就是你的关注点在国家代码而我的关注点是ASN，但这应该都可以用于分类IP，然后应用bestroutetb算法。然后我的问题是，我要如何将我整理到的IP段，跟你数据库中的US,HK,JP,GB等等合并在一起，最后进行一次运算，得到最简化的VPN路由表。
看过说明文档之后，我留意到本身可以在参数中携带我需要特别指定的subnet，但量比较多的话在bash里加参数可能就不太好用了。感觉上我似乎可以根据你的数据库的格式再写一份包含我自己地址段的文件，然后合并进去。但因为我不是程序员，所以要看懂里面这个程序怎么运作的大概还需要些时间...
最后是一个提议，是否有办法可以根据ASN或者AS-SET抓取一份prefixes数据，并将其以参数的形式跟国家代码一起使用，例如 --route.net=CN --route.vpn=US,JP,GB,HK,AS-GOOGLE,AS13414,AS35995 这样，这样Google和Twitter的地址就会一起参与运算，然后像是一些新加坡节点的个别地址也不会被落下。
当然这只是一个提议， 我自己并不知道要如何用程序代码从BGP中抓取Prefixes，也不知道要如何转换处理这类数据，因为不懂写程序... 如果你觉得这个提议有价值的话，可以考虑下添加这个功能....
或者有什么更好的想法或方法，也可以交流下。
感谢！
我觉得加入AS支持的想法很好，这应该可以方便bestroutetb的使用。
https://bgp.he.net/irr/as-set/AS-GOOGLE 现在不能访问，这里的数据是如何访问的？ARIN和其他NIC都只提供了ASN查询，如何找到对应的网段？
对于后边的问题，你可以直接插入网段到参数里：
--route.net=CN --route.vpn=US,JP,GB,HK,64.9.224.0/24,172.217.0.0/24
虽然不如提议中的方便，但是这个功能现在就已经支持了：）
http://bgp.he.net/irr/as-set/AS-GOOGLE
不知道为什么现在加了https就不行了，去掉https之后用梯子就可以访问了
bgp.he.net 提供的数据很直观，但因为是网页所以不太方便提取（至少我不会....）
另外我想到的一个是 routeview project ， http://www.routeviews.org ，这个网站可以从一些开放的router上面提取全球的现网运行态的bgp数据，但这个项目我还没深入研究，这个项目支持使用命令采集bgp数据，但如何采集、如何解析数据这个我还没去尝试。
前两天折腾的时候也在考虑这个问题，主要问题在于，不知道哪里可以用脚本爬 ASN 与 ip 段的映射关系。不过我只有日本和美国两个出口，所以只是特殊处理了一下 Google 全部走日本。
这个似乎可以解决查询问题：https://github.com/RIPE-NCC/whois/wiki/WHOIS-REST-API
大概有现成的package可以用。
$ whois -h whois.radb.net '!gAS12345'
A47
212.47.32.0/19 199.233.58.0/24 199.233.59.0/24
Chttps://iptoasn.com
我试着在 lib/db.js 加一个此网站数据的解析器应该就能满足需要，
更贴近现有的下载 RIR 全表再做处理的逻辑，工作量应该很小。
Arnie97@67d3e91 改了个支持 ASN 的版本，大家可以拿去试用了。由于只下载了一个做了压缩、只有 IPv4 地址的数据库，比原版下载速度更快些。但是由于不知道 Node.js 怎么获取 gz 解压后的大小，把进度条改坏了。
$ ./cli.js --update --route.vpn US,13414,35995 --route.net CN,4134,4808,4837,HK,9808 -p iproute -vfo .
下一步计划把 multi-gateway 的支持 pick 过来，这样才能充分利用 AS 分流，实现 BGP 的效果。
发现一些 bad case，我再找找有没有更准确可靠的数据源。
比方说 118.31.180.41/17（www.cnblogs.com，AS37963 阿里云）被我的 fork 判断为 AS4713 NTT，到国外绕了一大圈。
迫于 tcp reset, 我又来填坑了，哈哈。
Arnie97@00f5ff4 这次是直接用的五大注册局（:D 原来是不是漏了其中最没有存在感的一个）官方数据，质量应该有保障
是否有必要把 byASN 从 byCountry 里分出来用另一个 json key？我准备提 PR 了
迫于 tcp reset, 我又来填坑了，哈哈。
Arnie97@00f5ff4 这次是直接用的五大注册局（:D 原来是不是漏了其中最没有存在感的一个）官方数据，质量应该有保障
是否有必要把 byASN 从 byCountry 里分出来用另一个 json key？我准备提 PR 了
直接 byASN 的可用性不强，还是需要一个可以用名称反向查询的工具。
另外，根据 https://www.apnic.net/about-apnic/corporate-documents/documents/resource-guidelines/rir-statistics-exchange-format/ extension 字段没有约束格式，所以你的写法存在潜在的可用性风险