IPv4 开始收费!新的 IT 灾难?

目前的情况实在糟糕。我们要么向云服务商付更多的钱,要么坐视自己的网络服务崩溃。

最近一段时间,新闻头条总会时不时提起 IP 地址。AWS 宣布要对每个 IPv4 地址每小时收费 0.005 美元,其他云服务商也纷纷行动,宣称要对公共 IPv4 这种“奢侈品”开价。Google Cloud Platform 开出的价格是 0.004 美元,跟 Azure 和 Hetzner 的每小时 0.001 欧元基本相当。很明显,云服务商自己掏钱购买 IPv4 地址空间的时代即将结束。随着时间推移,当这些地址越来越有价值,想要免费使用自然也就不可能了。

面对这样的压力,我们当然应该赶快切换到 IPv6。其实我第一次听说 IPv6 这东西,是在高中的第一堂思科技术课上。而现在我已经 36 岁了,大家可以想象当时老师说的“即将到来”究竟来得有多慢。到目前为止,我在 IPv6 方面还没做过多少实际工作,毕竟市场对此类技能的需求实在不旺。而且从业经历也还算丰富的我可以证明,没有任何一家雇主会认真强调 IPv6 方面的技能需求。所以我压根就没学,只能说很遗憾错过了这场网络领域的巨大变革和进步。

种一棵树最好的时间是十年前,其次是现在。学习 IPv6 当然也是如此,所以我打算试着把自己的博客迁移到 IPv6。我会继续把它放在 CDN 后面来处理 IPv4 流量,但无论如何,这个重要的历史时刻终于来临了!但我惊恐地发现,关于 IPv6 的一切几乎都没法开箱即用。主要依赖项会立即停止运行,而解决方案也很难称得上“生产就绪”。即使是人员充足的技术团队,在处理 IPv6 迁移过程时也是异常艰难,毕竟几乎没人在这方面的实践经验。我们多年来都忽略了这个问题,而现在是时候付出代价了。

有必要折腾 IPv6 吗?

当然有,但受篇幅所限,本文就不具体论述 IPv4 和 IPv6 的优劣了。网上这类文章很多,大家酌情参考。下面,我简要介绍一下为什么要转向 IPv6。

IPv4 开始收费!新的 IT 灾难?

IPv6 数据包标头示例

  • 地址空间
  • 标头字段数量较少(仅占为 8 个,IPv4 上是 13 个)

IPv4 开始收费!新的 IT 灾难?

  • 处理速度更快:不再需要校验和,所以路由器不必对每个数据包进行重新计算。
  • 路由速度更快:包含更多汇总路由和分层路由。(看不懂?没关系,汇总路由 = 将多个 IP 组合起来,这样就不需要处理所有地址,而仅仅只要根据地址开头部分的大致方向前进就行。路由也是如此,毕竟 IPv6 是我们唯一能够使用的小型、高效主干路由。)
  • QoS:Traffic Class 和 Flow Label 两个字段,让 QoS 更轻松。
  • 自动寻址。允许 IPv6 主机在局域网上无需路由器或 DHCP 服务器即可实现连接。
  • 可以使用 Authentication 标头和封装安全负载将 IPsec 添加至 IPv6。

最后,也是最重要的一点:IPv6 地址是免费的,但 IPv4 地址却要付钱

设置仅支持 IPv6 的服务器

其实具体设置过程非常简单。我配置了一台 Debian 设备并选择了“IPv6”,接下来第一个“惊喜”就出现了。这台设备没能获得 IPv6 地址。我只得到了一条 /64 地址,也就是 18,446,744,073,709,551,616。但好消息是,我的小型 ARM 服务器可以通过扩展,在所有公共地址上运行我之前工作过的每家公司的网络基础设施。

这看似有点浪费,但理解了 IPv6 的工作原理之后,大家会发现事实并非如此。因为 IPv6 比 IPv4 多得多,所以就算在网络上设置 1 万台主机也没问题。所以哪怕乍看上去有点浪费,保留所有 IPv6 空间也有其实际意义。所以,用不着考虑有多少地址被发送给了每台设备。

