家庭 VPN 服务器与云服务器：哪一个能连到你的 NAS？
隧道能建立，但家里的 NAS 依然不可达。先按你必须访问的资源选择 endpoint 的位置，再检查路由。
隧道建立，客户端显示绿点，而 ssh 192.168.1.20 仍然挂起到超时。我租了一台小云主机并装上 WireGuard 之后就遇到一模一样的情况：握手正常、DNS 正常，桌上那台 NAS 却像在月球上一样不可达。隧道本身没有问题。Endpoint 被放在了一个没有通往我家路由的网络里。Endpoint 的位置决定了哪些网络与它相邻，所以要先按你必须访问的资源来选，再比较托管条件。
隧道只能到达 endpoint 能路由到的网络
VPN 会分给客户端一个位于 endpoint 自身路由域内的地址。客户端向 192.168.1.20 发包时，endpoint 必须知道这个包该往哪走。云主机的路由表只认服务商的 VPC 子网，从没听说过你的 LAN。已连接和可访问是两件事，家庭与云之间的多数困惑都来自把前者当成后者的证明。
一条命令就能判定。在 endpoint 上，ip route get 192.168.1.20 要么指出一个 LAN 接口，要么指向默认路由。家用机器上的答案是 LAN 一侧。云主机上数据包会发往互联网然后死掉。开启 net.ipv4.ip_forward=1 并添加 MASQUERADE 规则也改变不了这一点，因为在家庭一侧有东西把链路接到云端之前，根本没有可转发的地方。
家庭场景还有后半段：回程。从 LAN 经过隧道主机出去的包会被 NAT，或者 LAN 需要一条回到隧道子网的静态路由。当只有一个方向能通时，检查 sysctl net.ipv4.conf.all.rp_filter。严格的反向路径过滤会丢掉从与路由预测不同的接口到达的回包，症状看起来和防火墙规则一模一样。
先读症状，再动配置
隧道建不起来：密钥、endpoint 地址或被封的 UDP 端口。隧道起来了但 LAN 主机不通：位置和路由。隧道起来了但上不了网：转发、NAT 或 DNS。这是三个层次、三种不同的检查，改写一份本来就正确的配置只会浪费一晚上。
| Symptom | First suspect | Check |
|---|---|---|
| Handshake fails, no transfer | Keys, endpoint port, UDP blocked | wg show, then the port from outside |
| Peer pings, LAN host times out | No route to the LAN | ip route get on the endpoint |
| Tunnel up, name resolution fails | DNS options in the peer config | Resolve a name from the client |
| Large transfers reset the connection | MTU | Lower the tunnel MTU and retry |
家里的入站可达性值得单独检查，因为它决定了在家里托管到底可不可能。把路由器报告的 WAN 地址与外部主机看到的地址做比较。如果它落在 100.64.0.0/10，或者两者对不上，你就处在运营商级 NAT 之后，任何端口转发都不会生效。真正的选择是中继、一条从家里向外拨号的云端链路，或者把 endpoint 搬走。
在家托管能换来什么，又要付出什么
家是唯一默认处在 LAN 内部的位置，这正是把服务器放在家里的全部理由。只在本地网段应答的设备——比如打印机，以及拒绝非本地子网的 NAS 管理页面——不需要额外路由就能工作。机器、路由器和上行链路也都由你自己维护。
代价是物理性的。家庭上传带宽是所有客户端同时共享的上限，所以视频通话和备份会抢同一条管道。电力、磁盘磨损、打补丁、需要 DDNS 的动态地址、必须向内转发 UDP 的路由器，以及可能的双重 NAT，全都落在你身上。人们常忽略的是恢复能力：如果你不在家时机器坏了，你回家的唯一通道也一起断了。留一台有相同密钥的第二台设备，或者至少准备一套物理接触方案。
如果想在没有家里那台机器的情况下访问 LAN，那就搭一条链路，而不是假装可以。云端 endpoint 变成路由器：从家庭一侧建立隧道，AllowedIPs = 192.168.1.0/24 配在云端 peer 上，再在云主机上做转发和 NAT。strongSwan 的转发指南正好讲了这套配置的回程部分，而这些尝试大多失败在那里。现在家庭 peer 必须在线，任何东西才能工作，所以你只是把一种依赖换成了另一种，应该把这点写下来。
云端 endpoint 到底是干什么用的
云端 endpoint 改变的是你的公网出口。流量从服务商的地址段出去，网站看到的是那个地址，而不是你家的地址。价值就在这里，这也正是云 VPN 不会给你 NAS 的原因：你搬走的是出口，不是 LAN。
你仍然要维护客户机系统、VPN 服务及其凭据，而服务商维护的是 hypervisor 和物理网络；凌晨 2 点出问题时，这个分工很关键。公网 endpoint 会被持续扫描，所以要关闭管理端口、只放行 VPN 端口，并按计划打补丁。安全组和服务商防火墙必须放行该端口，而且有些云如果不调整实例的源/目标检查，就会丢弃转发的流量。
小实例能覆盖少量客户端，但加密是 CPU 工作，突发型实例在积分耗尽后持续负载下表现不均。要看实际使用的路径，而不是规格表。
一个可以写下来的决定
决定位置的是任务，不是机箱上的标签。如果你需要访问家里 LAN 上的设备，最便宜的正确答案是家里的 endpoint；云主机只有在你把回程链路搭好之后才可行。如果你需要另一个公网出口，答案就是云，LAN 的问题根本不会出现。两者都要是合理的，但那意味着两个 endpoint、两套密钥和两条有文档的路径。
| What you need | Endpoint location | What else must exist |
|---|---|---|
| Reach a NAS or printer on the home LAN | A box on that LAN | Port forward or relay, DDNS, recovery plan |
| Browse from an exit unrelated to home | Cloud instance | Firewall and egress rules, patching |
| Both, reliably | Two endpoints, or cloud plus a link home | Separate keys, routes, documented failure modes |
按顺序从客户端验证：握手、peer 地址、LAN 主机，最后是出口 IP。curl -s https://ifconfig.me 显示互联网看到的东西，ip route get 192.168.1.20 显示 endpoint 认为的东西。当出口检查通过而 NAS 检查挂起时，位置问题的答案已经有了；在客户端上调 AllowedIPs 并不会凭空变出路由。10.8.0.0/24, 192.168.1.0/24 这样的分行只有在路由确实存在时，才会把 LAN 流量留在隧道里。