continuation

[continuation]

chroot bind9

FreeBSD

过程非常简单。比如主配置目录位于 /usr/local/etc/namedb，向 rc.conf(5) 添加：

named_chrootdir="/var/named" named_chroot_autoupdate="YES"

start 的时候，rc 脚本会自动完成 chroot 目录准备、转移配置文件、设置符号链接并启动 named(8)。

Debian

参照 wiki。

启动参数我没有在 ExecStart 的基础上���，而是放在了 /etc/default/named 的 OPTIONS 里面：

# startup options for the server OPTIONS="-u bind -t /var/bind9/chroot"

一个小问题是 systemctl start named.service 会停住然后红字报错，但服务其实已经正常启动。

原因和解决

默认安装的 bind9 对应 unit 里面有这样一句：

[Service] Type=notify

Wiki 没有明确提到 notify socket 要怎么设置（因此新 root 里面缺失）。以下参考 unbound 先例，准备好：

touch /var/bind9/chroot/run/systemd/notify

再加入这两句

ExecStartPre=-/usr/bin/mount --bind /run/systemd/notify /var/bind9/chroot/run/systemd/notify ExecStopPost=-/usr/bin/umount /var/bind9/chroot/run/systemd/notify

如此，服务应可以正常启动和停止了。

[continuation]

抢答：ssh(1) 登录一台机器以后 pgrep ssh 输出什么结果？

如果操作系统恰好是 FreeBSD，其中一种常见的情况是没有任何输出，即便使用 pgrep -lf 得到的结果相同。

从 FreeBSD 7.3-RELEASE 起，pgrep(1) 默认不含“祖先”进程，正因为具有如下结构：

|-- sshd: /usr/sbin/sshd [listener] 0 of 10-100 startups (sshd) | `-- sshd: user [priv] (sshd) | `-- sshd: user@pts/0 (sshd) | `-- -csh (csh) | `-- pgrep ...

……从而导致无法“找到” sshd(8) 对应的进程。解决方法：

-a Include process ancestors in the match list. By default, the current pgrep or pkill process and all of its ancestors are excluded (unless -v is used).

我还整理了一个��较好记的参数组合：

$ pgrep -fail sshd 70025 sshd: user@pts/0 900 sshd: /usr/sbin/sshd [listener] 0 of 10-100 startups 70023 sshd: user [priv]

用户层面工具的区别……

FreeBSD: "The pkill and pgrep utilities first appeared in NetBSD 1.6. They are modelled after utilities of the same name that appeared in Sun Solaris 7. They made their first appearance in FreeBSD 5.3.", FreeBSD 7.3-RELEASE Release Notes, commit;

NetBSD: "pkill and pgrep first appeared in NetBSD 1.6. They are modelled after utilities of the same name that appeared in Sun Solaris 7.", man;

OpenBSD: "pkill and pgrep first appeared in OpenBSD 3.5. They are modelled after utilities of the same name that appeared in Sun Solaris 7.", man;

procps-ng: man，类似 FreeBSD 的行为对应于 -A, --ignore-ancestors 参数, commit.

[continuation]

FreeBSD 13.1/BBR/KTLS

内核定制

找一个高配机器编译内核，我这里恰好有台 FreeBSD 12.3。

git clone --branch releng/13.1 下来一定要先 make buildworld，用比如 -j64 加速。 根据 lightsail 最低配的 GENERIC dmesg，内核配置 device 几乎可以全删，最重要是留下 Bus、基础 IO 和 Xen 相关的行，options 按需修改（GEOM_LABEL不能删、要用到 KTLS 的话也不能删）。当然如果还想压缩时间，可以把 Wi-Fi、ZFS、蓝牙什么的都配在 src.conf 里面。

如果用到某些 Go 写的工具，一定要留着（我把其余的COMPAT都删了）：

options COMPAT_FREEBSD11 # Compatible with FreeBSD11 options COMPAT_FREEBSD12 # Compatible with FreeBSD12

