涼果笔记

2026-01-27

创建于: 更新于: 6分钟阅读本页源码

修改 pveam download 下载源为镜像站

为了解决 LXC 容器镜像下载慢的问题，直接修改命令的源代码来得最快。

sed -i 's|http://download.proxmox.com/|https://mirrors.cernet.edu.cn/proxmox/|g' /usr/share/perl5/PVE/APLInfo.pm

路由器上的 tailscale 日志文件有大量 monitor: RTM_NEWROUTE 内容

打开 Koolshare 的 Tailscale 插件中 tailscaled运行日志 窗口，整个浏览器页面都卡死了。开发者工具一看，加载了整整 26MB 的日志文件。

从 http://192.168.9.1/_temp/tailscaled_log.txt 把文件下载下来看到的满眼都是 monitor: RTM_NEWROUTE 这种关键字，而且和 IPv6 有关。

2026/01/27 18:43:37 Program starting: v1.92.4, Go 1.25.5: []string{"/koolshare/bin/tailscaled", "-state", "/koolshare/configs/tailscale/tailscaled.state"}
2026/01/27 18:43:44 monitor: RTM_NEWROUTE: src=, dst=2408:8362:73:52f2:8827:fd4:4d8f:aacf/128, gw=fe80::1, outif=13, table=254
2026/01/27 18:43:44 monitor: RTM_NEWROUTE: src=, dst=2001:e68:5472:10b6:8559:d374:9e4e:2e67/128, gw=fe80::1, outif=13, table=254
2026/01/27 18:43:44 magicsock: derp-20 connected; connGen=1
2026/01/27 18:43:44 health(warnable=no-derp-connection): ok
2026/01/27 18:43:44 monitor: RTM_NEWROUTE: src=, dst=2001:e68:5472:10b6:58c3:51a2:8dc1:1380/128, gw=fe80::1, outif=13, table=254
2026/01/27 18:43:44 monitor: RTM_NEWROUTE: src=, dst=2001:9b0:1:1603:85:24:253:50/128, gw=fe80::1, outif=13, table=254
2026/01/27 18:43:44 monitor: RTM_NEWROUTE: src=, dst=2409:8a20:1cd2:c4d0:7874:ee38:68b0:1cfb/128, gw=fe80::1, outif=13, table=254
2026/01/27 18:43:44 monitor: RTM_NEWROUTE: src=, dst=2409:8a1e:6940:7c20:c4e6:22f8:171e:f1ed/128, gw=, outif=41, table=254
2026/01/27 18:43:45 monitor: RTM_NEWROUTE: src=, dst=240e:382:b13:d100:360d:b419:8897:4c7f/128, gw=fe80::1, outif=13, table=254

这个文件是由 SukkaW/Koolshare-OpenWrt-API-Documents: The API documents (unofficial) for Koolshare OpenWrt httpdb 的文件清单 API 从路由器的 /tmp/upload/tailscale_log.txt 位置下载而来。

看上去是因为，Tailscale 捕获到了流经路由器的流量基于 NDP 协议对 IPv6 路由表进行的动态更新。

在 Openwrt 上也会这样，好在有解决方案 tailscale in OpenWRT keeps on registering error · 议题 #16420 · tailscale/tailscale

而产生这个日志文件的 /koolshare/scripts/tailscale_config 又是个 非开源 的二进制，找不到很好的切入点关闭日志。（没地方添加命令行参数 --no-logs-no-support）

我部署 tailscale 的目的是把内网设备暴露出去（--advertise-router），那么本次的经验是不要在路由器上做这个，放到一台独立容器中会更好（或者在一个可以忽略此问题的运行环境）。

所以我选择在我的那个 Openwrt 上关闭日志运行。它能同时广播两个子网，也不会有日志问题。

/etc/config/tailscale
config settings 'settings'
        option log_stderr '0'
        option log_stdout '0'
        option port '41641'
        option state_file '/etc/tailscale/tailscaled.state'
        # default to using nftables - change below to 'iptables' if still using iptables
        option fw_mode 'nftables
opkg update
opkg install tailscale
tailscale set --advertise-routes="192.168.0.0/24"
tailscale up

上面这个办法只是表面上解决了问题，把 Tailscale 安装在路由器上就是为了让局域网设备能不加设置地直接访问到 tailnet，其中一个用处是使用 tailscale serve 以 HTTPS + 域名暴露只监听在 127.0.0.1 的 moltbot，所以还是得在主路由上部。

尝试添加静态路由的方式路由到 tailscale 客户端，似乎是防火墙拦截了，这方面探索先放下

既然不知道 koolshare 怎么做的，那解决方案就是模拟它的行为。
在 WebUI 启动后把原先的进程干掉，替换成自己的：

killall tailscaled
nohup /koolshare/bin/tailscaled -state /koolshare/configs/tailscale/tailscaled.state 2>/dev/null &

当然别忘了给局域网设备配置 DNS

dnsmasq.conf
server=/koi-cosmological.ts.net/100.100.100.100
server=/tailc4e92a.ts.net/100.100.100.100

systemd certbot .service 状态异常

命令备忘

属 Cloudflare 认证令牌过期了，按照 [[#|#为 Windows RDP 申请 Let’s Encrypt 证书]] 的过程重新设置执行就好。注意调节 DNS 传播等待时长

Inside WSL2
# check system log
journalctl -xeu certbot.service
# retry service
sudo systemctl start certbot.service
# update API credential
vim ~/.secrets/certbot/cloudflare.ini
# manually trigger renew
sudo certbot renew --dns-cloudflare-propagation-seconds=60

JFFS 分区文件丢失引发局域网 DHCP 分配混乱

不知怎得，断电或者死机，今天路由器重启了，以前也发生过。RT-AX86U 上的 JFFS 分区文件像是丢了一样，我编写 DNSmasq 的配置文件不翼而飞，上面记录了很多关于 IP 地址池分配的指令。现在局域网里各个设备拿到的都是另一个 DHCP 服务器分配的新 IP 地址（这又是另一个故事 RG-MA3063 内置 DHCP 会在桥接模式断网后激活），无法通过设备名关联到解析记录。特别是小爱音箱等 IoT 设备，得手动断点重启才能重新取得 IP。

这种事故会引发 PVE 主机依赖虚拟机作 DHCP 导致主机无法启动 问题的，好在之前在 使用 MACVLAN 为主机同时分配静态 IP 并取得动态 IP 设置的 mgmt 网卡能提供直接连接，不至于丢失设备访问入口。登上去刷新 DHCP 就好 systemctl restart networking

关系图谱

反向链接