重要提示:控制住自己优化地址利用率的冲动。在跟经验丰富的网络专家交流时,我发现很多人都容易掉进优化地址的坑里。我们都花过很多时间考虑 IPv4 地址块里还剩多少空间,并围绕这个问题搞设计。但在 IPv6 中这个问题根本就不存在,/64 前缀就是我们应在接口上配置的最小前缀。

如果非要使用较小的前缀(有人确实尝试过),比如用 /68 或者 /96,可能会破坏无状态地址的自动配置。在心态上,我们应当将各个站点配置为 /48,这也是地区互联网注册管理机构在分配 IPv6 时的默认设定。而在设计网络组织时,则应考虑半字节边界——这可不是胡说八道,简单来讲,这就是一种让 IPv6 更易于阅读的形式。

假设我们要使用 2402:9400:10::/48,如果希望每台设备只使用 /64 作为平面网络结构,则可按如下方式进行划分:

IPv4 开始收费!新的 IT 灾难?

而 /52 的情况也差不多。

IPv4 开始收费!新的 IT 灾难?

这样,我们就能一目了然看到自己正在查看哪个子网。

好了,现在设备已经准备就绪,接下来做点常规服务器设置操作。

问题 1:我没法通过 SSH 登录

其实这个问题完全可以预见。我的工作或家庭 ISP 都不支持 IPv6,所以我才需要设置自己的服务器,但现在却完全不起作用。好吧,我只能附加一个 IPv4 地址,通过 SSH 登录,再设置 cloudflared 来运行隧道。想必系统会自行处理其中的转换工作。

但 Cloudflare 显然没考虑到这种用法。所以当我删除 IPv4 地址时,隧道意外崩溃了。默认情况下,cloudflared 实用程序使用的是 IPv4,我们需要单独编辑 systemd 服务文件以添加:-edge-ip-version 6。完成之后隧道才能正常启动,我也可以通过 SSH 顺利登录了。

问题 2:没法使用 GitHub

现在我的小服务器已经开始运行,接下来该做具体设置了。我运行了自己的服务器设置脚本,但立马就报错了。它会尝试访问 history 的安装脚本,这是款很棒的 shell 历史记录实用程序,我在自己的所有计算设备上都会用它。它尝试从 GitHub 提取安装文件,但失败了。“这不对吧,GitHub 难道不支持 IPv6 吗?”

确实不支持。这简直让人心态爆炸,支撑整个互联网的软件发布服务居然不能兼容 IPv6……但也难怪,现在微软的心思全都放在人工智能身上,哪有功夫管你什么 GitHub 和 IPv6。最终,我选择使用 TransIP GitHub 代理,效果很好。现在我可以正常访问 GitHub 了。但随后 Python 也报错,显示 urllib.error.URLError:。好吧,我选择放弃。我猜是 Debian 中的 Python 3 版本不兼容 IPv6,但我现在实在没那个心情做故障排查。

问题 3:无法设置 Datadog

接下来是一些基本操作。我想设置 Datadog 来监控这台服务器的运行,其实关注的指标并不多,只是一些历史负载数字。我转向 Datadog,登录并开始执行设置,但它立刻就崩溃了。我运行 curl -L https://s3.amazonaws.com/dd-agent/scripts/install_script_agent7.sh 来实现这个简单设置,而且人家 S3 已经支持 IPv6 了,这到底是哪出的错?

