家庭实验室的虚拟机监控程序无法通过 VPN 访问：该从哪里查

隧道已建立，虚拟机监控程序的网页超时，而客户端声称已经连接。这个组合排除了很多可能：VPN 握手正常、客户端拿到了地址、端点可到达。剩下的是一小串路由与策略问题，而且它们有自然的顺序。要从虚拟机监控程序向外查，而不是从客户端向内查，因为确认它自身的状态成本最低。

从管理网段开始

确认虚拟机监控程序的管理地址和监听该地址的服务，并在做任何远程诊断之前，确认同一网段的其他主机能打开该页面。本地测试失败并不是 VPN 问题，而这五分钟的检查能省下一小时。

然后是两条路径。VPN 客户端需要到管理网络的路由，通常意味着客户端的 AllowedIPs 或推送的路由包含该子网。虚拟机监控程序或其默认网关需要到客户端地址池的回程路径，除非设计上刻意在入口做源地址转换。这是两个独立的事实，缺任何一个都会产生同样的超时。要分开检查：客户端上的 ip route get 192.168.10.20，以及在虚拟机监控程序主机上抓包，看报文到底有没有到达。

允许真正的远程管理员

授权与可达性是两回事。把网关和主机策略限制在真正需要管理访问的来源和服务上。只需要一个实验应用的访客 VPN 账号，不应因此就能进入管理平面；而放行整个隧道子网的粗放规则，正是造成这种情况的原因。

保留虚拟机监控程序自身的身份验证和证书检查。私有路由不是忽略意外身份警告的理由。

这个警告值得当作发现来处理，而不是当作障碍。如果证书与你使用的名称不匹配，要么名称写错了，要么服务并不是你以为的那个，这两个答案在管理界面上比在其他任何地方都更重要。用证书签发给的那个名称访问页面，并让 DNS 把该名称指向隧道地址。在局域网与隧道之间解析不一致的私有名称，是证书告警看起来像 VPN 故障的常见原因。

检查次要连接

有些功能使用的连接并不是网页所用的。控制台会话、ISO 上传、VNC 或 SPICE 代理以及迁移通道，各自可能使用不同的端口或不同的主机地址。当页面能打开而某个功能失败时，应去读该产品的要求，而不是把主机上的所有端口都打开。

把所有端口都打开，正是管理界面变成无人管理的界面的方式。每多一个端口，就多一个需要持续打补丁的监听者，而虚拟机监控程序暴露的端口已经够多了。找出该功能真正需要的那条连接，确认它能通过隧道到达，其余保持关闭。如果该功能坚持要直连一个无法通过隧道路由的主机地址，那是需要刻意绕开的设计约束，而不是转发一段端口的理由。

动网络之前先留好回程

在改动承载你自己 VPN 的虚拟网络之前，确认你有本地或独立的回程方式。

这在家庭实验室里尤其重要，因为 VPN 端点往往就是你要访问的那台虚拟机监控程序上的虚拟机。远程修改虚拟交换机、网桥或防火墙规则，可能把你正在使用的路径删掉，而会话也许能撑到你看清这件事发生。

要从实验室外部测试，而不是从局域网测试，并且既要验证允许，也要验证拒绝。本应从隧道不可达的网络，在你的改动之后仍应不可达，这与管理页面能否打开是两个不同的断言。把两个结果都写下来，因为第二个常被跳过，而实验室变大时它才最重要。

要留下的记录很短：管理地址与服务、两侧各自需要的路由、被允许到达的身份，以及恢复路径。这足够下一个人复现可用状态，而不必重新推导。

如果这一切之后页面仍然超时，先在虚拟机监控程序上抓包，再改下一条规则。从未到达的报文是路由或防火墙问题；到达却被拒绝的报文是服务或策略问题；到达并有回包而客户端仍在等待，是回程路径问题。strongSwan 关于转发的文档说明了 Linux 网关如何把隧道流量转发到内网主机。三次抓包胜过再一次猜测。