我家的拨号 IPv4 在 CGNAT 后面，IPv6 有能从公网路由的全局地址。NAS、PT 和 Lucky 的服务入口，这次检查了 IPv6 防火墙。
本文的实施和访问测试发生在10月16日。10月21日只读复核，六条规则仍同时限定WAN接口列表、LAN出口和目标设备列表，均为启用；没有再做换前缀、重启或公网非目标负向测试。下文设备分类和隔离进度沿用已确认的维护记录。
给六条 IPv6 放行规则加条件
原先六条业务放行主要按端口匹配。这次保留原端口，补上 WAN 入口、LAN 出口和目标设备地址列表，分别限定到 NAS、PT 和 Lucky。
PT 的几个目标还共用原来的端口匹配，没有细分到每个实例与端口一一对应。
列表里的动态 IPv6 地址由 RouterOS 每分钟同步，NAS 配套定时通告，供路由器重新学习地址。真实换前缀和重启恢复都还没演练。
这里的名单是允许从公网访问的服务目标IPv6地址，与RouterOS用于IPv4选路的CNIP名单、AGH用于选择DNS上游的国内域名名单分别维护。10月21日的DNS分流没有改变这六条规则，也没有把IPv6流量改送mihomo。
其余规则补了可信 LAN/VPN 或认证接口条件，四条无效或重复的历史规则停用了，ICMPv6 hop-limit 检查移到了通用放行之前。
改完重新读了规则和地址列表，双栈 Ping、DNS、HTTPS 都检查过，也用手机移动网络打开了 Lucky 入口。还没有从公网去访问其他主机的同一端口，确认它们是否会被挡住。
HomePod 的两个分组
HomePod 同时在 IoT 和代理设备列表里。核对后保留了这两个分组：它是 IoT 设备，也需要代理资格。按当前规则顺序，最终 QoS 落在中类。
手工地址范围和自动精确项也有重叠。范围条目负责兜底，精确项保留设备身份，对应效果取决于引用这些列表的规则和顺序；同一个地址在两个列表里，不会因此被转发两次。
sync_arp 的改动
sync_arp 这次补了写入前的整套检查。设备改类、ARP 禁用或出现地址冲突时，先检查计划，再写入。遇到冲突先停下，通过后先补齐新分类，再清理脚本自己生成的旧项。
手工条目和其他来源的动态项保留。IPv6 隐私地址暂时没出现在邻居表里时，也继续使用原来的宽限时间。
这些情况先在独立样本中测过，再比较现有地址的有效策略。除了一个明确废弃的代理例外，其余 284 个既有地址的策略保持原样。这次主要改的是脚本以后的更新流程，没有清出一批现有错误分类。
两台插座的活动 DHCP 地址、永久 ARP 和 IoT 标签没对齐。我先按设备身份核对，保留当前地址，再统一记录。其中一个旧地址已经被空气净化器使用，没有按旧备份直接恢复。
IoT 设备还在同一个 LAN
目前大部分设备仍在同一个 LAN。iot_devices 和预留访客列表是规则使用的分组，还没做成 VLAN 或访问隔离。NAS 的 macvlan 网络名称里虽然带 vlan，也没有因此完成 802.1Q 隔离。
后面做隔离时，还要确认手机、Home Assistant、NAS 和投屏之间哪些访问得保留，AP 能不能配合，以及改错后从哪里进入管理。