在 Proxmox 上用 LXC 还是 VM 跑 WireGuard：它该放在哪里？

WireGuard 需要恰好一个内核对它的接口负责，而这一点在性能被拿出来讨论之前，就已经定下了 Proxmox 部署争论的大半。LXC 容器是宿主机内核的命名空间视图，VM 则启动自己的内核。所以真正有用的问题不是哪个选项更轻，而是你愿意改动哪个内核、能接受哪条恢复路径。把这一点答清楚，宿主机、容器还是 VM 的选择通常就自然定了。

LXC 客户机跑在宿主机内核之内

在容器里安装 wireguard-tools，你拿到的是控制程序，而不是独立内核。你创建的 wg0 接口注册在宿主机的网络栈里，并出现在宿主机的模块列表上。正因如此，容器可以通过所有软件包检查，却在宿主机内核缺少该模块时于第一条 wg 命令上失败。而 Proxmox 容器参考文档 记录了这一共享内核模型，以及你实际所处的命名空间与权限边界。

第二个约束是权限。把接口拉起来并给它挂地址，需要 该接口所属命名空间内的网络管理权限，而非特权容器并不直接持有这些权限，而是通过它的用户命名空间做映射。不要把完全特权当作第一答案；先看清容器实际被要求做什么，再只给那一部分。

宿主机内核也是一份共享依赖。一次 Proxmox 内核更新会同时改变所有容器底下的 WireGuard 实现，这很方便，直到某次更新和某个容器的预期对不上。

宿主机、容器、VM：每种放法真正持有什么

放在宿主机上，就是把 VPN 放进 hypervisor 自己的网络。路由、防火墙规则和隧道都成为宿主机恢复的一部分，那里出错可能连管理接口一起带走。对能通过控制台够到的宿主机来说，用于基础设施路由尚可接受；对没有带外访问的远程机器则很痛苦。

容器把服务打包好、可重启，同时仍然借用宿主机内核。它适合刻意共享内核的服务，也给你一个便于重建的小单元。它不提供独立内核，所以任何需要特定模块构建的东西都不该选它。

VM 多花内存，还多一套要打补丁的系统；换来的则是隧道拥有自己的内核、自己的路由表和一层快照边界。当在糟糕改动后要回滚的正是 VPN 时，这层快照值这份开销。

三个替你选的条件

如果隧道需要 Proxmox 宿主机不提供的内核版本或 WireGuard 特性，就停在这里，改用 VM。你无法把更新的内核装进容器，也不该为了迁就一个客户机而更换 hypervisor 内核。

如果隧道是站点里真实 LAN 前缀的网关，先问一句：回程路由已经归谁管。容器能路由流量，但它的接口坐在宿主机栈里，于是不管你计划没计划，宿主机最终都要承担一部分配置。放在宿主机上在这点上是诚实的；放在容器里往往不是。

然后衡量一次错误的影响半径。重启容器很便宜，恢复 VM 快照可预期，修宿主机网络则可能需要物理或控制台访问。正确的选择是：最坏情况真的能在出事那一个小时里恢复。

第四个问题很少起决定作用，但值得说出来：宿主机上还有别的东西需要看到隧道接口吗？如果需要，放在宿主机或容器里能让这种可见性留在本机；VM 则逼你在客户机和宿主机之间路由。

在把流量导进去之前，先证明这套放法站得住

装好之后要确认：到底是哪个内核在服务这个接口，容器拿到的权限是否够它维持下去：

$ pct config 101 | grep -E 'unprivileged|features'
unprivileged: 1
$ pct exec 101 -- wg show
interface: wg0
  listening port: 51820
$ pct exec 101 -- ip -4 addr show wg0
inet 10.60.0.2/24 scope global wg0

接着从宿主机检查转发那一侧，因为单次握手只能证明隧道起来了。用 ip route get 查一个客户端地址，确认下一跳和接口跟设计对得上，并确认对端存在回程路径。

把部署留给一个有名字的负责人：实现跑在哪个内核上、接口归哪个命名空间管、网关被允许转发哪些前缀。这一句话挡下的事故，比三种放法的任何基准对比都多。