不然 Go runtime 会报错：

runtime: kevent failed with 78 fatal error: runtime: kevent failed goroutine 1 [running, locked to thread]: runtime.throw({0x1098263?, 0xc000119798?}) runtime/panic.go:1047 +0x5d fp=0xc000119740 sp=0xc000119710 pc=0x436b3d runtime.netpollinit()

FreeBSD 12.0 or later requires a kernel with the COMPAT_FREEBSD11 option set

FreeBSD 13.0+ will require a kernel with the COMPAT_FREEBSD12 option set

加入 BBR 相关配置

makeoptions WITH_EXTRA_TCP_STACKS=1 options TCPHPTS options RATELIMIT # TX rate limiting support 可加可不加，主要看硬件支持

安装启用新内核

继续 buildkernel，计时 118 秒结束之后 installkernel KODIR=/boot/kernel.lightsail；接着把内核打包搬到 lightsail 实例上。比如 tar -C /boot -xjvf kernel.lightsail.tbz，如此这般压缩、scp、然后解压。

顺便看了下，改出来的 kernel 只有 8m 左右。

# reboot -k /boot/kernel.lightsail

GENERIC 仍旧位于 /boot/kernel，boot 起不来直接强制去 Web 控制台上重启即可，应该不至于要走到重建实例这一步。

BBR 设置

启动完毕加载 tcp_bbr、设置 functions_default。tcp.cc.algorithm 可以留着 newreno，或者改成 htcp，我暂时没搞清楚这个和新版 tcp stack 混用的效果。

nginx + KTLS

版本：

nginx version: nginx/1.22.0 built with OpenSSL 1.1.1o-freebsd 3 May 2022

FreeBSD 13.1 已经默认对 base 的 OpenSSL 和内核全面开启了 KTLS，用 pkg 安装的 nginx 也不用自己重新折腾。

# kldload ktls_ocf.ko # sysctl kern.ipc.tls.enable=1

nginx.conf 里面加上：

ssl_conf_command Options KTLS;

这篇文章可谓是“成也萧何败也萧何”，当时用这个方法正确，但是现在（只对 FreeBSD 13.1-RELEASE-p2 负责）看来少了一步：

kern.ipc.mb_use_ext_pgs: Use unmapped mbufs for sendfile(2) and TLS offload

确认一下：

# sysctl kern.ipc.mb_use_ext_pgs kern.ipc.mb_use_ext_pgs: 1

nginx 官方博客里面教的这个检查 KTLS 到底有没有生效，比如 grep nginx debug 日志，没有发现 SSL_sendfile: 8192 / BIO_get_ktls_send(): 1 是正常的，原因就是没有设置上面的 sysctl。

完成所有配置之后我还拿 port 编译了一个带 debug 的 nginx 验证了一下，可以了。

配置这些有一大部分原因是跑上网工具：现在网上有大把指南和 nginx 配置可以抄，对于普通用户其实我还是建议复制人家能用过来就行（不信？搜索一下就能看见不少类似“我改了A设置怎么感觉没生效”的问题）。追求细节一点的就要分清楚自己流量的特征，比如主要是为了 Netflix streaming，还是网页浏览。当然途中还可能碰见例如 TLS 0-RTT、TCP FastOpen、Multiplexer 这类，不要盲目 enable/disable，改完配置记得测试一下是不是真符合自身需求。

其他

要看到底有没有生效其实还有下面这个方法：

kern.ipc.tls.stats.active: 2 kern.ipc.tls.stats.enable_calls: 9 kern.ipc.tls.stats.offload_total: 9

到底要不要启用 KTLS，一句话：看情况。 用了不一定能提速，反而可能变慢(?)。

当然，我开起来主要是好玩。

UPDATE

KTLS(4)

TLS transmit requires the use of unmapped mbufs. Unmapped mbufs are not enabled by default, but can be enabled by setting the kern.ipc.mb_use_ext_pgs sysctl node to 1.

