OPNsense IKEv2 远程接入：证书、地址池、客户端与排障

一个可用的 IKEv2 远程接入系统，需要同时解决四件事：客户端确认 VPN 服务器身份，服务器验证用户，为客户端分配虚拟地址，以及让隧道中的流量按防火墙、路由、NAT 和 DNS 策略到达目标。看到“已连接”只证明协商走到某一步，不能证明访问范围和 DNS 路径都正确。

本文依据 OPNsense / Deciso 的 IPsec – Roadwarriors IKEv2 全文翻译整理，同时覆盖共享地址池与逐用户固定地址池，不将客户端系统拆为多篇。核对日期为 2026 年 10 月 05 日。研究页记录的界面核验版本为 26.7.4_1；本次读取的是动态官方文档，没有连接该版本设备进行测试。

所有地址、域名和用户均为文档示例，必须替换为自己的规划。原文中的固定演示密码已移除，用户密码应强、独立且通过受控方式分发。本文中的命令和配置只做静态审查，未生成、导出或读取任何真实私钥，也未更改网络设备。

网络与证书准备

示例服务器名称为 vpn1.example.com，用户为 John 和 Laura。公网 DNS 的 A 记录指向 203.0.113.1，AAAA 记录指向 2001:db8:1234::1。这些地址必须是防火墙实际可绑定且客户端可到达的地址。IPv6 可以不部署，但若客户端本身有双栈网络，仍要明确未入隧道的 IPv6 和 DNS 应如何处理。

在 System → Trust 建立或导入受控的 CA 和服务器叶证书。主教程命名 CA 为 IPsec CA、叶证书为 vpn1.example.com。它链接的 证书链教程说明了根 CA、可选中间 CA 和叶证书的关系；服务端证书应选服务器用途，DNS Alternative Names 与实际连接名匹配，密钥算法、有效期和签名算法按组织策略及客户端支持选择。

客户端导入的是可信 CA 的公开证书，不是服务器私钥。根 CA 私钥应离线保护，叶证书私钥仅交给实际服务端；证书轮换、吊销及到期需要单独维护。不要关闭服务器证书验证来解决认证故障。

进行网络变更前，保留独立控制台，导出加密 XML 配置备份，并记录接口映射和现有服务状态。菜单与 Source NAT 行为需要按所用发行版及 26.7 迁移说明核对；回退后还应复查接口、服务和同一条端到端访问测试，不能仅以界面能登录作为恢复完成。

WAN 入口只承担隧道建立

先建立主机别名 host_vpn1_example_com，包含示例服务器 IPv4 和 IPv6 地址；再建立端口别名 port_ipsec_500_4500，内容为 UDP 500 与 4500。WAN 入站规则设为 Pass、IPv4+IPv6、UDP，目的为服务器别名，目的端口为该端口别名。

本教程明确启用 UDP encapsulation，ESP 会封装在 UDP 中，因此这里不另开原生 ESP 协议规则。若采用不同的封装方式，就不能机械沿用这一判断。原文来源为 Any，适用于地址经常变化的远程用户；若业务允许固定来源，进一步限制来源范围。

两种地址池方案只能选一种

共享池方案配置简单，兼容多数客户端；逐用户固定池方案便于用源地址为不同用户建立访问规则，但配置数量随用户增加，原生 Windows 客户端的 EAP 身份交换也不如共享池适配。

不要同时配置两种方法。原文提醒两者会出现认证匹配重叠。使用 EAP Id: %any 的共享连接也只建立一条；建立多条同样的通配连接，可能使任一合法 EAP 身份匹配不希望它使用的连接。

方法一：所有用户共享地址池

在 VPN → IPsec → Connections → Pools 创建：

这里的前缀表达租赁地址池，不是一个广播子网。原文给出的 IPv4 /24 和 IPv6 /120 各包含 256 个可租用地址；IPv6 池不应误写为整个 /64。官方还提醒 StrongSwan 池的硬边界为 /97，较大的地址规模应查阅实际版本限制。DNS 地址通过 Configuration Payload（RFC 4306、RFC 7296 §3.15）推送；不想推送 DNS 时可留空，但仍须有明确的客户端解析策略。

