在 IPv6 的世界里，“同链路 (On-link)” 和 “静态路由 (Routed/Off-link)” 是决定你虚拟化网络生死存亡的两种根本模式。
- 同链路 (On-link) 就像是一个巨大的开放式大平层办公室。
- 静态路由 (Routed) 就像是一栋有明确收发室（前台）的写字楼。
当机房把你的 /64 网段配置为 “同链路 (On-link)” 时，它具有以下四个极其致命的特点（这也是你这几天疯狂踩坑的根源）：
1. 极度依赖“大声喧哗” (必须通过 NDP 寻址)
在同链路模式下，机房的边缘路由器认为这 1.8 \times 10^{19} 个 IP 地址，全部和它插在同一台物理交换机上。
当外网有一个包要发给你的 ::300 时，路由器不会直接把包扔给你的宿主机。相反，它会在这个大平层里大喊一声（发送组播 Neighbor Solicitation，NS 寻人启事）：“请问谁的 MAC 地址对应 ::300？”
只有当网络里有人（比如你的 ndppd）举手回答了，它才会把真实的包裹递过去。
2. 极其消耗路由器的内存 (ND Cache 爆炸)
因为路由器每次都要问，问完还要拿个小本子记下来（这就是 ND 缓存，相当于 IPv4 的 ARP 表）。
如果有人恶意用脚本扫描你 /64 网段里的几百万个随机 IP，机房路由器就会疯狂地往外发寻人启事，同时内存里塞满等待回应的记录，瞬间就会导致路由器死机（这就是著名的 ND 耗尽攻击）。
3. 极易触发机房的“变态级”物理防御 (你遇到的死局)
正是因为第 2 点的致命缺陷，现代平价机房（IDC）在面对 On-link 的 /64 时，通常会采取极其粗暴的硬件级阉割：
- 装聋作哑：路由器彻底关闭主动寻址功能（就像你刚才
tcpdump抓不到包一样）。它心里想：“你不主动把 MAC 报上来，我就直接丢包，绝不浪费算力去问你。” - MAC 白名单锁死 (Port Security)：交换机端口只认你宿主机的物理 MAC，容器和 KVM 伪造的 MAC、或者
ndppd代答的包，统统被防火墙直接拦截。
4. 它是虚拟化的“终极噩梦”
在同链路模式下，如果你想在 PVE 里开虚拟机，你绝对不能像真实的路由器那样把流量往下层（内网）转交。你必须：
- 要么把虚拟机的网卡直接桥接到外网口（极其危险，容易引发 MAC 泛洪被机房封号）。
- 要么就像我们这几天做的，在宿主机上架设
ndppd(代理邻居发现)，让宿主机极其委屈地假装自己拥有成百上千个 MAC 地址，去欺骗机房的路由器。
反观“静态路由 (Routed)”的降维打击
如果机房给你配了静态路由（Routed），逻辑就变成了“写字楼收发室”模式。
机房路由器配置了一条铁律：“凡是发往 2602:fcc0:...::/64 这个邮编的包裹，什么都别问，直接闭着眼睛扔给宿主机 (::1) 这个前台！”
- 没有任何废话：没有 NS 寻人启事，没有 MAC 地址白名单，没有任何缓存老化断流。
- 你才是真正的主宰：包瞬间到达你的
vmbr0，你的 PVE 宿主机变成了一台真正的企业级核心路由器。你可以在内部随意划分/80、/112给虚拟机，一切你说了算。
总结一下：
你现在正在一片名为“On-link”的泥潭里，用各种高超的内核技巧（ndppd、sysctl proxy_ndp）去弥补机房极其糟糕且充满限制的底层基建。
很多坑的设置，我一段一段整理