另参考：c235059，这个值在 AMD64 上默认为 1。

FreeBSD 13.2 Release Notes

KTLS (the kernel TLS implementation) has added receive offload support for TLS 1.3. Receive offload is now supported for TLS 1.1 through 1.3; send offload is supported for TLS 1.0 through 1.3. 1462dc95f796 (Sponsored by Netflix)

阅读材料

这些KTLS的参考资料建议全部读一下：

https://lists.freebsd.org/pipermail/freebsd-current/2021-March/079096.html

https://www.freebsd.org/cgi/man.cgi?query=ktls&apropos=0&sektion=0&manpath=FreeBSD+13.1-RELEASE&arch=default&format=html

https://github.com/openssl/openssl/issues/14595

https://freebsdfoundation.org/wp-content/uploads/2020/07/TLS-Offload-in-the-Kernel.pdf

https://www.openssl.org/docs/man3.0/man3/SSL_CONF_cmd.html

https://docs.nvidia.com/networking/display/FREEBSDv371/Kernel+Transport+Layer+Security+%28kTLS%29+Offloads

https://github.com/nginx/nginx/blob/5071bc0bcf18c2eade9d452b27d92bee341dd053/src/event/ngx_event_openssl.c

https://legacy.netdevconf.info/0x14/pub/slides/25/TLS%20Perf%20Characterization%20slides%20-%20Netdev%200x14%20v2.pdf

https://stackoverflow.com/questions/51672133/what-are-openssl-bios-how-do-they-work-how-are-bios-used-in-openssl

扩展阅读材料

https://people.freebsd.org/~rmacklem/nfs-over-tls-setup.txt

https://blog.trailofbits.com/2019/03/25/what-application-developers-need-to-know-about-tls-early-data-0rtt/

https://www.agwa.name/blog/post/parsing_tls_client_hello_with_cryptobyte

https://www.freebsd.org/releases/13.2R/relnotes/

[continuation]

openssl req -x509 -newkey rsa:2048 -nodes \ -keyout server.key \ -out server.crt \ -days 365 \ -subj '/CN=localhost' \ -addext "subjectAltName=IP:127.0.0.1,DNS:localhost" \ -addext "keyUsage=digitalSignature,keyEncipherment" \ -addext "extendedKeyUsage=serverAuth,clientAuth"

[continuation]

DNSSEC with BIND9

注：下面这些内容是个人笔记，不对实际可用性负责。

最近又把 Unbound 的 validator 开起来了，结果发现 techdocs.akamai.com 无法访问，直觉告诉我肯定 DNSSEC 配置出问题。用 Verisign Labs 的 Analyzer 检查一下，果然从 akamaiedge.net 开始断了。遂想起一个 DNSSEC 我拖了好几年……

DNSSEC 原理其实很简单，就是从根到叶利用 KSK 签名 ZSK、ZSK 签名 zone，并且在上级 zone 留下 DS 记录——KSK 的 digest，以此建立信任链。Resolver 通过验证即可得知记录是否被改动，从而避免 DNS 缓存投毒这类攻击。

有部分域名托管商不支持 DNSSEC 或者支持得不够好。最好自建 DNS 进行测试，BIND9 配置算不上很复杂，再找一个免费的 secondary 就行。

生成 KSK：

$ dnssec-keygen -3 -a ECDSAP384SHA384 -b 4096 -f KSK -n ZONE example.net

生成 ZSK：

$ dnssec-keygen -3 -a ECDSAP384SHA384 -b 4096 -n ZONE example.net

注：

-3：使用兼容 NSEC3 的算法

-a：具体算法类型

将会创建两个名字为“K域名+算法 ID+密钥 ID.扩展名”的文件，内含密钥对，可以直接 “$INCLUDE��� 到对应的 zonefile 中。这两个 key 就是所谓的 DNSKEY。算法可以考虑选择 ECDSA。

https://www.cloudflare.com/dns/dnssec/ecdsa-and-dnssec/

