IPSec VPN适用于哪些场景？

周五晚上十一点，老张还在办公室里盯着拓扑图发愁。

他是一家连锁餐饮企业的 IT 负责人，公司刚在三个城市新开了十二家门店，老板要求下周一开始，所有门店的收银系统必须实时把数据回传到总部机房。摆在老张面前的选择不少：拉专线？一条 2M 的 MSTP 专线月租就要上千元，十二家门店一年下来是笔不小的开支，而且开通周期动辄两三周，赶不上下周一。上云？收银系统是十年前的老架构，供应商明确说改造成本高、周期长。

老张最后选了 IPSec VPN。总部放一台防火墙做集中网关，每个门店用一台几百块的小型 VPN 路由器，通过门店现有的宽带拨号接入，建立 IPSec 隧道。周六一天配置调试，周日测试，周一早上八点，十二家门店的收银数据准时出现在总部的报表系统里。

这个场景，几乎每天都在不同的企业里重演。IPSec VPN 诞生至今已有二十多年，在 SD-WAN、零信任、SASE 这些新概念轮番登场的今天，它依然是企业网络里最"耐打"的技术之一。那么，它究竟适用于哪些场景？与其罗列干巴巴的条目，不如跟着几个故事走一遍。

场景一：多分支机构组网——"门店要连总部，但预算只有专线的零头"

老张的故事值得展开讲讲，因为它代表了 IPSec VPN 最经典、最广泛的应用场景：站点到站点（Site-to-Site）组网。

连锁零售、餐饮、银行网点、保险公司分支机构、制造业的异地工厂——这类企业的共同特征是：分支数量多、单点带宽需求不大、但数据必须实时汇总到总部。传统做法是租用运营商专线，稳定是稳定，可成本高、开通慢、变更难。一家门店搬迁，专线迁移要走半个月流程；而 IPSec VPN 只要门店有宽带，换个地方插上电就能重新拨通。

更关键的是，IPSec VPN 工作在 IP 层，对上层的应用完全透明。收银系统、库存系统、监控摄像头、考勤机，不需要任何改造，只要路由通了，它们就以为自己在一个局域网里。这对那些"系统老得动不了"的企业来说，几乎是唯一可行的方案。

当然，这个场景里有个细节常被忽略：分支网关的选择。老张用的是支持 IPSec 的小型路由器，配置简单；但如果分支规模再大一些，比如上百个网点，就需要考虑集中管理、隧道自动建立、链路备份这些能力。这时候，很多企业会选择在总部部署支持 DMVPN 或 Hub-Spoke 架构的汇聚设备，让分支隧道像拨号一样自动上线，运维人员不用逐台配置。这也是 IPSec VPN 生态里比较成熟的一套打法。

场景二：远程办公接入——"出差在酒店，也要像坐在工位上"

第二个故事来自一家设计公司。

李工是结构工程师，常驻项目现场。项目在外地，图纸存在公司内网的 NAS 上，用的是私有协议，没有公网入口。以前他的做法是让同事把图纸压缩发过来，改完再传回去，版本一多就乱套。后来公司 IT 给他配了一台支持 IPSec 的客户端，他在酒店房间里点一下连接，笔记本就"回到"了公司内网——NAS 能直接访问，内部的项目管理系统能打开，连打印机都能搜到。

这就是 IPSec VPN 的第二个主战场：远程接入（Remote Access）。

严格来说，远程接入更常见的是 SSL VPN，因为它客户端轻、浏览器就能用、权限粒度细。但 IPSec VPN 在这个场景里依然有不可替代的位置，原因有三个：

其一，网络层透明。SSL VPN 通常只能代理特定的应用或端口，遇到非 Web 协议、自定义端口、UDP 传输的业务系统，就容易抓瞎。IPSec 隧道建立后，客户端拿到的是一张虚拟网卡，所有 IP 流量都走隧道，什么协议都能跑。像李工访问的 NAS，用的是 SMB 协议加私有端口，SSL VPN 代理起来很别扭，IPSec 则毫无压力。

其二，客户端形态灵活。很多操作系统原生支持 IPSec（比如 Windows 自带的 VPN 客户端、iOS 和 Android 的系统级 VPN），企业不需要额外装软件，配置一个连接描述文件就能用。对 BYOD 场景来说，这点很实用。

其三，安全性有保障。IPSec 的加密和认证机制成熟，配合证书或预共享密钥，再加上 IKE 的密钥协商，整体安全强度足够应付大多数企业远程办公需求。

不过要提醒一句：远程接入场景下，IPSec 客户端和网关的兼容性是个坑。不同厂商的实现细节有差异，NAT 穿透（NAT-T）配置不对，客户端在酒店、机场这种多层 NAT 环境里就拨不上。所以选型时，客户端和网关最好同厂商，或者至少做过互通验证。

