在分配的虚拟 IP 上访问 IKEv2 客户端

网关需要通过 IKEv2 向连接到它的笔记本电脑发起连接，并使用分配给该客户端的虚拟地址。隧道已建立，客户端能访问网关后方的所有内容，但反方向仍然失败。这种不对称是正常的：协商出的策略描述的是哪些地址可以通信，而不是哪一方可以发起。要让网关发起的请求生效，必须同时满足三个条件。

隧道并不会修正源地址

一个 CHILD SA 覆盖一对流量选择器，每侧一个，并允许该对选择器双向通行。它并不说明哪一方先打开了 IKE 交换。最初在监听隧道的网关仍然可以发出第一个应用数据包，前提是所选源地址和目的地址落在已安装的选择器之内。当请求从错误的接口发出时，它根本不符合隧道的条件。

通向客户端的路由是必要条件，而不是充分条件。策略必须允许你实际使用的那个源地址。

读已安装的策略，而不是配置文件

从当前的关联及其选择器入手，因为动态分配会改变内核中安装的内容。

ipsec statusall
ip xfrm policy

状态输出会列明连接、已分配的虚拟地址以及该对端当前生效的选择器。策略转储把同样的选择器显示为内核状态，而数据包选择真正查询的正是它。把网关侧的选择器与应用程序将要使用的源地址作对比，因为不匹配能立刻解释失败原因。要读取客户端当前的地址，而不是上一个会话的地址，因为重新分配的 VIP 会让旧策略失效。

客户端必须在数据包到达的地方监听

即使策略完美，只要服务只绑定到回环地址，数据包也会撞上关闭的端口。监听必须落在已分配的地址上，或者落在通配的本地地址上。

ss -ltnp 'sport = :9090'
iptables -S INPUT

套接字列表显示端口是否绑定到虚拟地址，防火墙规则则显示是否接受来自受保护源的新连接。为已建立连接编写的规则不会放行网关发起的连接。保留服务自身的认证，因为经由隧道到达只能确定数据包来自哪个网络。客户端位于自己的 NAT 之后时仍然不需要入站端口转发，因为这些请求都在现有隧道内部传输。

单独测试新方向

从客户端到服务器的正常请求从不会走这条路径。请从网关生成请求，并同时观察两端。

ip route get 10.90.0.42 from 192.168.50.1
tcpdump -ni any host 10.90.0.42 and tcp port 9090

路由查询会回答网关将使用哪个源地址和接口，而这正是策略必须允许的值。抓包应当显示请求在 ESP 内部发出，而不是以明文 TCP 出现在公网接口上。在客户端上抓取解密后的流量，以确认到达情况以及服务是否有回应。如果请求消失且线路上没有 ESP，应先怀疑源地址，而不是客户端的防火墙。

在密钥轮换或重新连接之后重复测试，因为 VIP 可能改变。只在下次会话之前有效的路径不算可用的路径。