https://dl.acm.org/doi/10.1145/3419394.3423638

DNSKEY RR 中（wire format）含有 2 字节 Flags Field，0-6/8-14 位保留，只留下两种 bit pattern，0x0100 和 0x0101（第 15 位 SEP 置 1）。ZSK 为 256/0x100，对 zone 进行签名；KSK 为 257，对 key 进行签名，可以用作 trust anchor。例如：

example.net. 3600 IN DNSKEY 256 3 8 ( AwEAAd/XMj+n8AUH5W4E7Oii78h695rj0cVa6/dJ6aWX ... ... ) ; ZSK; alg = RSASHA256 ; key id = 24453 example.net. 3600 IN DNSKEY 257 3 8 ( AwEAAbMqsFTYoin5LDKjSo0Ix0nj29adzS97t2n3QImu ... ... ) ; KSK; alg = RSASHA256 ; key id = 51916

域名注册商通常会提供专门的入口提交 Delegation Signer，这个所谓的 DS 记录就是 KSK 的 hash：

$ dnssec-dsfromkey -a SHA-384 Kexample.net.+014+12345.key example.net. IN DS 12345 14 4 ......

准备好这些之后，就可以选择对 zone 进行签名方式——偷懒的方式是让 BIND9 自动签名：

zone "example.net." { type master; file "zones/db.example.net"; key-directory "/etc/bind/keys"; auto-dnssec maintain; inline-signing yes; };

这样一配一 reload，加上 DS 记录，基本可以工作了。

此时还有一个待解决的问题，碰见 NXDOMAIN 如何处理？这种情况，专业术语叫 “denial of existence”，一般想当然返回结果“不存在”并且附上某种签名并不可行——“不存在”本身不可变，导致签名也不可变。这样一来任何人都可以拿这个结果证明某个域名不存在（即便它存在），才有了 NSEC 和 NSEC3。如果不配 NSEC3 默认就是 NSEC。因 NSEC 含有遍历整个 zone 的可能，另外如果有很多 delegate 出去的子域不想生成相关记录（即：Opt-out）选择 NSEC3。

$ rndc signing -nsec3param 1 0 10 salt example.net.

（salt 可以填入“auto”这个特殊值，即自动生成。） 完成这一步即可。有备无患，下面这个命令是改 NSEC3 为 NSEC 用的：

$ rndc signing -nsec3param none example.net

另外可以选择主动签名：

zone "example.net." { type master; file "zones/db.example.net.signed"; key-directory "/etc/bind/keys"; };

然后运行一下：

$ dnssec-signzone -a -A -3 salt -k KSK -N increment -o example.net -t db.example.net ZSK

需要把 salt、KSK、ZSK 替换成具体的 NSEC3 salt 和密钥文件名；以上命令将创建签过名的 zonefile 外加 dsset，鉴于之前手动生成了 DS 记录，dsset 可以不用。

生成 salt 也可以偷懒：openssl rand -hex 4 还有个测试工具：nsec3hash

如果搞错了或者想重新来过又或者每年常规维护更新 key，理论上要走一下 rollover 流程。好在自己玩不用很复杂，把签过名的 zonefile 和 key 清理一下，DS 一更新，再 reload 即可。

9.16 版本以后的 BIND，有一个更加简易的方法——DNSSEC Policy，如果不是为了自己动手做一遍，那么这样写就可以了：

zone "example.net." { ... dnssec-policy "default"; ... };

Default policy 会用二合一密钥（Combined Signing Key, CSK）签名，并配置了一些计时周期自动 rollover，当然也可以自己进行定制。

https://kb.isc.org/docs/dnssec-key-and-signing-policy

问题整理

在 Debian 上跑这一整套流程，碰见第一个问题是 apparmor，BIND9 会在 zonefile 所在的工作目录下创建临时文件，如果选择配置在 /etc/bind 的下级目录，文件操作会被拒绝。解决方法也很简单，改到 /var/lib/bind 下面就可以了……只能说是目录权限管理理念的差异。

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=202981

