IP地址--人们期待已久的问题

我年纪够大了，还能记得 HOSTS.TXT 以及域名系统的引入。

那是在那些日子里，你通过向加州发送一封礼貌的信，得到一封礼貌的信来获得B级网络，然后，几个月后，当 RFC1166 INTERNET NUMBERS 在每半年一次的打印RFC包中到达时，发现这封信打错了，并且您已经在136.172/16而不是136.173/16上配置了所有的欧洲议会1200计算机。

但事情并不简单，如果说有什么不同的话，那就是复杂得多，因为TCP/IP并不像今天那样，是唯一重要的协议。

除了TCP/IP，还有IBM的SNA、Digitals DecNet、ApolloRing、Banyan/Vines、Novell NetWare、X.21、X.25、X.75，以及整个CCITT-OSI-“智能网络”电信灾难从未开始。

这就是为什么DNS数据包具有 class 可设置为的字段 Hesiod 或 CHAOS 除了……之外 the Internet ：当时的想法是，所有不同的协议都会有一个编号，我们将有“一个目录来统治所有协议”。

在很大程度上正因为如此，设计了一种新的、与协议无关的查找函数： getaddrinfo(3) 和 getnameinfo(3) 当然，对于IP来说，它们应该是向后兼容的，因为有 thousands 用户数量已经很多了。

这就是为什么 telnet 80.1440 尝试连接到 80.0.5.160 ，为什么？ ping 0x7f000001 vbl.成为 127.0.0.1 和 0127.0.0.1 vbl.成为 87.0.0.1 。

如果您阅读的手册页 getaddrinfo(3) 你会发现它并没有告诉你这一点，它只是说了它 conforms to IEEE Std 1001 。

但在1990年，每个人都知道那是什么，而且没有人有防火墙，因为Cheswick和Bellowins的书 Firewalls and Internet Security 直到1994年才出版，所以不用担心？

就像《为未来而设计》经常出现的情况一样， getaddrinfo(3) Api立即僵化，在‘unix™战争’中被冷冻射线击中。

这就是为什么当IPv4数字开始看起来像一个有限的资源，旧的A、B和C类网络被分解成任意大小的无类域间路由或“CIDR”网络掩码时，getaddrinfo(3)不能将“192.168.61/23”转换为有用的东西。

我相信也有一些小人国的争论，关于 192.168.61 会回来 192.168.0.61 保持向后兼容，而 192.168.61/23 会回来 192.168.61.0 + 255.255.254.0 。

正因为如此，Varnish使用 getaddrinfo(3) 无处不在，只有一个地方：解析VCL中的ACL规范。首先，我们必须使用自己的解析器来检查它是否是CIDR条目，如果不是，我们会询问 getaddrinfo(3) 。

之所以会这样大喊大叫，是因为有人注意到 ping 0127.0.0.1 没有去过 127.0.0.1 正如他们所料。

这已经变成了CVE-2021-29418和CVE-2021-28918，一旦CVE战利品猎人进城，可能还会有十几个。

所有IP编号字符串从信任点输入Varnish，或者作为命令行参数 (-a ， -b ， -M 等)，在VCL源代码中 (backend ， acl 等)或者作为来自Varnish前面的TLS剥离器的PROXYv1报头字符串。

当然，VCL几乎允许您做任何事情，包括：

if (std.ip(req.http.trustme) ~ important_acl) {
     ...
}

如果你做了这样的事情，你可能想要a)考虑信任陌生人IP#‘S的智慧，b)考虑这个“关键的网络掩码问题”。

否则，我不认为这个新的“关键网络掩码问题”会导致Varnish中的任何源代码更改。

如果和当各种类Unix操作系统，并烟雾弥漫的“严肃的Unix行业”，(IEEE？奥斯汀集团？开放小组？无论他们现在叫什么)把他们的行动集中起来，翻新 getaddrinfo(3) API，Varnish会自动拾取并使用它。

他们是否应该在灵光一闪的时候，也做出 getaddrinfo(3) 对于解析我们在1993年得到的这些新奇的CIDR地址很有用，我将非常乐意放弃 vcc_acl_try_netnotation() 也是。

直到下一次，

保尔-亨宁，2021-03-30