curl -v https://s3.amazonaws.com/dd-agent/scripts/install_script_agent7.sh*   Trying [64:ff9b::34d9:8430]:443...*   Trying 52.216.133.245:443...* Immediate connect fail for 52.216.133.245: Network is unreachable*   Trying 54.231.138.48:443...* Immediate connect fail for 54.231.138.48: Network is unreachable*   Trying 52.217.96.222:443...* Immediate connect fail for 52.217.96.222: Network is unreachable*   Trying 52.216.152.62:443...* Immediate connect fail for 52.216.152.62: Network is unreachable*   Trying 54.231.229.16:443...* Immediate connect fail for 54.231.229.16: Network is unreachable*   Trying 52.216.210.200:443...* Immediate connect fail for 52.216.210.200: Network is unreachable*   Trying 52.217.89.94:443...* Immediate connect fail for 52.217.89.94: Network is unreachable*   Trying 52.216.205.173:443...* Immediate connect fail for 52.216.205.173: Network is unreachable

问题不在 S3 或者我的服务器上,因为我可以正常使用 AWS 提供的 S3 存储桶连接测试。

curl -v  http://s3.dualstack.us-west-2.amazonaws.com/*   Trying [2600:1fa0:40bf:a809:345c:d3f8::]:80...* Connected to s3.dualstack.us-west-2.amazonaws.com (2600:1fa0:40bf:a809:345c:d3f8::) port 80 (#0)> GET / HTTP/1.1> Host: s3.dualstack.us-west-2.amazonaws.com> User-Agent: curl/7.88.1> Accept: */*>< HTTP/1.1 307 Temporary Redirect< x-amz-id-2: r1WAG/NYpaggrPl3Oja4SG1CrcBZ+1RIpYKivAiIhiICtfwiItTgLfm6McPXXJpKWeM848YWvOQ=< x-amz-request-id: BPCVA8T6SZMTB3EF< Date: Tue, 01 Aug 2023 10:31:27 GMT< Location: https://aws.amazon.com/s3/< Server: AmazonS3< Content-Length: 0<* Connection #0 to host s3.dualstack.us-west-2.amazonaws.com left intact

好吧,我打算通过 apt 手动进行设置。

0% [Connecting to apt.datadoghq.com (18.66.192.22)]

他奶奶的……行,Datadog 你滚吧。到这个时候,我终于意识到纯使用 IPv6 根本没有前途。如果不上代理和技术补丁,那原本简单的几乎一切组件都会跟我闹别扭。所以接下来我会尽可能使用 IPv6,但同样辅以 IPv4。

NAT64

为了从 IPv6 访问 IPv4 资源,我们需要借助 NAT64 服务。我最终用的是 https://nat64.net/。漂亮!所有问题几乎立刻消失,我能够正常访问各种资源了。我其实有点担心,毕竟这只是个业余项目,靠它来接入所有关键互联网资源到底行不行啊?但 IPv6 的兼容性问题实在太多,可行的选项又相当有限,所以我只能祈祷 NAT64 别耍流氓了。

我甚至惊讶于目前能够选择的方案居然如此有限。以下就是我能找到的最佳工具列表:

IPv4 开始收费!新的 IT 灾难?

其中大多数工具似乎已经失效。Dresel 链接无法工作,Trex 在测试中出现了问题,August Internet 彻底消失,大多数 Go5lab 测试设备离线。Tuxis 倒是可以工作,但在 2019 年推出之后似乎就没升级过。基本上,Kasper Dupont 似乎是互联网上唯一愿意继续支持 IPv6 的技术人。抱拳了,Kasper~

更直白地讲,Kasper 相当于是在用一臂之力支撑整个 IPv6 互联网

Kasper Dupont

到时这里,我对 Kasper 不禁心生好奇,并给他发邮件提了几个问题。这位老兄也热心给出了回复。

我:我发现公共 NAT64 服务非常有用,你为什么会一直坚持维护这个项目呢?

Kasper:我这么做,主要是想推动 Ipv6 继续发展。有那么几年,我打算在家里搭建纯 IPv6 网络,并发现 DNS64 加 NAT64 的实际表现相当出色。我想让更多人也能有机会用上。在发布第一个 NAT64 网关时,它只是推广 NAT64 扩展的概念验证项目。NAT64 就这样延续了下来,没有太多复杂的故事。

