做企业网络这一行只要公司有多个办公地点或者业务上了云“两个内网怎么安全地连起来”这个问题迟早会落到你头上。早些年大家习惯拉一条运营商专线预算到位什么都好说可现在总部、分部、云上环境三地开花专线成本顶不住走公网又担心数据在链路上裸奔。这时候 IPSec 加密隧道就该登场了——它在公网之上架起一条加密通路把两边的内网严丝合缝地缝在一起让内网设备彼此“看不见”中间那段公开链路。这篇就把 IPSec 从协议原理到落地配置、从 IKE 协商到故障排查完整地捋一遍。内容适合刚接手企业组网的新手也适合被“SA 起不来”折磨过的老手复盘。我会尽量把每个参数“为什么这么设”讲透而不是甩一堆命令让你照抄同时在关键环节分享我自己踩过的坑。1. 为什么总部和分部要用 IPSec 把两张内网缝在一起1.1 专线、裸公网、加密隧道三条路的账怎么算先聊选型。企业把两个内网连起来本质上就三条路租运营商专线、直接走公网、在公网上叠一层加密隧道。专线比如 MPLS 专线质量最好延迟抖动可控但它按带宽收费一个 100M 的跨省专线月租往往四位数起步而且新增一个分部就要重新申请、重新等工期业务扩张一快就卡脖子。直接走公网最省钱问题是数据全是明文任何中间节点都能看到你的内部流量财务系统、数据库同步这类流量放上去等于裸奔。于是就有了第三条路——在公网之上用 IPSec 建立加密隧道。它的思路很简单两端的网关设备先协商好一套密钥和算法之后所有需要跨站点传输的内部流量都被网关抓出来、加密、再套上一层公网能识别的 IP 头通过公网送达对端网关对端解密后还原成原始内网包。整个过程对两边的终端完全透明终端该 ping 内网 IP 还是照常 ping感觉就像在同一个局域网里。成本上你只需要为公网带宽付费灵活性上新增分部只要对端网关配一段策略就能接入扩容极快。连接方式成本安全性灵活性典型适用场景运营商专线高按带宽计价高物理隔离低工期长核心交易系统、强合规要求裸公网直连极低无全程明文高临时测试、非敏感数据IPSec 加密隧道中公网带宽成本高端到端加密高策略配好即通多分部互联、云上内网打通这张表我建议你在做方案汇报时直接用它能让不懂技术的人一眼看明白钱花在哪、风险省在哪。专线不是不能选而是要用在刀刃上大部分办公互联、分支数据回传场景IPSec 加密隧道已经足够。1.2 IPSec 到底解决了哪些实际问题很多人对 IPSec 的理解停留在“加密”两个字其实它一口气解决了四个问题这也是它比简单加密工具更可靠的原因。第一是机密性通过对称加密算法如 AES把原始数据变成密文中间人抓包只能看到乱码。第二是完整性通过哈希算法如 SHA为每个包生成校验值数据在链路上被篡改一个比特对端都能发现。第三是身份认证两端的网关在建立隧道前必须互相证明身份证明不了就不让通道建立避免了“假冒对端”的中间人攻击。第四是抗重放IPSec 为每个加密包带上一个单调递增的序列号接收方维护一个滑动窗口重复收到的旧包直接丢弃防止攻击者把截获的历史报文重新发一遍来欺骗系统。这四项能力组合起来才让“在不可信的公网上跑可信业务”成为可能。理解这一点很重要因为后面配置里那些看起来繁琐的参数——加密算法、哈希算法、DH 组、密钥生命周期——其实每一项都对应着上面某个能力的实现细节。你把它当成一套“锁签名身份核验防重放”的组合拳来理解后面看配置就不会觉得是一堆无意义的字母数字。2. 把 IPSec 拆开看几个绕不开的协议组件2.1 AH 和 ESP 到底选哪个IPSec 不是单一协议而是一套协议族最核心的两个成员是 AH认证头和 ESP封装安全载荷。它们用不同的 IP 协议号来标识AH 是 51ESP 是 50。AH 的特点是只做认证不做加密它会把整个 IP 包包括外层 IP 头都纳入校验范围因此能防篡改、防伪造但数据本身还是明文。ESP 则既能加密又能认证不过它的认证范围不包括最外层 IP 头。那为什么实际项目里几乎清一色用 ESP关键就在于 NAT。AH 把外层 IP 头也算进校验可一旦数据包经过 NAT 设备源 IP 会被改写对端收到后一算校验值对不上直接丢包隧道根本跑不起来。ESP 不校验外层 IP 头天然对 NAT 更友好。所以除非是纯内网、完全无 NAT 的极特殊场景否则一律选 ESP。提示如果你在某些老设备的配置界面上看到 AH 选项先别急着勾先确认整条路径上有没有做地址转换否则大概率是白忙一场。2.2 传输模式与隧道模式别用错IPSec 有两种工作模式选错模式是新手最常犯的错误之一。传输模式是在原始 IP 包的基础上去保护它的载荷原 IP 头保持不变通常用于“主机到主机”的直接通信。隧道模式则是把整个原始 IP 包含原始 IP 头整体加密然后在外面重新套一个新的 IP 头新头的源和目的是两个网关的公网地址。站点到站点的互联必须用隧道模式。原因很直观内网用的是私有地址段比如 10.x.x.x这种地址在公网上根本不可路由网关必须把“私有地址的原始包”整个包起来套上公网地址的新头才能送出去。对端网关收到后再拆掉外层头、解密、还原出原始私有地址包转交给自己的内网。传输模式做不到这一点它没法隐藏原始内网地址公网上一传就丢。2.3 安全联盟 SA 和 SPI隧道真正的“身份证”IPSec 里有个核心概念叫安全联盟Security AssociationSA。你可以把 SA 理解成两端对“怎么加密、用什么密钥、用多久”达成的一份合同。重点在于SA 是单向的。也就是说从 A 到 B 的流量有一条 SA从 B 到 A 的流量是另一条独立的 SA。所以一条完整的双向隧道实际上对应着两条 SA。每条 SA 用一个叫 SPI安全参数索引的 32 位数字来标识它是接收方生成的会放进 ESP 头里。对端收到包后用“SPI 目的 IP 安全协议类型”这个三元组在自己的 SA 数据库里查找对应的解密策略。此外每条 SA 都有生命周期分软超时和硬超时软超时到了会提前协商新 SA 做平滑切换硬超时到了旧 SA 必须作废。这个设计保证了密钥不会长期不变降低被破解的风险。理解 SA 的单向性和生命周期对后面排查“单向能通、反向不通”这类问题至关重要。3. IKE 协商两个阶段报文究竟怎么跑3.1 阶段一先把管理通道建起来IPSec 的两端要建立数据隧道得先通过 IKE互联网密钥交换协议协商。IKE 协商分两个阶段阶段一的目标是建立一条“管理通道”也就是 IKE SA之后阶段二的协商报文都在这条通道里加密传输。阶段一有主模式和野蛮模式两种。主模式一共交换 6 个报文分三组先协商一套保护后续协商的算法套件再做 DH 密钥交换最后做身份认证。它的优点是身份信息全程加密安全性好缺点是报文多、握手慢。野蛮模式只用 3 个报文握手快但身份信息是明文传输的安全性弱一些。野蛮模式适用于对端公网地址不固定比如动态拨号的场景——因为它能在第一条报文里就带上身份标识主模式在地址不固定的情况下反而不好处理。实际项目里只要两端都是固定公网 IP优先用主模式。阶段一要协商的核心参数包括加密算法如 AES-256、哈希算法如 SHA-256、DH 组如 group 14/group 2、认证方式预共享密钥或证书。这四个参数两端必须完全一致任何一项对不上阶段一就协商失败隧道连门都进不去。3.2 阶段二数据通道的快速生成阶段一打通后就进入阶段二也叫快速模式一般 3 个报文。它的目标是为实际的数据流量协商出 IPSec SA在这个过程中会生成真正的加密密钥同时确定 SPI 值另外还会协商一个可选项 PFS完美前向保密。PFS 的作用是即使某一条 SA 的密钥被破解也推不出其他 SA 的密钥因为它每次都会重新做一次 DH 交换。开了 PFS 会更安全但会牺牲一点性能。阶段二需要协商的参数是加密算法、哈希算法、封装模式隧道/传输、SA 生命周期、以及是否启用 PFS。同样这些参数两端必须对齐。这里有个容易忽略的点——阶段二的加密算法可以和阶段一不同它们是完全独立的两套参数别把两者混为一谈。3.3 预共享密钥还是数字证书身份认证方式有两种主流选择。预共享密钥PSK就是两端配置同一个口令字符串配置简单、上手快适合中小规模、设备数量不多的场景。但它的短板也明显所有设备共用一个口令一旦某台设备配置泄露就得全网改密钥而且密钥没法按设备粒度吊销。数字证书则用 CA 签发的证书来做身份认证适合设备规模大、安全要求高的环境。它支持按设备吊销、支持密钥轮换但需要搭建或对接 CA 体系配置和维护成本更高。我的建议是二三十个节点以内的中小项目PSK 完全够用但口令一定要足够长且复杂上了规模、或者有合规审计要求就老老实实上证书。注意PSK 的口令千万别图省事用“123456”这类弱口令。我见过有人用公司简称当口令结果隧道被爆破内部流量被窃取教训非常深刻。4. 两台网关对接参数怎么定、配置怎么写4.1 地址规划与参数计算配置之前先把地址和感兴趣流规划清楚这一步做扎实后面能省一半的排查时间。我用一个典型场景来演示总部内网用 10.1.0.0/16分部内网用 10.2.0.0/16总部网关公网地址是 200.1.1.1分部网关是 202.1.1.1。“感兴趣流”是 IPSec 的核心概念指的是哪些流量需要走隧道。总部这边要定义为“源 10.1.0.0/16 到目的 10.2.0.0/16”分部那边则要精确镜像写成“源 10.2.0.0/16 到目的 10.1.0.0/16”。方向写反是新手最常见的错误直接导致协商失败。参数选择上我给一套稳妥的默认组合阶段一的 IKE 协商用 AES-256 SHA-256 DH group 14阶段二用 ESP AES-256 SHA-256PFS 打开用 group 14。这套组合兼顾了安全性和兼容性现在的设备基本都支持。如果你想兼容一些老设备可以再额外预留一套 AES-128 SHA-1 group 2 的备用参数作为协商回退。4.2 关键配置逐条拆解以常见的企业级网关命令行风格为例配置大致分五块定义 IKE 提议、定义 IKE 对端、定义 IPSec 提议、定义感兴趣流 ACL、定义 IPSec 策略并应用到接口。我逐条说明意图。第一块IKE 提议ike proposal 10 encryption-algorithm aes-256 authentication-algorithm sha2-256 dh group14这段定义了阶段一用的算法套件编号 10 只是本地标识符两端编号不用一致。第二块IKE 对端指认“跟谁协商、怎么认证”ike peer branch remote-address 202.1.1.1 pre-shared-key cipher MyStrongPsk2024 ike-proposal 10remote-address 指向对端公网地址PSK 两端必须一模一样注意大小写。第三块IPSec 提议定义阶段二的参数ipsec proposal branch-prop encapsulation-mode tunnel transform esp esp encryption-algorithm aes-256 esp authentication-algorithm sha2-256第四块感兴趣流 ACLacl number 3000 rule 5 permit ip source 10.1.0.0 0.0.255.255 destination 10.2.0.0 0.0.255.255第五块把前面几块串起来做成 IPSec 策略然后应用到公网出接口ipsec policy branch-policy 10 isakmp security acl 3000 ike-peer branch proposal branch-prop pfs dh-group14最后在出接口上ipsec policy branch-policy引用即可。整个过程的关键是ACL 决定“谁走隧道”IPSec 策略把 IKE 对端、提议、ACL 绑在一起接口引用决定“从哪个口出去”。三者的关系理顺了配置就不会乱。4.3 上线验证与抓包配置写完别急着庆祝一定要做验证。第一步看 IKE 状态display ike sa应该能看到阶段一的 SA 处于已建立状态第二步看 IPSec 状态display ipsec sa能看到具体的 SPI、加密算法和加解密包计数。第三步从总部内网发ping到分部内网地址能通说明数据面通了。最有效的验证手段是抓包。在公网接口上抓包你应该能看到 IKE 的 UDP 500 端口协商报文以及后续数据面上的 ESP 报文协议号 50。如果你能看到 ESP 包说明隧道确实在工作如果只有协商报文没有 ESP那多半是感兴趣流没匹配上或者 ACL 写反了。抓包时注意看两端的加解密包计数是否同步增长如果一端一直在加密发送、另一端解密计数始终为零那就是单向 SA 没建起来。实操心得验证时先ping小包再ping大包比如ping -s 1400。很多问题只在大包上暴露小包能通不代表隧道完全正常这一点后面排错部分会详细讲。5. NAT 穿透与故障排查实录5.1 NAT-T 为什么必须懂现实中两端网关的公网地址很少直接暴露在互联网上中间往往会经过运营商的地址转换设备。前面说过 ESP 不校验外层 IP 头所以地址被改写本身不致命但另一个问题来了ESP 是三层协议没有端口号NAT 设备做端口映射时找不到端口无法为它建立映射表项回程包就可能送不回来。解决办法就是 NAT-TNAT 穿透。它的原理是把 ESP 包整个封装进 UDP 里用 UDP 4500 端口传输这样 NAT 设备就能基于端口建立映射了。NAT-T 的检测是在 IKE 阶段一自动完成的——两端会发现彼此之间存在 NAT然后自动切换到 UDP 封装。需要提醒的是NAT-T 生效后NAT 设备上的会话老化时间可能会影响隧道保活建议配合开启 IKE 的保活机制DPD定期发心跳包维持映射表项。5.2 常见故障速查表下面这张表是我多年排查经验的浓缩遇到问题先对照它缩小范围能省下大量时间。故障现象最可能的原因排查方向阶段一 SA 起不来算法/DH组/PSK/对端地址不一致核对两端 IKE 提议每一行参数阶段一通了阶段二不通感兴趣流 ACL 写反或不镜像检查两端 ACL 源目方向单向能通反向不通反向 SA 未建立或 ACL 不对称看两端 SA 状态和加解密计数小包通大包丢MTU 问题或分片被丢弃调小 MTU检查分片处理隧道频繁闪断DPD 保活未开或会话老化开启 DPD检查中间设备老化时间重启后隧道不通配置未持久化或顺序问题检查配置保存和接口引用5.3 我踩过的坑帮你避一避第一个坑是 PSK 大小写不一致。有次我复制粘贴配置一端是大写开头一端是小写肉眼根本看不出来愣是排查了两个小时。后来养成习惯PSK 统一用配置管理工具下发绝不手敲。第二个坑是 DH 组不匹配。阶段一两端的 DH 组必须完全一样有一次对端工程师把 group14 写成了 group2协商报文能发出去但建立不了 SA日志里报的错又很含糊最后是抓包看协商报文的 proposal 才定位到。第三个坑是 MTU 和分片。隧道封装会给每个包增加额外的头部开销ESP 头、外层 IP 头加起来几十字节如果链路 MTU 是标准的 1500原始包太大时封完就超过 MTU需要分片。如果中间设备禁止分片或者对分片处理不当就会出现小包通、大包丢的怪现象。解决办法是适当调低隧道接口或内网接口的 MTU或者启用 TCP MSS 调整让终端主动生成更小的包。第四个坑是时间不同步。如果用了证书认证两端时间偏差过大会导致证书校验失败隧道建立不了。所以证书场景下务必保证两端的时钟同步。第五个坑是配置了策略却没生效。IPSec 策略必须显式应用到出接口而且 ACL 的匹配顺序会直接影响结果——如果有一条放行所有流量的规则排在了感兴趣流规则前面那你的流量根本不会被 IPSec 策略抓取自然也就不会走隧道而是明文出去了。这个坑最隐蔽因为表面上“网络是通的”只是没加密你根本意识不到。提示每完成一个配置阶段就做一次验证别等全部配完再一起测。分级验证能把故障范围快速锁定在某一块排查效率翻倍。最后分享一个我在实际项目里的习惯给每条隧道都配一份“配置档案”记录两端的公网地址、内网段、算法套件、PSK 标识、ACL 内容和上线日期。隧道一多人脑记不住全靠档案对账。之前有次一个分部搬迁换了公网地址我翻档案五分钟就改完了配置而隔壁没做档案的团队排查了一整天。IPSec 这东西配置本身不难难的是把它管清楚、排得动把参数对齐和记录做好你就赢了一大半。