一条 AWS Client VPN 会话背后的 LAN：什么会被转发

主机上能用的会话不会自动延伸到 LAN。按顺序检查客户端支持、转发、地址转换和回程路径。

笔记本连上 AWS Client VPN 端点，能到私有子网，一切看起来都正常。同一 LAN 上的台式机却什么也到不了，尽管 Linux 主机也有网桥接口，两台机器还在同一根线上。隧道里没有配置错误；缺的那一环是路由，网桥是一条假线索。

把 Client VPN 会话扩展到 LAN 是网关角色，不是把以太网段拉进托管服务。

主机能用，LAN 不能用

Linux 机器上的隧道接口在 Client VPN 客户端 CIDR 内有地址，端点也下发了 VPC 网段的走法。那台机器上发出的请求是本地生成的流量：选一条路由、从隧道出去、拿到回应。这条路径从不经过转发代码、LAN 接口，也不经过任何管辖过境流量的防火墙规则。

来自另一台 LAN 设备的流量是另一条流。它落在 LAN 接口上，需要一条指向隧道的路由，需要开启转发，需要放行它的防火墙，还需要回应从同一台主机回来。四个条件，而笔记本上跑通的那个测试一个都没证明。从台式机看，故障显得很怪：隧道是通的，凭据有效，目标就是不应答。缺陷在网关的转发路径上，不在服务侧。

并非所有客户端都能当网关

AWS 说明其 Client VPN 桌面应用不支持 IP 转发，其他客户端可能支持。这条限制在任何命令敲下之前就决定了架构。如果唯一可用的客户端是官方桌面应用，那么为 LAN 做转发的 Linux 网关就是无法完成的配置，再多的 masquerading 也改变不了。

替换的客户端还必须匹配端点的认证方式以及你打算执行的策略。基于证书、目录和 SAML 的端点不接受同一套客户端配置，而一个能认证却忽略下发路由的第三方客户端算不上改进。

把客户端选择当作设计评审的一部分。它决定 LAN 转发模式是否成立，也决定端点对网关后面每台设备看到的是什么身份。把客户端和它被测试时的端点配置记录下来。半年后换一个客户端，可能悄悄去掉设计所假设的能力。

把 LAN 路由进隧道并做地址转换

有了受支持的客户端，剩下的就是普通网关工作。LAN 设备需要一条指向 Linux 主机的 VPC 网段路由，主机需要开启转发。如果希望 VPC 把流量看成已连接的那个客户端，而不是一个随便的 LAN 地址，就在出口做源地址转换。

LAN: 10.24.11.0/24
Linux LAN gateway: 10.24.11.15
VPN interface: tun0
Target VPC range: 10.2.0.0/16

iptables -t nat -A POSTROUTING -s 10.24.11.0/24 -d 10.2.0.0/16 -o tun0 -j MASQUERADE

把规则限定在隧道接口和 VPC 网段上，如上所示，而不是把主机转发的一切都做 masquerading。更窄的规则更容易推理，也不会悄悄改掉本该保留原始源地址的流量。

能自动就自动下发 LAN 路由：一个 DHCP 选项、一条路由通告，或者由管理 LAN 的东西推送的静态路由。只存在于一台测试机上的路由，会在别人一试的瞬间让设计看起来是坏的。

回程也要有路

请求到达 VPC 之后，回应必须沿着同一套转换状态回来，并在网关上找到 LAN 路由。只要 masquerade 规则在位，这一段通常没问题，因为映射就活在执行它的那台主机上。当 VPC 侧有一条把回应送到别处的路由时，它就会断；这正是客户端 CIDR 路由和端点上的子网关联都重要的原因。

看计数器，不要只看 ping。零包的 masquerade 规则说明请求根本没到隧道接口，这把问题指回 LAN 路由或客户端自己的路由表。有包但没有回应的规则指向 VPC 侧、授权规则，或者一个不接受转换后源地址的安全组。改动之前先读两个方向，因为只有一侧在涨的计数说明是单向通路，而不是慢。

记住端点是托管服务。没有服务器配置文件可改，也没有 client-config 指令可加，所以为自管 OpenVPN 服务器、带自定义客户端子网路由写的那套说明搬不过来。在 AWS 上，可用的杠杆是子网关联、授权规则和 VPC 路由表。

共享身份是策略必须回答的部分

网关后面的每台设备都用网关的 VPN 会话。端点的授权规则把访问权给某个用户或某个组，从服务角度看这条会话上只有一个用户。本地转发不会把这个身份变成按设备认证，也不会把设备姿态检查延伸到角落那台打印机。

这也许可以接受，也许正是设计被否掉的理由。这取决于 VPC 资源对谁在调用做了什么假设。共享身份只要和授权模型对得上就没问题；如果它悄悄把一条认证过的会话变成整个 LAN 的访问，那就是一条等着被写下来的发现。

如果需求真的是把整个站点接到 VPC，那在扩展远程访问客户端之前，先比较一下受支持的站点到站点方案。语义不同，而当 VPC 需要主动向 LAN 发起连接时，经过 NAT 的客户端会话是站点链路的糟糕替代品。

按这个顺序定下客户端、路由、地址转换和身份故事。每一环都约束下一环，而这个顺序解释了为什么主机能用、LAN 不能用。

相关文章