几个月前,我终于在家里用上了原生 IPv6。所以现在,我可以用更类似自己当初的方式帮助目标用户解决问题。

我:NAT64 几乎是互联网上仅存的少数此类免费公共服务之一。能不能聊聊你为什么坚持了下来,这服务的运行成本是多少,总之多跟我说说具体情况吧。

Kasper:这是款个人产品,所以我在不同的地方一共用到七家虚拟机托管服务商。有些是从 Hetzner 购买的,价格是每月 4.51 欧元:https://hetzner.cloud/?ref=fFum6YUDlpJz 其他虚拟机要贵一点,但贵得不多。

在这些虚拟机中,有 4 个用于 NAT64 服务,其他则用于别的 IPv6 过渡相关服务。比如我自己也在其中一个虚拟机上运行这项服务:http://v4-frontend.netiter.com/

我希望以后能跟托管商达成协议,提高服务容量并把它变成能赚钱的业务,这样我就可以全职从事 IPv6 相关工作了。但目前我仅仅是拿出点个人时间鼓捣。我的目标是让纯 IPv4 内容提供商以传输带宽成本的方式支付这部分费用。

我:有没有愿意分享的其他技术细节呢?

Kasper:当然可以,只是这些技术细节可能有点复杂。

我觉得自己这项服务跟其他服务的主要区别,在于我的每个 DNS64 服务器都会自动根据所有网关的健康检查通过 NAT64 前缀进行更新。也就是说,任何单一 NAT64 网关的中断,基本都不会对用户体验造成影响。这对维护也有帮助。在我看来,这可能是 NAT64 服务在同类公共服务中获得认可的核心原因。

NAT64 服务的代码也完全由我自己开发而成,目前作为 Linux 上用户模式的守护进程。我正在考虑把大部分性能关键部分移植成内核模块。

我的网站

好了,到这里我已经介绍完毕、网站也开始运行了。为了通过 IPv6 拉取 docker 容器,我们需要在镜像名称前添加 registry.ipv6.docker.com/library/ 。例如:image: mysql:8.0 会变成 image: registry.ipv6.docker.com/library/mysql:8.0

Docker 会警告说此设置尚未达到生产就绪状态。我不太确定 Docker 想提醒什么,毕竟如果它停止运行,拉取操作照常执行也就可以了吧?

完成之后,我把自己这个网站设置为 AAA DNS 记录,并允许 Cloudflare 进行代理。也就是说,它们会处理 IPv6 的广告并将流量引向这里。我还做了另一项修改:之前我使用的是 Caddy Web 服务器,但因为现在大部分流量都转移到了 Cloudflare 这边来,所以我决定改用 Nginx。毕竟当主要流量都来自 Cloudflare,那自然得相应调整 SSL 的工作方式。

现在,我已经把 Cloudflare 的原始证书硬加载到了 Nginx 当中,同时设置了经过身份验证的源拉取,这样就可以确定所有流量均通过 Cloudflare 运行。该证书的签名有效期为 15 年,所以我可以放心把它保留在自己的 secret 管理系统当中、不再分心打理。好了,现在我的网站已经重新上线并正常运行。是的,你眼前看到的这篇内容,就是系统能够顺畅工作的最好证明。

尚未解决的问题

我的容器仍无法与 IPv4 资源通信,就算位于具有 IPv6 网桥的 IPv6 网络上也不行。DNS64 解析能正常工作,而且我已经把 fixed-cidr-v6 添加到了 Docker 当中。我可以跟 IPv6 资源正常通信,但 NAT64 转换过程却不起作用。之后我会继续研究可行的办法。

有些朋友可能想 ping 一下试试,但我在添加 NAT 时用到了 ip6tables。

SMTP 服务器问题。我还没找到拥有 AAAA 记录的商用 SMTP 服务。Mailgun 和 SES 都不行,我试过的其他一些小服务也宣告失败。即使 Fastmail 也帮不上忙。

为什么不继续使用 IPv4?

