strongSwan vips：向 IKEv2 请求虚拟地址

你的 IKEv2 客户端可以向网关请求一个内部地址，而由网关决定交回什么。在 strongSwan 中，这个请求就是 vips 设置；即使你在其中写入某个具体地址，它仍然只是一个请求。下面的操作手册会配置请求、加载它并读回结果，因为这三个步骤会以三种不同方式失败。它们没有一步会因为你输得更用力而变短。

vips 请求什么，又不能承诺什么

vips 属于连接定义之内，用于向响应方请求虚拟地址。strongSwan 的虚拟地址指南明确说明，回应可能是另一个地址，也可能什么都没有——而这正是人们写入一个值、期待它出现时会跳过的那句话。这个请求仍然值得发出，因为你要核实的正是回应。请把该设置当作去询问的指令，而不是对结果的配置。

请求 0.0.0.0 表示请求任意可用的 IPv4 虚拟地址，当具体值无关紧要时通常这样做是对的。请求某个具体地址只是给网关的提示，而不是对它的要求。

swanctl 片段及其所在位置

该设置位于连接块内部，不在独立文件里，也不在操作系统配置文件里。这个单独的片段展示了它的形态：

connections {
  net {
    local_addrs = 192.0.2.10
    remote_addrs = 203.0.113.5
    vips = 10.77.0.31
    children {
      net { local_ts = dynamic remote_ts = 10.77.0.0/24 }
    }
  }
}

用拥有该连接的文件加载它，然后发起连接并读取结果。把片段粘到错误的小节会产生解析错误，或者更糟：连接虽然加载了，却没有你以为已经发出的请求。按顺序运行这三条命令并保留输出。

swanctl --load-all --file /etc/swanctl/swanctl.conf
swanctl --initiate --child net
swanctl --list-sas

local_ts 选择流量，并不创建地址

local_ts 命名子 SA 所保护的流量集合；它并不会把地址放到接口上。一旦协商出虚拟 IP，strongSwan 就停止使用默认的动态选择器，改用被授予的地址。如果你把选择器钉死在一个字面地址上，你就是在断言网关可能并未授予的东西，这正是故障表现为 SA 正常工作、流量却不知去向的原因。选择器描述的是流量，而地址分配来自另一次交换。

获得稳定内部地址的另一种方式是在本地拥有它。在隧道建立之前把地址放到接口上，让选择器指向已经存在的东西，并围绕它安排对端和路由。

那种设计里没有任何协商，因此什么都不能被重新分配，这就是取舍：用确定性换取你自己完成地址工作。它是另一种机制，而不是 vips 的变体，因此两者不应混在同一个连接里。把钉死的选择器放在协商地址旁边，得到的连接会在网关分配别的东西时失效。

核实响应方实际分配了什么

读取 SA 列表，找到网关授予的地址，然后确认该地址确实存在于接口上。如果两者不一致，隧道是通的，但流量并没有去你以为的地方。授予的地址始终没有到达接口，是这一串步骤中最令人困惑的故障，因为每一半单独看都正确。

在笔记中分开记录四个地址：请求的内部地址、被授予的地址、机器的 LAN 地址，以及某个网站报告的公共出口。它们属于不同层次，出现在不同地方。把四个都记下来的手册，别人才能在不追问你指哪个地址的情况下照着做。每次重新加载后都要重新读取它们，因为被授予的值才是唯一描述当前隧道的值。

静态设计要单独保留

如果你需要固定的内部地址，就在网关上安排保留，并让客户端的请求保持为请求。把钉死的选择器与协商地址混用，会得到一个在网关分配别的东西之前可用的连接。把保留规则写在连接旁边，因为这是同事无法从配置文件推断的部分。这样新客户端会继承规则，而不是重新摸索。

在内置的 Mac 客户端上，这些选项名一个都不存在。使用网关提供的任何分配或保留，以及运营方发布的配置文件，并在读回分配结果之前，把客户端侧的任何值都当作提示。回滚就是删除 vips 行并重新加载，这会让你回到网关默认分配的状态。