在 VPN → IPsec → Pre-Shared Keys 中为每个用户建立类型为 EAP 的记录。Local Identifier 为 john@vpn1.example.com 或 laura@vpn1.example.com，Pre-Shared Key 字段填各自新生成的独立密码。这里的 EAP 密码不要与整条 IKE 隧道的传统 PSK 认证混淆。Remote Identifier 可填 vpn1.example.com；原文指出 Android 原生客户端需要这一对应关系，其他客户端有匹配问题时需结合日志调整。用户名也可以是简单字符串，但带服务器域名更方便区分多套服务。

启用 IPsec 并应用，然后添加一条 Connection，打开高级模式：

保存后，Local Authentication 设 Round 0、Public Key、Id 为服务器域名、Certificates 为服务器叶证书。Remote Authentication 设 Round 0、EAP-MSCHAPv2、EAP Id 为 %any。

再添加 Child，Start action 设 None，ESP proposals 为 aes256-sha256-modp2048 并取消 Default。全隧道的 Local traffic selectors 为 0.0.0.0/0 与 ::/0；仅访问内部网络的分流方案则填写 LAN 网段。Child Rekey time 原例为多数客户端 600 秒，Windows 原生客户端为 0。保存并应用。上述算法与时间是原文互相配套的示例，改变服务端后也须调整客户端，不能将它们视为任何终端组合的通用配置。

方法二：每名用户使用固定地址池

在这种方法中，每人建立独立池，并为每人建立独立 Connection：

DNS 与方法一相同。若同一用户有多台设备，可分配更大池，例如 /31 含两个 IPv4 地址、/127 含两个 IPv6 地址；这是地址租赁池语义，管理员必须自行保证各池不重叠。

EAP 用户记录与方法一相同。John 的连接使用自己的两个池，Remote Authentication 的 EAP Id 明确填写 john@vpn1.example.com；Laura 对应填自己的身份和池。其他 IKE、证书及 Child 配置与前述示例一致。可以克隆连接，但必须逐项修改池、EAP Id 和描述，不能留下共享的 %any 身份。每增加一名用户，都要建立匹配的新池和连接。

客户端配置与兼容性

客户端从服务端 Configuration Payload 获取虚拟地址、流量选择器和 DNS 信息，但不同客户端的处理方式需要验证。所有设备都应先信任正确的 CA，再核对服务器名称及远端身份。

Windows 10/11 原生客户端

官方推荐方法一。方法二中原生客户端首次交换不发送预期的本地身份，原文记录了可能要求重复输入密码，以及取消认证窗口后需重启才能再次连接的行为。这是原文兼容性记录，不是本文在当前 Windows 补丁上的重现实验。

以下为原文 PowerShell 配置的整理版：移除了直接抑制确认的 -Force。它们会创建或修改 VPN 配置，不是只读检查。示例针对当前用户配置；管理员身份本身不等于所有用户配置，计算机范围配置还需核对相应 cmdlet 的 -AllUserConnection 参数与权限。

Add-VpnConnection -Name "vpn1.example.com" -ServerAddress "vpn1.example.com" -TunnelType "Ikev2"
Set-VpnConnectionIPsecConfiguration -ConnectionName "vpn1.example.com" -AuthenticationTransformConstants SHA256 -CipherTransformConstants AES256 -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -PfsGroup PFS2048 -DHGroup Group14 -PassThru

确认配置使用与服务端相同的 EAP-MSCHAPv2 用户认证。若明确采用分流，才开启 SplitTunneling 并添加 LAN 路由：

Set-VpnConnection -Name "vpn1.example.com" -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName "vpn1.example.com" -DestinationPrefix "192.168.1.0/24" -PassThru
Add-VpnConnectionRoute -ConnectionName "vpn1.example.com" -DestinationPrefix "2001:db8:1234:1::/64" -PassThru
(Get-VpnConnection -ConnectionName "vpn1.example.com").Routes

修订说明：原文这一段的 IPv6 路由使用了另一组 fe0d:… 地址，本文已统一为前面的 LAN 示例。删除路由的原文命令 Remove-VpnConnectionRoute 会实际改变配置，应仅用于撤销准确匹配的路由，不能把删除步骤混进常规验证。

