面向 IPsec 网关的 WireGuard 配置：该改问什么

与沉默网关之间的握手超时，通常意味着两种永不相见的协议。WireGuard 对端说的是 Noise，而 IPsec 网关等待的是 IKE。地址和端口正确也改变不了这一点。

在配置中复用同一个端点并不能把两者桥接起来。下一步是向管理该网关的人提出请求。

第一项请求：协议版本

IPsec 是一族协议，而不是单一流程。IKEv2 与 IKEv1 在交换过程、认证选项以及网络切换时的行为上都不同。只终止 IKEv1 的网关，其表现会与提供 IKEv2 的网关截然不同。客户端配置也随之不同。

询问服务终止的是哪个版本，以及它运行的是基于标准的实现，还是带自有客户端的厂商变体。操作系统菜单常把这个答案藏在一个标签后面。标签并不等于协议。

第二项请求：客户端认证方式

认证才是真正大部分工作所在。服务可能要求具有特定扩展密钥用途的机器证书、用户证书、基于 IKEv2 的 EAP 方法，或与某个身份绑定的预共享密钥。到底适用哪一种，决定了客户端需要什么。

WireGuard 私钥不属于上述任何一种。它是在某一次特定握手中使用的 Curve25519 密钥。任何转换都不会把它变成证书或 EAP 凭据。声称能做到这一点的工具，只是在给文件改名，或生成无关的东西。

RFC 7296 中的 IKEv2 规范描述了该版本的实现必须支持什么。它是理解运营商含糊答复的参考，而不是客户端配置指南。

第三项请求：可信身份与目标网络

索取客户端必须看到的网关身份，以及用于验证它的信任锚。然后询问服务会下发哪些私有网段和解析器。这两个答案决定了隧道实际承载什么。

没有它们，连接即使建立也可能完不成任务。隧道建立起来却没有下发解析器，内部名称就得不到解析。缺少流量选择器，即使握手成功，目标也会留在隧道之外。

对端点做探测，回答的是与客户端报错不同的问题。端口可达但没有关联，指向认证问题；端口不可达，则指向路径问题。

# what does the endpoint offer on its IPsec ports?
sudo nmap -sU -p 500,4500 198.51.100.44

# strongSwan: what did the IKE exchange negotiate?
sudo swanctl --list-sas
sudo swanctl --list-conns

在改动客户端之前先做这项探测。如果端口有响应但关联仍然失败，问题在凭据或策略。如果完全没有响应，改配置也无济于事。

当两种协议必须共存时

同时管理两张网络，是保留两种协议的正当理由。常见设计是在不同接口或不同网关上分别终止 WireGuard 与 IPsec，然后在两者之间路由已批准的流量。

这种设计引入了信任与授权边界，应当明确记录为一条边界。哪些对端可以穿越、朝哪个方向、按谁的策略，属于路由和防火墙的决策。两种协议都不提供这些。

它不是透明转换。经 WireGuard 到达的流量会在 IPsec 隧道里重新发起，中间的每一条策略都会作用于它。

先弄清服务器对协议和认证的要求。再使用运营商支持的客户端和注册路径，并在此过程中让私钥远离网页转换器。