
Mac 有 IPv6 地址却 ping 不通任何公网 IPv6。之前一直正常,某天突然全断,重启路由器也没用。最终定位是 iStoreOS 的 NDP Relay 模式不稳定,改一行配置从 relay 切到 server 就修好了。这篇记录了逐层排查到根因的完整过程。


Mac 有 IPv6 地址却 ping 不通任何公网 IPv6。之前一直正常,某天突然全断,重启路由器也没用。最终定位是 iStoreOS 的 NDP Relay 模式不稳定,改一行配置从 relay 切到 server 就修好了。这篇记录了逐层排查到根因的完整过程。
AWS 不提供 Graviton 架构的 Windows AMI,但这不代表 Graviton 跑不了 Windows。本文记录如何用开源项目 bin456789/reinstall 的一键 DD 脚本,把一台运行 Amazon Linux 2023 的 t4g 实例原地重装成 Windows 11 Pro ARM64。


新 Mac 到手后,我习惯先做一次系统化检测:硬件信息、SSD 健康、接口状态、安全配置、系统稳定性都过一遍。这样后面如果遇到异常,可以知道是机器本身的问题,还是后续使用环境造成的。
在终端执行 nslookup www.youtube.com 8.8.8.8,看到 Server: 8.8.8.8,很容易以为答案来自 Google。但这个字段只说明查询目标,以及被接受的应答声称的来源。明文 UDP/53 没有认证这个来源。
2026 年 9 月 27 日,我在 iStoreOS 软路由上做了一次 WAN 抓包实验。最有价值的结果不是“六家 DNS 的答案不同”,而是:向一个不应提供公共 DNS 的文档保留地址查询,仍收到了匹配的 DNS 应答。
把第二台域控分散到另一台物理宿主机,直接迁移健康 VM 通常更简单。这次我选择从黄金镜像新建可写 DC、更新并提升、验证复制,再正常降级旧 DC2;新机使用新名称,最终接管原 IP。
2026 年 9 月 21 日,核心切换和功能验收完成。旧 VM 已退域、关机、断网,尚未销毁。最容易遗漏的是:相同 IP 不会继承旧 FQDN、TLS 证书或客户端依赖。
“BIOS 找盘,BCD 引导 Windows”省略了几层关系。PVE 的虚拟设备顺序、UEFI 的启动项、Windows BCD 的系统选择是三份不同配置。真正打开磁盘和虚拟固件,区别就清楚了。
2026 年 9 月 21 日,我从 Windows Server 黄金模板完整克隆 VM202,断开网卡、关闭自启,完成只读检查和一次正常启动观察。模板 VM200 与域控 VM201未改动。这一轮是静态证据加启动验证,没有固件指令跟踪或 ETW 启动时序。
第一台 PVE 已运行域控、ASR、监控等服务,第二台是新装空机。我希望统一管理、保留手动迁移能力,并让现有业务继续运行。2026 年 9 月 19 日,两台机器成功组成集群;没有配置 HA 资源,QDevice 也尚未部署。
这次最重要的操作并不是 pvecm add 本身,而是确定由哪台创建、哪台加入,以及用什么证据证明来宾没有重启。
这次身份集成最终打通了 Windows AD → authentik → Cloudflare 控制台。域用户用 AD 身份登录 authentik,再点击应用卡片进入 Cloudflare。最后一个障碍竟然是卡片的地址:普通控制台首页只是书签,并不会自动发起这套 SSO。
本文基于 2026 年 9 月 16 日的部署记录。authentik 为 2026.8.2,连接两台可写域控和一台云端 RODC;完整控制台登录已由用户实际确认。下文域名统一为示例,不包含口令或客户端密钥。
macOS 能使用 AD 域账号,不意味着它会按 Windows 的方式处理设备策略。我在一台 macOS Sequoia 实验 VM 上做了绑定、GUI/SSH 登录、移动账户和 GPO 对照;最有价值的结果是把“目录身份”和“设备管理”拆开。
原环境为 PVE 虚拟化 macOS,仅作为这次实验背景,本文不展开安装路线,也不把单台实验机结果推广成所有 Mac 的兼容性保证。域名、OU、账号与地址均换成示例。DNS 域使用 corp.example.com,NetBIOS 名单独设为 LAB,不能把两者混用。
2026 年 8 月 14 日来电后,两台 PVE 域控启动,主机名能解析,部分 IPv4/IPv6 探测正常,DC1 从 DC2 拉取 Schema 的最近一次复制却报 8524。
随后在 DC2 请求 DNS 注册、重启 Netlogon,修正远程命令包装并定向重试,复制恢复。9 月 15 日整理记录时,最值得纠正的是当时过快的解释:恢复成功不证明最初一定缺了某条 DNS 记录。