导入 CA 时，可使用 MMC 的 Certificates 管理单元，选择 Computer account → Local computer，把 CA 公共证书导入 Trusted Root Certification Authorities。此操作需要相应管理权限，会扩大本机信任范围，因此只能导入已经核对来源和指纹的 CA。连接时输入自己的用户名及密码。若 DNS 推送没有生效，在 VPN 适配器的 IPv4/IPv6 属性中核对 DNS；原例分别为 192.168.1.1 和 2001:db8:1234:1::1。

iOS 与 Android

iOS 原生配置中，类型为 IKEv2；Server 和 Remote ID 均为 vpn1.example.com；Local ID 与 Username 均为 john@vpn1.example.com；Authentication 选择 Username，并填写自己的密码。原文提示其示例 iOS 客户端忽略 DNS Configuration Payload，提出手动调整 Wi-Fi DNS 的办法。本文保留为兼容性提示：应在目标 iOS 版本检查实际 DNS 路径，不把“已推送 DNS”当作“已采用 DNS”，也不假定手动 Wi-Fi 设置可以覆盖蜂窝网络和所有解析情形。

Android strongSwan 客户端选择 IKEv2 EAP，服务器、用户名、密码和 CA 与前述对应；高级设置的 IKEv2 Algorithms 和 IPsec/ESP Algorithms 均为 aes256-sha256-modp2048。连接失败时查看应用日志。

Android 原生客户端选择 IKEv2/IPSec MSCHAPv2，Server address 为服务器域名，IPSec identifier 在原例中留空，IPSec CA certificate 选导入的 CA，server certificate 选 Received from server。服务端 EAP 的 Local Identifier 必须是用户名，Remote Identifier 必须匹配服务器地址；原文称不匹配会使认证失败。

NCP Secure Entry 客户端

Windows/macOS 的 NCP 客户端是独立商业产品，需要许可证，与 OPNsense / Deciso 没有从属关系。原文提供的是 13.14 Build 29669、导出时间为 2023-09-11 的 INI。其有效内容包括：服务器域名、用户 IKE 身份、AES-256/SHA-256、DH/PFS 组 14、IKE 2400 秒、IPsec 600 秒、UDP 500/4500、DPD 30 秒，以及由服务端分配地址和 DNS 的行为。

导入流程为 Profile → Import Profile，选 INI 文件，输入自己的 EAP 用户名和密码。将 CA 公共证书放入该客户端证书存储；原文 Windows 路径是 C:\ProgramData\NCP\SecureClient\cacerts。macOS 应按实际安装版本的受支持路径定位，不必照搬原文以 root 权限遍历整个文件系统的查找命令。

安全审查：原 INI 还含 AntiReplay=0、Firewall=0、OnlyTunnel=0 等安全相关字段。其数值语义和新版本兼容性没有在本次通过供应商配置规范验证，因此不能当成加固模板导入；本文没有凭字段名自行改成 1。完整原始静态配置保存在交付附件 evidence/ncp-original-13.14.ini.txt，供审校比对，不属于已测试配置。当前客户端应通过受支持界面重新核对防重放、流量旁路、证书和密码保存选项，并检查 Help 下的日志。

让隧道内流量受控地到达 LAN 与互联网

WAN 放行 IKE 端口之后，还需在 IPsec 接口建立内层访问规则。共享池使用整个远程池作为来源；固定池可为 John、Laura 建立独立主机别名，以各自 /32 与 /128 地址限制访问。

原文创建 net_pool_roadwarrior，含 IPv4 /24 和 IPv6 /64；本文建议与实际租赁池保持一致，在共享池场景用 IPv6 /120，避免把未分配的更大地址范围也列入允许来源。若实际方案确实分配更大范围，则应据设计调整。

1. 为诊断增加范围有限的 ICMP 规则：来源为实际远程池，目的为 This Firewall。原文来源为 Any；本文收紧为远程池。客户端也只能访问 Child 的本地流量选择器所涵盖的地址。
2. 建立 LAN 访问规则：来源为远程池或单个用户别名，目的为授权 LAN 网段或服务，协议和端口按业务需要设置。原文 TCP/UDP 到整个 LAN、任意端口属于宽范围演示，不能等同于最小权限。
3. 全隧道需要互联网出口规则，且仍应防止绕过前面的内部访问限制。原文借助反向匹配的地址别名区分互联网和本地范围；不要把 Destination 简单设为 Any。