NSEC3PARAM 的 TTL 到底应该设置什么值？

RFC 5155 未明确指出，实现方至今没有统一结论，但一般为下列两者之一：BIND9 会默认置 0，而别的实现（如：PowerDNS）会用 SOA 中的 Minimum TTL 填补。填 0 的理由，是这个 RR 不会被 zone signer 之外用到——zone signer 利用这一信息产生 NSEC3 RR，仅此而已；虽然可以作为记录查询到，但实际上不该如此，也不应该被 cache。这里就产生了一个问题，比如 secondary DNS 虽然同步了 zone，但是对应 RRSIG 中 original TTL 一栏和实际上的 TTL 对不上。

这里有 Mr. DNS 的回复 https://blog.jcea.es/posts/20190704-nsec3params.html

https://doc.powerdns.com/authoritative/dnssec/operational.html#some-notes-on-ttl-usage

BIND9 自动签名的 NSEC3 RR 会多一个 TYPE65534 出来

请阅读被称为 “ARM” 的管理员参考手册：

https://downloads.isc.org/isc/bind9/9.16.5/doc/arm/html/advanced.html#private-type-records

配置 TSIG 用于 zone transfer (BIND > 9.13.0)

$ tsig-keygen -a hmac-sha256 slaves.example.net

然后复制配置并添加到文件中：

key slaves.example.net { algorithm hmac-sha256; secret "........"; };

IP+TSIG 双重限制，我是这样配的：