这里咱们先不扯地址不够用之类的闲话。如果能早一点尝试推广 IPv6,那我们的网络基础设施建设方式可能将完全不同。企业之所以经常用到负载均衡器和隧道等技术,并不是真的有什么硬性功能需求,而是希望在私有 IP 范围和公共 IP 地址之间做出某种逻辑划分,并将其保留在 DNS A 记录当中。

如果具体把负载均衡器拆开来看,它其实只负责两项工作。首先将传入的数据包分发到后端服务器上,之后检查这些服务器的运行状态并将不健康的服务器从轮换中剔除。当然,现在很多人也在用负载均衡器处理 SSL 终止和指标等事务,但这些并不是负载均衡器设计上的必要功能。负载均衡有多种实现方式,最常见的包括:

  • 连接请求轮询。
  • 不同服务器的加权轮询。
  • 最少连接原则,即连接数最少的服务器会收到更多请求。
  • 加权最少连接,跟上一条类似,但也可以设置更多倾向性。

大家应该注意到了,跟公共 IP 地址相比,私有 IP 地址完全用不上这些功能。从计算角度看,将主机配置为仅接受某一个来源(负载均衡器)的流量只是更简单也相对更便宜。但出于这个目标,我们被迫在基础设施层面做出大量设计,例如 VPC、NAT 网关、公共子网和私有子网等等,其实这些原本都没必要、至少不用像现在这么重要。

更讽刺的是,IP 白名单目前是种并不完善的安全实践。它最大的问题就是浪费时间,因为我们使用的都是云服务商所拥有的 IP 地址。但面向未来,IP 的名单的存在仍然意义重大,因为企业会随需求增加而自行购买 /44,包括从美国互联网号码注册机构(ARIN)、Réseaux IP Européens 欧洲网络协调中心(RIPE)或者亚太网络信息中心(APNIC)购买一组 IP。

这样,我们就永远不需要担心“谷歌会不会再多买点 IP 地址”或者“我得关注 GitHub 的支持页面,确保他们不会添加更多 IP 地址”。未来我们将拥有自己的 IP 地址块,在使用期限之内随意用于整个业务体系。容器系统不需要在每个主机上分配内部 IP 地址,因为有公共 IP 地址块可供使用,需要时还能通过标准公共 DNS 轻松发布通告。

当然,我不是说专用网络不好。我的意思是,我们采用的很多网络设计并非出于硬性需求,反而是被“绑架”的设计产物。我猜测未来的应用程序会更多对接开放互联网,而不再完全依赖于私有 VPC 的安全保障。考虑到安全漏洞的基本原理,这样的设计可能更有益于整体安全。

所以,使大家根本不关心成本和可用性问题,那让组织更多掌握网络功能的所有权和控制权,也必将带来可以量化的巨大价值。

这一切,会好起来吗?

总之,目前的情况实在糟糕。我们要么向云服务商付更多的钱,要么坐视自己的网络服务崩溃。希望那些不想付钱的朋友们能继续推动 IPv6 的普及,但遗憾的是我们居然花了这么多年才达到如今的水平。所有这些问题本来可以逐步解决,但在掌握资源的团队做出实际行动之前,很多朋友心里恐怕还是有个大大的问号。

我真心希望最终结果能更好一些,至少应该给那些希望永久掌握自己 IP 范围的小公司一点机会。而且随着 IPv6 逐步成为主流,也希望它的使用门槛能变得更低一些。反正目前的现状就是两个字:糟糕,出奇的糟糕。

如果你经营着一家小公司,又不想额外花钱使用 IP 地址,那当下唯一的办法就是多留点时间:各位将有无数问题需要解决

声明:本站所有文章,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。

给TA打赏
共{{data.count}}人
人已打赏
相关知识

购买服务器为什么选择大厂而不选择小商家?

2023-3-2 12:04:02

MacCMS

苹果CMS仿T5资源站影视资源分享网站模板

2022-12-23 15:33:23

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索