Networking

换回了 Comcast

上回书 说到我换到了一个采用微波通讯技术的小型本地 ISP，然而经过将近两年的时间， 我最终还是换回了 Comcast。正如张师傅说的，南湾乡下的居民不配有好东西，经过这么久， 我家这边依然没有 5G 互联网服务，也没有光纤到府，至于 cable 也很自然地也没有 DOCSIS 4.0，也不想想看，您配吗？

为什么要换回 cable 呢？Sail 声称他们采用的设计可以避免雨季带来的干扰，事实来看确实是这样， 但是他们的服务稳定性在过去几个月出现了灾难性的下降，此外延迟由于一些未知的原因增加了不少。 我为此收集了一些数据，发现去大河以及 Google 的延迟有时竟然超过了 500ms，这个就实在是太难受了。

在本地架设根 DNS 的镜像

目的

在本地的局域网上建立 DNS 解析服务可以显著地改善 DNS 的安全性：所有的 DNS 查询将由可以信任的本地 DNS 解析服务进行验证， 而不是简单地相信一台不受控的远程服务器通过 UDP 提供的应答。因此，这些年来我自己的网络包括机房的网络都是自己运行一组 DNS 解析服务的。

自建权威 DNS 的利弊

TL;DR：我的观点是现时 (2023) 大多数人都不应该自建 DNS，而应该找一家比较可靠的供应商。

下面说说我的理由。

FreeBSD 上的 nginx kTLS 支持

昨天，FreeBSD 13.2 正式发布了。 kTLS 是在 FreeBSD 13.0 中由 Netflix 赞助的新功能， 过去，TLS/SSL 应用程序对于通讯内容的加解密通常是在用户态进行的，这样一来， 系统在读取出数据和发出数据之前需要进行额外的上下文切换，并在内核和用户地址空间之间来回复制缓冲区来满足加解密的需要。 有了 kTLS 之后，内核可以在 sendfile(2) 时直接在内核上下文中完成加密和填充到网络协议栈的操作，从而减少了上下文切换和不必要的复制操作。

TCP 协议合订本出了

我们现在所说的 TCP 协议通常是指 1981 年 9 月 发表的 RFC 793 和一系列后续 RFC 定义的协议，其主体定义距今已经超过 40 年了（当然如果细究下去的话， 第一份正式的文档是 RFC 675， 而 RFC 793 本身也是针对一年前的 RFC 761 的修正，不过大部分实现者使用的基础依然是 RFC 793）。

作弊条：SSH 的 ProxyJump 跳板服务

问题

有些环境中，SSH 服务器可能无法从 Internet 直接访问（例如，SSH 服务器可能使用的是一个私有 IP 地址，或是 Internet 服务提供商没有提供 IPv6 服务，而 SSH 服务器只提供 IPv6 服务）。

考虑到 SSH 已经进行了相互认证（连接时客户端会验证服务器的公钥是否与已知公钥，例如 ~/.ssh/known_hosts， 或是通过 DNSsec 发布的 SSHFP RR 匹配；服务器端则会验证用户是否能证明自己拥有与授权公钥对应的私钥）， 因此比较常见的解决方法便是使用 VPN、在防火墙上穿孔，或是使用代理服务器。

由于 SSH 自身也提供了许多转发功能，因此如果中间的跳板服务器也提供 SSH 服务， 便可以使用这些跳转服务器直接作为代理服务器来用。与前面那些传统方法相比， 这样做的优点是避免了安装额外的软件，也不需要特别指定端口。

用 BHyVe 虚拟机解决 FreeBSD Wi-Fi 驱动的问题

BHyVe

https://www.FreeBSD.org/ 10.0-RELEASE 起，系统提供了一个最早由 NetApp 开发的使用处理器提供的虚拟化硬件支持 (目前是 Intel VT 和 AMD-V；针对 ARM 平台的支持也在 https://reviews.freebsd.org/D26976) 的虚拟化环境 https://wiki.freebsd.org/bhyve，这套虚拟化环境可以运行支持 VirtIO 规范的各种操作系统，并提供了 UEFI 支持。

重建了 IPv6 隧道

之前 提到我换了一家ISP。这家ISP目前尚未提供IPv6服务，因此想要用IPv6的话就需要自己动手。 此前也有一些其他朋友问过我关于为什么一定要有 IPv6，毕竟 狼来了 的故事已经讲了这么多年， 而且 十几年前 IPv4 的中央地址池其实就已经用完了，只是在工业界抱残守缺^H^H^H^H食古不化^H^H^H^H我也不知道该管这种行为叫什么， 总之苟延残喘了十几年依然没有把服务迁移到 IPv6 上去，所以目前用 IPv6 往往也只是满足一下一些技术宅的恶趣味， 例如看 kame.net 那只能动的海龟之类。

当然，我自己用 IPv6 有一些更加现实的动力，比如我的一些服务是只在 IPv6 上提供的，这样做可以把那些做的不好的客户端直接排除在外， 有点类似于在当年我把网站的 TLSv1.2 和更早版本的 TLS/SSL 支持全都砍掉一样。

话说回来，由于新的 ISP 出于一些我不理解的原因死活不愿意支持 ping （唯一可能的解释是，这样做会导致扫描起来容易不少，毕竟扫描 IPv4 地址段比扫描 IPv6 地址段要容易太多了， 但安全不能建立在别人不知道的基础上，anyway，打电话、开票之后未能解决该问题），而大河的隧道服务又要求必须可以 ping 到终点，于是陷入了死循环。

新年，新ISP

我在美国的这几年，家里一直使用的是来自 Comcast 的各种基于 cable 的互联网服务。 关于 cable 的各种问题，多年以前 Extremely Decent 做过一个视频 The First Honest Cable Company 来吐槽。

简而言之，虽然谈不上有多好，但 Comcast 算是在湾区几个能用的 ISP 里比较靠谱的一个了。 贵厂十一年前宣布了 Google Fiber，然而由于种种原因我家这片地方一直都没有愿意提供光纤入户服务的 ISP。 比较新的小区，例如 yegle 同学所在的幸福屯地区则比较幸运， 类似 AT&T Fiber 之类的服务都比较容易获得。

作弊条: hAP ac 配置迁移

本文主要是作弊条，记录一下目前所做的事情，以备未来不时之需。

2017年的时候和 @yegle 团购了一批 Mikrotik hAP ac。 我当时主要的需求有：

• 支持多个VLAN和SSID，以便于隔离不同厂商的IoT设备，以及家里不同的计算机设备；
• 能够覆盖家里的不同区域；
• 漫游比较容易(并非刚需)；
• 硬件便于安装，需要可以挂在墙上，最好支持 PoE 供电。

认为比较无所谓的功能是：

• 图形界面(可有可无)；
• 路由功能(采用了一台基于 Atom C2758、7个千兆口的超微主板组装)；
• 云管理(减分项)。

具体实施中，我在家里是通过扁平的六类线缆以明线方式从路由器直接连到楼上。原本买了三台AP，但实际上只用了两台就实现了整栋建筑的覆盖。