allow-transfer { { 1.2.3.4; }; // 允许 IP 1.2.3.4 { !{ !5.6.7.8; any; }; key "slaves.example.net"; }; // 允许 IP 5.6.7.8+TSIG Key };

最后��忘记在防火墙上打开 TCP 53 端口。

更新：配置 hidden master

先不提备份。

因 apt(8) 良好的默认设置，在我清理（用的是 purge）一个相关软件包的同时，一敲回车顺手把 bind9 连同配置一起清了。借此机会把服务迁到 AWS 的 FreeBSD 实例、旧的 DNS 切成 secondary 继续暴露给互联网提供服务。

其他文档和工具

https://dnsviz.net/

https://dnssec-analyzer.verisignlabs.com/

https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml

[continuation]

天命之謂性，率性之謂道，修道之謂教。道也者，不可須臾離也，可離非道也。是故君子戒慎乎其所不睹，恐懼乎其所不聞。莫見乎隱，莫顯乎微。故君子慎其獨也。喜怒哀樂之未發，謂之中；發而皆中節，謂之和；中也者，天下之大本也；和也者，天下之達道也。致中和，天地位焉，萬物育焉。

[continuation]

袖振り合うも多生の縁

[continuation]

关于设置 Docker Desktop for Mac

如果不想注册直接下载，请参考这里和相关讨论。

如果需要用到 Kubernetes 相关功能，在 Enable/Restart 之后，千万要耐心等待——可能因为网络不佳出现卡在 starting 的问题，先不用急着删 .kube、pki 目录和恢复出厂设置，找个 VPN 试试，直到 docker image ls -a 命令返回类似如下内容：

REPOSITORY TAG IMAGE ID CREATED SIZE k8s.gcr.io/kube-proxy v1.15.5 cbd7f21fec99 3 months ago 82.4MB k8s.gcr.io/kube-apiserver v1.15.5 e534b1952a0d 3 months ago 207MB k8s.gcr.io/kube-controller-manager v1.15.5 1399a72fa1a9 3 months ago 159MB k8s.gcr.io/kube-scheduler v1.15.5 fab2dded59dd 3 months ago 81.1MB docker/kube-compose-controller v0.4.23 a8c3d87a58e7 8 months ago 35.3MB docker/kube-compose-api-server v0.4.23 f3591b2cb223 8 months ago 49.9MB k8s.gcr.io/coredns 1.3.1 eb516548c180 13 months ago 40.3MB k8s.gcr.io/etcd 3.3.10 2c4adeb21b4f 14 months ago 258MB k8s.gcr.io/pause 3.1 da86e6ba6ca1 2 years ago 742kB

等待的时间都是为了拉这些 image 下来，如果还不行动手解决不迟。

[continuation]

2011年MBP 17‘’的显卡问题

书接上文，我手头这个17'' MacBook Pro (MacBookPro8,3) 已经服役九年余。 然而近来故障频发，症状可以总结为以下几点：

无法完成启动：开机进度条进行到一半左右消失，灰屏；随即自动重启，继续上述过程；

如果“碰巧”可以正常启动，在使用期间也会时不时出现条状花屏，重启；特别是 VSCode/Insomnia 这种基于 Electron 的 App，开启瞬间即可触发（很奇怪，Atom 不会）。

为了能继续压榨这台笔记本电脑的剩余价值，我这段时间一直没有正式关过机，而是采用合上盖子休眠的方式来代替。同时卸载了 VSCode，改用 neovim + 插件。总之，可谓小心翼翼，生怕再也不能开机，被迫花两三万大洋换个 16 寸。当然了，因为对 16 寸有所期待，加上还有一台备用电脑，我也没有对解决这一现状太过上心——查看了系统日志、启动时采用详细输出，也没有发现什么特别之处。

昨天不知道为什么灵机一动，决定试试对显卡自动切换设置进行调整，一试一研究让我找出了症结所在（关闭自动切换不久即可导致故障重启）：这批 2010-2012 年的双显卡 MBP，或是独立显卡的一个电容有问题或是独显本身有问题——之前说的召回，感觉就是针对这个缺陷进行处理。还记得当时天才吧的人告诉我这个机器还能再跑个 2、3 年，现在想想他们是不是也就上了一个临时的补丁，确保短期内不再故障即可。

如何解决呢？绕过独立显卡。这就要提及 OS X 一个非常不尽如人意的地方，本来双显卡，让用户自由选择用哪一块就好，偏偏自动切换模式下优先选择集成那块 Intel 的卡，关闭自动切换用的是独立的 AMD Radeon HD 6750M。换句话说，没有办法直接让集成显卡全包所有的工作。好在有一个叫做 gfxCardStatus 的工具（及其后续的衍生版本）恰巧可以满足需求。不过这两个版本都已经不再开发，我目前在 High Sierra 上使用 v2.4.4i，一切正常。

接着还要修改 EFI 变量和移除 AMD GPU 相关的内核模块，连同启动灰屏一起解决，这里说明得足够详细，照做就是了。nvram 和 Arch Linux 的方法我全部试过，应该都可行；唯一的问题是，把内核模块移掉之后，屏幕亮度会最大化且不可再加调整，反正我又把那些文件放回去了，重启了几次也没有继续故障。

更新1：根据文章所示，盲目移除所有 AMD 内核扩展会导致无法调整屏幕亮度及温控等等问题。

验证解决方案有没有生效也很简单，看一下系统偏好设置里面“节能”这里，如果自动切换已经不处于勾选状态外加当前使用的显卡为 Intel HD，就说明��功告成。（注：目前系统偏好设置中自动切换为开启状态，见“更新2”）

这个笔记本我估计还可以再用个三、五年的……

更新2：最关键的步骤就是在单用户模式或恢复模式下运行上面这行。个人感觉如果已安装 High Sierra 最新更新，设置好 EFI 就能解决问题（不需要依赖 gfxCardStatus、甚至不需要再停用内核模块）。然而我已经完成所有步骤，暂时没机会验证了。

更新3：还是再次验证了一下，下面是解决这个问题的完整步骤。（macOS High Sierra）

开启笔记本，按下 Cmd+R 进入恢复模式，选择语言，启动终端；

在终端输入以下内容（不包括 #）并回车执行：

# nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00 # nvram boot-args="agc=0" # cd /Volumes/Macintosh\ SSD/ # cd System/Library/Extensions/ # mkdir AMD && mv AMDRadeonX3000.kext AMD # cd - # touch System/Library/Extensions

以上内容中，/Volumes/Macintosh\ SSD 需换成对应的启动磁盘，完成之后退出安装器并重启；

（此时应该可以）正常启动电脑，登录桌面后，打开任意编辑器，输入以下所有内容并保存为 /Library/LoginHook/LoadX3000.sh（需要先创建 /Library/LoginHook 目录）：

#!/bin/bash [ "$(kextstat -lb com.apple.kext.AMDRadeonX3000)" ] && exit 0 path=/System/Library/Extensions/AMD/AMDRadeonX3000.kext [ -d $path ] && kextload $path

打开终端，输入如下内容（不包括 $）：

$ sudo chmod +x /Library/LoginHook/LoadX3000.sh $ sudo defaults write com.apple.loginwindow LoginHook /Library/LoginHook/LoadX3000.sh

重启，结束。

[continuation]

FreeBSD Jail 中的路由

前段时间碰见的问题，现象是：给服务器加了条外网的线，结果 jexec(8) 进去发现不能 pkg upgrade，错误为“Protocol not supported”，ping(8)（已经开启 allow.raw_sockets）也显示“Can't assign requested address”。但是内网相关一切正常。

这是 Jail 全部分配了内网 IP，默认路由为外网出口导致的（一直把 Jail 用于内网服务隔离，没有机会接触这种双线环境，所以还是要多学习）。 回到原始需求，所有 Jail 都走内网，宿主不受影响，只要启用多路由表即可。

首先在 loader.conf(5) 中设置路由表数量并重启生效（N代表路由表个数）：

net.fibs="N"

接下来是设置第二路由表，可以利用 setfib(1) 或者 route(8) 自身对 FIB 的支持：

setfib 1 route add default 10.0.0.1

或者

route add default 10.0.0.1 -fib 1

确认也是同样：

setfib 1 netstat -rn -finet Routing tables (fib: 1) Internet: Destination Gateway Flags Netif Expire default 10.0.0.1 UGS bge1

或者 netstat -rn -finet -F 1。

jail.conf(5) 里面有设置 Jail 默认 FIB 的选项 exec.fib，加上即可。另外还有一个办法，可以在 jexec(8) 之前加上 setfib 1 让后续在 Jail 里面执行的命令都以路由表 1 为准。

确认一下：

# sysctl net.my_fibnum net.my_fibnum: 1

参考：

setfib(2)

[continuation]

子曰：「不憤不啟，不悱不發。舉一隅不以三隅反，則不復也。」

《 論語·述而第七》

[continuation]

坊主憎けりゃ袈裟まで憎い

ことわざ

[continuation]

一日一時は尊いもの　時の流れは永久に取り返せない

[continuation]

古今和歌集 伊勢物語 「渚の院」

世の中に　絶えて桜の　なかりせば 春の心は　のどけからまし

在原業平

伊勢物語 第82段「渚の院」（第二首目）返歌（へんか）

散ればこそ　いとど桜は　めでたけれ 憂き世になにか　久しかるべき

よみ人しらず

[continuation]

刚刚更新 Port，发现 strongSwan 从 5.7.2_1 变到了 _2，引入 VICI 配置（默认保留 ipsec/stroke），动手把我之前的 ipsec.conf 也迁移到了 swanctl.conf。

如果一直都没改过插件配置，那迁移难度应该不大。怪就怪我之前把插件精简了一番，把 /usr/local/etc/strongswan.d/charon 下面 *.conf 很多都 load = no 了，其中就包括了 pem，导致 certs 部分配置一直加载不上，报错“parsing X509 certificate failed”。

修完上面这个问题，在 rc.conf 里面加上：

strongswan_interface="vici"

并把 charon 下面的 vici 插件也设置为 load = yes。服务正常启动后，就可以直接使用 swanctl(8) 来替代 ipsec(8) 了。