山海寻川
1. 案例背景
某企业设有总部与分支机构，两者服务器需实现跨区域数据互通。为保障数据传输过程中的安全性与保密性，企业决定采用 IPsec VPN 主模式进行连接配置。其中，总部服务器配置固定IP地址，分支服务器因网络环境限制采用动态IP地址。
2. 配置需求
网络互通：确保总部与分支服务器之间能正常建立网络连接，实现数据传输互通。
连接模式：采用IPsec VPN主模式进行协商，通过完整的身份认证与密钥交换流程提升连接安全性。
数据安全：对跨区域传输的所有数据进行加密处理，保障数据的保密性、完整性与防篡改能力。
身份认证：配置严格的身份认证机制，杜绝非法设备接入VPN通道。
稳定性：分支IP地址变更时，VPN连接需能自动重新协商，保障数据传输不中断。
3. 案例拓扑
4. 配置步骤
需确保 Server1与Server2的互联网可达性，核心及防火墙的网络基础配置在此不再赘述，我们直接进入IPsec VPN的配置环节。
4.1 防火墙创建IPsec VPN策略（总部）
4.1.1 场景中点到点与点到多点的区别
点到点（本案例采用此方式）
点到点VPN本质是为两个独立私有网络搭建加密 “专属通道”，通过双方VPN网关建立IPSec隧道实现互联互通，也被称为局域网到局域网VPN（LAN to LAN VPN）或网关到网关VPN（Gateway to Gateway VPN）。
访问发起规则
单向访问：本地网关主动访问对方时，远程网关需配置固定IP地址或可解析域名。
双向访问：两端网关均配置固定IP地址或域名，双方可互相主动发起访问。
配置前必做准备
获取远程网关标识：确认对方VPN网关的固定IP地址，或能正常解析的域名信息。
确定身份验证方式：双方管理员协商，选择预共享密钥（约定专属字符串）或RSA签名证书认证体系。
明确目标网段范围：锁定需要访问的远程私有网络地址段，即对方内部需互通的设备地址区间。
点到多点（适用于多个分支）
点到多点IPSec主要用于总部与多个分支、移动终端（出差员工设备）建立加密连接，通过总部VPN网关与多个节点（分支网关、便携设备等）搭建多条IPSec隧道，实现所有节点与总部私网的互联互通，常见于总部与出差员工的VPN连接场景。
访问发起规则
总部需具备固定 IP 地址或可解析域名，作为连接的核心接入点。
分支网关、移动终端（手机、电脑等）IP地址通常不固定，需由这些节点主动向总部发起访问请求。
配置前必做准备
确认接入设备类型及对应协议：VPN网关使用IPSec协议，移动客户端常用L2TP over IPSec 协议或IKEv2 协议。
协商身份验证方式：总部管理员与接入方确定，采用预共享密钥（约定专属字符串）或RSA签名证书认证体系。
配置用户组及认证机制：创建对应用户组并设定认证方式，确保移动终端接入时的合法性验证。
设定私网IP分配范围：总部需提前规划地址段，为接入的节点分配私网IP，保障其与总部内网设备正常通信。
4.1.2 虚拟系统配置（选择默认public）
虚拟系统（Virtual System）是在一台物理设备上划分出的多台相互独立的逻辑设备，你可以从逻辑上将一台FW设备划分为多个虚拟系统。每个虚拟系统相当于一台真实的设备，有自己的接口、地址集、用户/组、路由表项以及策略，并可通过虚拟系统管理员进行配置和管理，虚拟系统具体详细内容不在本文阐述，这里选择默认即可，后续会单独写篇文章具体介绍。
基本配置
策略名称：可自定义配置，配置多条策略时不能重复。
本端接口：选择与对端设备相连的接口（也就是连接运营商侧的接口），此接口用于和对端建立隧道。
对端地址：若分支为动态IP地址，分支则需配置总部公网固定IP地址，总部侧无需配置。若分支有固定公网IP地址，则总部与分支均需要指定对端地址。
认证方式
预共享密钥：双方提前约定一个 “暗号密码”，连接时互相验证这个密码，一致就通过。优点是配置简单，适合小网络。（本案例使用的此方式）
RSA 签名：用 “公私钥对” 验证身份，自己用私钥签名，对方用公钥验签。安全性高，但配置稍复杂。
RSA 数字信封：先加密 “数据密钥”，再用该密钥加密数据，双重加密保障安全。是三者中最安全的，但配置和管理最复杂。
本端ID：可以选择以IP地址或名称的方式，名称及可解析的域名，用于没有固定公网IP的场景。这里的本端ID要与对方的对端ID相同。
对端ID：可以选择以IP地址或名称的方式，名称及可解析的域名，用于没有固定公网IP的场景。这里的对端ID要与对方的本端ID相同。
待加密的数据流配置说明
主要用于配置需要通过IPSec隧道传输的数据流规则。
规则匹配机制：可配置多条规则，流量将按照 “从上到下” 的顺序依次匹配；若某条规则匹配成功，将直接依据其动作进行处理，不再继续匹配后续规则。
对端镜像规则要求：在IPSec对端设备上需配置镜像规则，除 “源” 与 “目的” 的地址/端口呈反向关系外，其余参数需完全一致。具体对应关系如下：
对端 “源地址/地址组”/“源端口” ↔ 本端 “目的地址/地址组”/“目的端口”
对端 “目的地址/地址组”/“目的端口” ↔ 本端 “源地址/地址组”/“源端口”
反向路由注入（RRI）
主要用于IPsec VPN场景中自动将对端VPN子网的路由注入本地路由表。
作用：确保VPN流量通过加密隧道转发，实现对端子网的通信。
优先级：决定路由选择的优先级（通常数值越小优先级越高），避免路由选择冲突。
解决的问题：
无需手动配置对端子网的静态路由，解决路由缺失问题。
通过优先级设置，确保 VPN 路由优先生效，解决路由选择冲突导致的流量转发异常问题。
4.1.3 安全提议（无特殊需求按默认配置）
IKE和IPSec的作用介绍（这两个分工协作，缺一不可）
两者是保障IP数据安全传输的 “黄金搭档”，IKE负责 “前期筹备”，IPSec负责 “实际执行”，全程协同完成从安全协商到数据保护的完整流程，具体关联可拆解为3个关键环节：
1. 启动阶段：IKE为IPSec“扫清障碍”
IPSec本身没有协商能力，无法自行确定和谁通信、用什么加密规则、靠什么密钥加密。这时候IKE先登场：
先做 “身份核验”：确认通信双方是合法对象（比如企业总部和分支网关），避免 “冒充者” 接入。
再定 “安全规则”：协商好后续IPSec要用的加密算法（如AES-256）、认证算法（如SHA2-256）等参数。
最后 “配送钥匙”：通过安全方式生成并交换会话密钥，同时建立 “安全关联（SA）”—— 相当于双方签字确认的 “安全操作手册”，明确所有防护规则。
2. 传输阶段：IPSec按IKE的 “手册” 干活
IKE完成筹备后，IPSec正式接手数据保护工作：
严格遵循SA中的规则，用IKE提供的密钥对IP数据包加密（防止数据被公网窃取）。
按约定的认证算法校验数据（确保数据没被篡改，且来自合法方）。
比如用ESP协议封装加密后的数据包，全程按照IKE定好的 “规矩” 执行，不用再额外协商。
3. 维护阶段：IKE为IPSec “更新保障”
为了避免密钥长期使用导致安全风险，IKE会定期 “续约”：
自动重新协商新的密钥和SA，替换过期的参数。
IPSec无缝衔接，直接沿用新的 “安全手册” 继续工作，全程不中断数据传输的安全性。
4.2 防火墙创建IPsec VPN策略（分支）
场景的配置分支防火墙与总部配置大相径庭，除对端地址填写为总部的固定公网IP以外其他配置均与总部相同。
待加密的数据流配置源地址要配置为本地服务器的网段，与总部配置相反。
4.3 防火墙创建安全策略（总部）
安全策略中需放通分支到总部的安全策略，允许分支到总部防火墙本地的 IKE 报文及加密数据流报文。
在 IPsec VPN 场景的 NAT 策略配置中，除上网策略对应的地址转换规则外，需对总部服务器网段专门配置 no-nat 策略（即不执行地址转换）。若该网段被执行 NAT 转换，其流量转发至分支时会被转换为公网地址，将导致 IPsec VPN 加密数据流无法完成匹配，进而影响 VPN 隧道正常通信。
4.4 防火墙创建安全策略（分支）
分支与总部的防火墙安全策略规则保持一致，双方均需配置放通 IPsec VPN 流量至防火墙本地及业务网段的访问规则。两者的核心差异在于：双方规则中的源 IP 地址与目的 IP 地址呈反向对应关系（即一方的源IP对应另一方的目的 IP，反之亦然）。
NAT 策略配置内容与总部一直，两者的核心差异在于：双方规则中的源 IP 地址与目的 IP 地址呈反向对应关系（即一方的源 IP 对应另一方的目的 IP，反之亦然）。
5. 验证测试
Server1 测试结果
Server2 测试结果