场景三：跨云与混合云互联——"机房和云上，得拉一条看不见的线"

第三个故事发生在两年前。

一家电商公司把部分业务迁到了公有云，但核心数据库还留在自建机房。云上的应用要读机房的数据，走公网不安全，走云专线又太贵——一条 100M 的云专线，月费加初装费，一年下来够买一辆车。他们的折中方案是：在机房出口的防火墙上配置 IPSec VPN，在云上买一个 VPN 网关服务，两边建立 IPSec 隧道，把 VPC 和机房内网打通。

这是近几年 IPSec VPN 增长最快的场景：混合云与跨云互联。

主流公有云厂商都提供 IPSec VPN 网关服务，按隧道计费，价格比专线低一个数量级。对于带宽需求在几十兆到一两百兆、对延迟不极端敏感的业务（比如数据同步、备份、测试环境互联、灾备切换），IPSec VPN 是性价比最高的选择。尤其是灾备场景：平时用 VPN 隧道做异步复制，真出事了一键切换，成本可控。

这个场景里有个技术要点值得展开：路由与网段规划。两边内网网段不能冲突，否则隧道建起来也通不了。很多企业上云时没规划好，机房用 192.168.1.0/24，云上 VPC 也用 192.168.1.0/24，结果只能改一边。所以实施前一定要做地址规划，这是 IPSec VPN 跨云互联最容易翻车的地方，比加密算法选型重要得多。

另外，跨云场景下经常需要多条隧道做冗余。云厂商的 VPN 网关一般支持双隧道，企业侧可以配两台设备分别对接，一条主用一条备用，配合 BGP 或静态路由做切换。这套架构搭好了，稳定性不比专线差多少，成本却只有零头。

场景四：那些"不太起眼但很要命"的边缘场景

除了上面三个主流场景，IPSec VPN 还在一些边缘场合默默发挥作用，值得单独提一笔。

临时项目组网。工程公司在野外项目部、影视剧组在外景地、会展公司在展馆布展——这些场景的共同点是"临时、短周期、地点不固定"。拉专线不现实，架设临时无线网桥覆盖有限，用 IPSec VPN 加 4G/5G 路由器，当天就能把现场和公司内网连起来，项目结束设备撤走，不留痕迹。

工业与物联网回传。工厂里的 PLC、数控机床、传感器网关，很多只提供以太网口，不支持装客户端软件。在边缘侧放一台工业级 VPN 路由器，把设备网段通过 IPSec 隧道回传到厂区中心，既解决了协议兼容问题，又满足了工控网络"不直接暴露公网"的安全要求。这类场景对设备的宽温、防尘、抗电磁干扰有要求，选型时要看工业级产品。

合规与等保需求。等保 2.0 里对"通信传输"有明确要求，跨广域网的敏感数据传输需要加密。IPSec VPN 是满足这类合规要求最直接的手段之一，配置成熟、审计友好，很多测评机构也认这套方案。

说回技术本身：它为什么还没被淘汰

讲完场景，不妨回头想想：SD-WAN 能智能选路，零信任讲究"永不信任、始终验证"，SASE 把安全能力搬到边缘，这些新架构听起来都比 IPSec VPN"先进"，为什么它还在大量场景里被选用？

原因其实很朴素。IPSec VPN 解决的是"网络层连通+加密"这个最基础的问题，而基础问题的解法往往最稳定。它不依赖特定应用、不需要改造业务系统、标准化程度高（IETF 的 RFC 摆在那里，各家实现大同小异）、设备成本低、运维人员熟悉。这些优势叠加起来，让它在"预算有限、系统老旧、周期紧张"的现实世界里，始终有一席之地。

当然，它也有明显的短板：配置复杂（尤其是多分支、多隧道的场景）、排错困难（IKE 协商失败的原因五花八门）、对动态路由和链路质量的自适应能力弱。所以实践中，很多企业会把 IPSec VPN 和 SD-WAN 结合——用 SD-WAN 做智能选路和集中管理，底层隧道仍然用 IPSec 加密。这不是谁取代谁，而是各司其职。

老张后来跟我说，他那套方案跑了一年多，十二家门店没出过大问题。唯一一次故障是某门店宽带欠费断网，隧道断了，收银系统自动切到本地缓存模式，续费后数据自动补传。"比我预想的省心，"他说，"早知道这么简单，去年就该做。"

技术的价值，有时候就体现在这种"做完之后没人再提起"的平静里。IPSec VPN 大概就是这样一种技术：不新潮，不喧哗，但在需要它的场景里，它一直在那儿。