原文名为 InternetIPv4 的别名其实包含 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16 和 127.0.0.0/8，通过 Destination / Invert 取反；InternetIPv6 则包含自身 IPv6 前缀。注意这不是完整的“互联网地址清单”：如果内部使用公网地址、还有其他受保护网络或特殊地址范围，也须纳入排除策略。不能用一个历史示例别名自动证明内网隔离。

IPv4 全隧道访问互联网时，需要在 Firewall → NAT → Source NAT 配置源地址伪装。至少启用 Hybrid Source NAT rule generation 以允许手工规则；示例的 WAN、IPv4、来源为远程池、目标为任意、Translation target 为 WAN address。原文现行页面还列 Direction In，该字段和新旧 NAT 界面语义需按当前版本核对，不跨版本照抄。IPv6 示例依赖正常路由及防火墙策略，不能自动套用 IPv4 NAT 做法。

若内部服务的 DNS A 记录指向公网地址，还可能需要 Reflection NAT。原文提示在相关 Destination NAT 规则中纳入 IPsec 接口；是否需要反射，要结合内外 DNS、服务实际地址和现有 NAT 设计判断。

DNS 与双栈泄露需要单独验证

可以让远程客户端使用防火墙上的 Unbound，或组织内已有 DNS。内部名称若交给外部公共 DNS，既可能无法解析，也会把内部名称查询发给外部解析器。Unbound 的示例 DNS 地址为 LAN 的 IPv4 与 IPv6 地址；内部 Samba / Microsoft Active Directory 解析可通过 Query Forwarding 按实际域和服务器配置。

原文建议 Unbound 的 Network Interfaces 保持 All，监听 UDP/TCP 53。该监听设置必须与访问控制、防火墙规则同时评估，不意味着应将递归解析暴露到 WAN。无需内部名称或目录服务时，可以省去相应内部转发配置，但仍不能省略对客户端 DNS 实际路径的核对。

只推送 0.0.0.0/0 的 IPv4 全隧道，不会自动覆盖 IPv6。双栈客户端可能继续使用本地 SLAAC / DHCPv6 获得的 IPv6 DNS。若目标是完整的双栈全隧道，须同时规划 ::/0、IPv6 地址租赁、服务器路由、出口规则和客户端行为；也要检查断隧道时的流量。原文“全隧道不会泄露”的概括不能替代这些检查。

按协商路径排障

1. 确认已经启用 IPsec 并 Apply，服务端证书有效，公网 DNS 指向可达地址。
2. 在发起连接期间，观察服务器入口是否收到 UDP 500/4500。没有包时检查客户端目标地址、上游设备和双方防火墙；有入无出时继续看 IPsec 服务端日志。
3. 对照服务端 VPN → IPsec → Log File 与客户端日志，核查提案不匹配、证书名称/信任、EAP 身份、密码、池和流量选择器。原文列出 /var/logs/ipsec/latest.log 路径，本次未核验设备上的实际路径，以当前 GUI 和版本日志配置为准。
4. 协商成功后，核对虚拟地址是否属于预期池，随后分别检查 LAN 访问、禁止访问目标、IPv4 出口、IPv6 出口和 DNS 查询。用已授权的目标进行最小必要检查。
5. 验证重连、重协商和回退后的行为。不要把一次“Connected”图标当成地址、访问控制和 DNS 都已正确的证明。

服务端和客户端日志通常需要联合分析。日志、抓包和配置备份可能包含身份与内部网络信息，应限制保留和分享范围。本次没有抓包、连接 VPN 或运行上列命令，因此没有可报告的联通性或安全测试通过结论。

来源与许可

原文维护/发布方：OPNsense / Deciso B.V.，页面无可确认个人署名。本文为中文翻译整理，附加了明确标示的安全和版本修订；原文 Windows IPv6 路由、过宽池别名、ICMP 来源及固定密码已按上述说明修订，NCP 历史完整 INI 保留在审校附件。文档依据 BSD 2-Clause 文档许可发布，保留以下声明：

Copyright 2016-2026, Deciso B.V.
Deciso B.V. All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

THIS DOCUMENTATION IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OPNSENSE DOCUMENTATION PROJECT BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.