面向总部与分支之间的公网统一安全对接方案

• 多分支机构公网接入办公网总部,或者接入机房.
• 网络全通,任意 IP 有能力访问任意网段
• 设备冗余
• 链路冗余
• 故障自动并快速切换,最好用户无感知
• 能够适应多种不同网络环境
• 统一配置模板
• 简化配置部署
• 具有较高安全加密功能
• 能够区分流量走不同的链路,同时某条链路故障了又可以自动切换
• 日后升级设备可以无缝替换,网络不中断
• 能够做地址转换,打通多个相同网段的网络
• 能够平滑的横向扩展接入能力
• 部署起来性价比高
• 优化分支机构的路由,避免过多路由
• 便于监控,能够抓取不同 VPN 流量

理想很完美,现实很骨感,总结起来就是用最少的钱实现最牛逼的效果,老板们的脸上乐开了花.

让我们先看看分支机构通过公网接入一般会有哪些网络场景?

多种不同网络环境如下：

选型思路

公网对接首要考虑的是安全,比较安全可靠的三层 VPN 类型有 IPsec、SSL VPN、L2TP over IPsec,鉴于我们的适用场景是 Site to Site,所以决定采用 IPsec VPN.这里我们对 IPsec 稍微多介绍一点,但是也不过多展开,网上资料一大堆,欢迎大家自行了解.我也在很多公司场景里见到使用 IPsec VPN,但是见到最多的用法为 IPsec VPN + Static Route,最多再加个 track 做切换,这样有一些缺陷,而且不便于大规模网络扩展,我们其实可以把 IPsec 用得更好.

IPSEC 协议：

IPsec 存在两种安全协议,一种是 AH(Authentication Header),一种是 ESP(Encapsulating Security Payload),其中 AH 只能做数据源验证、数据完整性校验、防报文重放功能,不具备数据加密功能,所以我们必须选用 ESP 协议. ESP 可以提供加密、数据源验证、数据完整性校验、防报文重放、穿越 NAT 功能,正好能满足我们不同网络对接模型.

常用加密、验证方法：

无论是加密还是验证方法,两端的安全提议保持其中一组一致即可.

• 数据来源验证：接收方验证发送方身份是否合法.
• 数据加密：发送方对数据进行加密,以密文的形式在Internet上传送,接收方对接收的加密数据进行解密后处理或直接转发.
• 数据完整性：接收方对接收的数据进行验证,以判定报文是否被篡改.
• 抗重放：接收方会拒绝旧的或重复的数据包,防止恶意用户通过重复发送捕获到的数据包所进行的攻击.

选定了 IPsec VPN,其实已经解决了很多需求,比如安全加密、穿越 NAT,通过野蛮模式可以实现总部配置一个 IPsec Policy Template,不用指向分支对端的 remote-ip 或 remote-name,起到简化配置的作用.

让我们继续来看看其他需求如何满足.

我们需要全网互通、设备冗余、链路冗余、故障自动切换这些很符合常理的需求,在 IDC 或者办公网内,我们通过 VRRP、HSRP、堆叠、虚拟化等技术实现网关冗余,通过链路捆绑或 STP 实现二层链路冗余,通过链路捆绑、动态路由实现三层链路冗余,通过 BFD 和 Track 实现三层链路快速切换,通过 ACL 和路由策略控制不同网络区域互访.考虑到公网对接场景跨三层,跨区域二层互访等需求本次不做过多考虑,最简单也是最容易扩展维护的方式就是通过动态路由协议来自动维护,切换链路,切换故障设备.

考虑到我们后期往往还会提出一些数据流量选路,不同网段之间互访,分支机构之间互访的更多的需求,我们推荐不同分支机构、不同机房、不同办公网之间互联采用 BGP 协议,可以满足后期各种复杂的选路需求,以下网络对接方案建立在目前已有网络已经同时运行了 IGP 与 BGP,在公网统一对接设计这里,继续用 BGP 是最好的选择.当然,如果您现有网络全网都是 OSPF,继续用 OSPF 完全可以,可以在规划一些非骨干区域用于 ABR 上汇总路由,优化网络,只是路由策略这块没有 BGP 那么灵活.

各大厂商均有一些 IPsec 冗余链路的特性支持,一般为主备的方式,需要增加一些额外的配置,并且在扩展性上没有那么好,因此我们决定采用多条 Tunnel 上运行动态路由协议的方式来做双链路、三链路、多链路的冗余.这里的 Tunnel 指的是 GRE Tunnel,也就是我们平常所说的 GRE over IPsec.

大家可能会问,你这里说的是公网统一对接方案,要求是不论公网还是内网均能够统一对接,而 GRE 协议由于报文格式里没有类似 seq 字段,是不可以穿越 NAT 的,而且 GRE Tunnel 两端均必须指对方与自己的源和目的 IP,所以做 GRE 的时候经常两端均具备公网 IP.

是的,通常我们在公网 VPN 对接中,会采用 GRE over IPsec 的方式,既跑动态路由协议,又对公网数据加密,GRE Tunnel 的源与目的 IP 一般为两端公网 IP,IPsec 针对两端公网 IP 匹配感兴趣数据流进而加密 GRE Tunnel.之所以用 GRE 的原因是因为 GRE 支持组播,可以更好的支持动态路由协议,并且不用为新增路由网段去修改 IPsec ACL,只需要通过路由协议去宣告新的网段即可,十分方便.而用纯 IPsec VPN 对接时,我们往往会在总部的设备上看到一堆的静态路由,虽然也可以通过静态路由加 Track、nqa、ip sla 等技术实现一些链路自动切换效果,但这种切换是无法对更远的链路故障进行感知的,不如动态路由协议,可以感知到全网任何一条链路故障.

前面我们强调过 GRE 不可以穿越 NAT,这里其实我们变换一下思路,把 GRE 的源与目的 IP 修改为两端的 Loopback 口 IP,即两端设备的内网 IP,通过总部与分支机构的内网 IP 建立 GRE 隧道,利用 IPsec 的穿越 NAT 特性统一接入不同网络场景,再通过动态路由协议 OSPF、BGP 统一控制路由层面,即可满足我们之前提到的所有需求,并且可以统一公网对接模式.

在横向扩展方面,我的思路是通过大量低端的设备完成,将 VPN 链路分散开来,某一台设备故障只会影响一小部分 VPN 链路,通过路由协议来维持全网的统一性.买十台低端路由器用以下方案组网,永远比你买一台高端设备睡得踏实.

实验配置

手边现有几台华为设备,以此配置举例,其他厂商的配置思路一模一样.

规划需求

我们将配置分为几个阶段：基础配置、IPsec 配置、GRE 配置、BGP 配置

演示拓扑如下：

基础接口配置部分

目标：实现分支能够访问到总部的公网固定 IP,分支可以是公网固定 IP,也可以是内网 IP 通过其他 NAT 设备访问总部,创建 Loopback 10 接口用于后面建立 IPsec VPN 使用.

总部：

sysname Hub
# 配置 WAN 口 IP
interface GigabitEthernet0/0/0
 ip address 200.1.1.100 255.255.255.0

# 配置用于建立 GRE Tunnel 的 Loopback 口 IP
interface LoopBack10
 ip address 172.20.1.1 255.255.255.255

分支：

sysname Spoke
# 配置 WAN 口 IP,如处于内网
interface GigabitEthernet0/0/0
ip address 192.168.1.100 255.255.255.0

# 配置用于建立 GRE Tunnel 的 Loopback 口 IP
interface LoopBack10
 ip address 172.20.1.2 255.255.255.255

分支防火墙：

确保 192.168.1.100 可以经过 SNAT 访问 200.1.1.100

公网：

确保总部出口 200.1.1.100 可以和分支机构公网出口 IP 通

基础路由配置部分

目标：确保两端经过 IPsec 加密流量从物理接口出去

总部：

ip route-static 172.20.1.2 255.255.255.255 GigabitEthernet0/0/0 200.1.1.1 description REMOTE-LOOPBACK10

分支：

ip route-static 172.20.1.1 255.255.255.255 GigabitEthernet0/0/0 192.168.1.1 description REMOTE-LOOPBACK10

IPsec 配置部分：

目标：总部实现一个 IPsec 配置模板,对接不同网络场景的分支机构,随着分支机构的增加不需要额外的 IPsec 配置.

总部采用 Template 模板方式,ESP 协议,开启野蛮模式、NAT 穿越. 分支采用 IPsec 策略配置一条或多条 IPsec 隧道,开启野蛮模式、NAT 穿越,指向总部的公网 IP,并且匹配 ACL,ACL 匹配的源 IP 与目的 IP 是双方的 Loopback 10 接口 IP 地址.注意：实验中只有分支机构需要指定 remote-address.

两端都采用 IKE 协商方式对接 IPsec.这里不采用 ike v2 的模式,因为 v2 不支持野蛮模式,无法传递给总部感兴趣 ACL(security ACL).

这里放上一张主模式与野蛮模式的协商过程对照图：

贴一段华为产品手册里总结的话：

• 如果发起方的 IP 地址不固定或者无法预知,而双方都希望采用预共享密钥验证方法来创建 IKE SA,则只能采用野蛮模式.
• 如果发起方已知响应方的策略,或者对响应者的策略有全面的了解,采用野蛮模式能够更快地创建 IKE SA.

总部：

# 创建 IPsec 安全提议
ipsec proposal PROPOSAL
 esp authentication-algorithm sha2-256 
 esp encryption-algorithm aes-128

# 创建 IKE 安全提议
ike proposal 5
 encryption-algorithm aes-cbc-128
 dh group2
 authentication-algorithm sha2-256
 prf hmac-sha2-256

# 配置 ipsec 对等体
ike peer REMOTE v1
 exchange-mode aggressive #野蛮模式
 pre-shared-key cipher test123 #两端 PSK 密码需要保持一致
 ike-proposal 5 #关联 ike 安全提议
 nat traversal #两端即使都为公网 IP,也可以开启 nat 穿越功能,不影响 IPsec VPN 建立.
# 注意：这里不指定 remote-name 和 remote-address,总部需要同时与多个分支建立多条 IPsec VPN.

# 创建 ipsec 策略模板,关联 ike 对等体和 IPsec 安全提议
ipsec policy-template TEMP 10
 ike-peer REMOTE
 proposal PROPOSAL
#注意：由于每条 VPN 加密数据流源目的均不同,这里不需要关联感兴趣数据流(security ACL),由分支机构负责传递 ACL 过来.

# 关联 IPsec 模板与 IPsec Policy,只能关联一个模板
ipsec policy POLICY 10 isakmp template TEMP

# 应用 IPsec 策略到接口上
interface GigabitEthernet0/0/0
 ipsec policy POLICY

分支：

# 创建 IPsec 安全提议
ipsec proposal PROPOSAL
 esp authentication-algorithm sha2-256 
 esp encryption-algorithm aes-128

# 创建 IKE 安全提议
ike proposal 5
 encryption-algorithm aes-cbc-128
 dh group2
 authentication-algorithm sha2-256
 prf hmac-sha2-256

# 配置 ipsec 对等体
ike peer REMOTE v1
 exchange-mode aggressive
 pre-shared-key cipher test123 #两端 PSK 密码需要保持一致
 ike-proposal 5 #关联 ike 安全提议
 nat traversal
 remote-address 200.1.1.100 #只有分支这里需要指定总部的公网 IP
# 注意：作为分支需要指定总部的 remote-address,不需要修改验证类型为 name.

acl number 3000 ?
# 匹配感兴趣数据流,源为分支设备的 Loopback 10 IP,目的为总部设备的 Loopback 10 IP
 rule 5 permit ip source 172.20.1.2 0 destination 172.20.1.1 0 

# 创建 ipsec 策略,关联 ike 对等体和 IPsec 安全提议,关联感兴趣数据流(security ACL)
ipsec policy POLICY 10 isakmp
 security acl 3000
 ike-peer REMOTE
 proposal PROPOSAL
# 注意：如果分支同时与多个总部建立 IPsec VPN,在此创建多个 Policy 节点,例如："ipsec policy POLICY 20 isakmp"

# 应用 IPsec 策略到接口上
interface GigabitEthernet0/0/0
 ipsec policy POLICY

GRE 配置部分：

目标：通过两端内网 Loopback 口建立起 GRE Tunnel,用于以后运行动态路由协议,开启 keepalive 功能.

总部：

interface Tunnel0/0/0
 ip address 172.30.1.1 255.255.255.252 #GRE IP,用于建立 BGP 协议
 tunnel-protocol gre
 keepalive period 1 retry-times 5 #每隔一秒心跳包检测,五秒超时
 gre key cipher test321 #只校验,不加密
 source LoopBack10 #源地址为总部 Loopback 10 IP
 destination 172.20.1.2 #目的地址为分支 Loopback 10 IP

分支：

interface Tunnel0/0/0
 ip address 172.30.1.2 255.255.255.252 #GRE IP,五秒超时
 gre key cipher test321
 source LoopBack10 #源地址为总部 Loopback 10 IP
 destination 172.20.1.1 #目的地址为总部 Loopback 10 IP

BGP 路由配置部分：

目标：BGP EBGP 邻居建立

总部：

bgp 100
 peer 172.30.1.2 as-number 200
 peer 172.30.1.2 path-mtu auto-discovery
 #
 ipv4-family unicast
 ?undo synchronization
 ?peer 172.30.1.2 enable

分支：

bgp 200
 peer 172.30.1.1 as-number 100
 peer 172.30.1.1 path-mtu auto-discovery
 #
 ipv4-family unicast
 ?undo synchronization
 ?peer 172.30.1.1 enable

检查

检查 ike sa、ipsec sa、GRE Tunnel 状态、BGP 邻居状态、BGP 路由

为什么不使用 BFD

既然用到了路由协议,BFD 是一个很好的搭配,可以用来快速链路检测,通常 BFD 可以实现 10ms 一次的心跳,三次失败的话仅需 30ms 就可以切换链路,纯内网环境非常适合.为什么不用 BFD 呢?

首先我们这里讨论的是公网环境,对延迟没有那么敏感,一些对延迟非常敏感的业务也不太可能通过公网传输.

其次关键的一点是 BFD over GRE 无法 over IPsec,大家可以抓包看看,BFD 可以进入 GRE 隧道,当你两端都做 GRE over IPsec 公网 IP 对 公网 IP 对接时,BFD 邻居可以起来,但是 BFD 报文外层仅有 GRE 报头,不会被 IPsec 加密,但是这样不影响公网对公网使用 BFD 协议,但如果我们的分支处于内网环境里就无法使用 BFD 了,因为 GRE 无法穿越 NAT,这里如果有人发现和我说的不同现象可以与我交流,因为我也没有把所有厂商的设备都测一遍,目前手里有的设备测试出来是这么个结果.

其次 GRE 自带的 keepalive 可以实现一秒一次的心跳包检测,三秒超时接口会 down,对应的 BGP 邻居会立刻 down,这个切换效果其实也可以接受,用户的感觉就是卡了一下就切走了.

再不然你还可以做 BGP 邻居的 Track,关联一些 nqa 和 ip sla 配置,实现更丰富的故障链路检测 & 切换效果.

如果分支的设备故障怎么办?

增加一台,与分支的内网里跑起来动态路由协议.

新建节点

我们假定一个工作场景,所有用于分支对接的网络设备需要总部网络工程师配置,那我们的网络工程师可以提前对设备进行配置,或者让分支机构的 IT 工程师协助配置,有哪些配置是需要后期完成的呢?

• WAN 口 IP,需要提前知道是何种方式,公网 IP 还是内网 IP,手工配置、DHCP 还是 PPPoE 拨号方式
• 缺省路由配置,若上一条可以提前配置,则此条不需要现场配置.

通常在分支设备 WAN 口可访问总部公网 IP 时,IPsec、GRE、BGP 一系列的状态都会自动 UP,远程管理地址也会自动接入网络,可以开始远程操作.

维护

让我们从后期维护角度看看此套方案的工作量新增公网 VPN 链路时需要新增的配置部分：

对于总部设备来说,增加一家分支机构接入：

• 增加一条指向分支机构的 Loopback 10 32 位静态路由
• 增加一条用来与分支机构建立动态路由协议的 Tunnel 口,运行 GRE 协议
• 动态路由协议里与分支机构建立邻居关系

对于分支机构来说,增加一家总部用于接入：

• 增加一条指向总部的 Loopback 10 32 位静态路由
• 增加一条 ACL 用于匹配不同链路的 IPsec 感兴趣数据流(security ACL)
• ipsec policy 里增加一个节点,关联上新的 ACL
• 增加一条用来与总部建立动态路由协议的 Tunnel 口,运行 GRE 协议
• 动态路由协议里与总部建立邻居关系

其他一些强烈建议配置项：

• NTP
• DNS
• AAA
• SYSLOG
• SNMP

批量管理：

建议通过 expect 或 python 脚本维护,通过学习一些基础编程知识,网络工程师很容易同时对上百台设备做变更操作.切记,跑之前先找其中一台试试.

总部设备横向扩展：

总部通过部署新路由器进行对接新的分支机构即可,全网通过动态路由协议打通,分支连接新的总部汇聚设备公网 IP,仅模板处需要更改.

割接：

网络运维中永远少不了割接,而一家分支如果有两条或两条以上隧道进行割接操作非常简单,假如我们现在需要对总部网络设备进行更换高配置的硬件型号,或者升级版本,只需切断路由协议邻居、或者是关闭 Tunnel 口,观察流量、报警有无变化,判断其余链路是否正常工作,是否可以继续进行操作,恢复的话以路由协议邻居建立、流量监控为准.

监控

监控以 syslog、snmp 协议为主,在网络自动连通的情况下均不是问题,管理 IP 均为提前规划,在上线前可以批量添加监控项目,这里就不做过多展开了.

由于我们是采用一条 VPN 对应一个 Tunnel 口的配置,所以在总部汇聚口这里,可以通过监控 Tunnel 口流量区分不同链路的流量,不同于纯 IPsec 的方式,VPN 数量一多的话所有流量都堆在一个物理接口下面,分不清楚每条链路各自消耗了多少带宽.

题外话

对于分支机构,小的办公网络往往只会接一条小带宽的运营商公网线路,分支节点多了办公网出口故障的情况还是比较常见的,好在现在的路由设备往往都支持 4G 模块,你懂的.

性价比

国内一些大厂路由设备价格在一台五千元上下的型号,IPsec 吞吐量可以达到 700Mbps 以上,根据实际情况合理规划,总部一台设备对接 20 – 50 条链路个人认为都可行.

分支机构如果流量不大可以选购一些不到 1U 大小的低端型号路由器,价格在千元左右,但是各种特性均支持,十分划算. 综上所述,设备选型还是与公司实际需求有关,一定要根据实际情况去做规划,对于整套方案来说,所有协议均是公共标准,没有私有协议,理论上各家厂商设备均可对接,低端设备与高端设备的区别往往是性能、接口数量上的区别.

尾声

有人估计要问了,开场提了一堆需求,好像还有一些未提到,例如：

• 优化分支机构的路由,避免过多路由
• 能够区分流量走不同的链路,同时某条链路故障了又可以自动切换
• 能够做地址转换,打通多个相同网段的网络

优化分支路由这块其实通过路由策略很容易实现,如果 AS 编号规划合理、连续的话,可以通过 as-path-filter 工具只向分支机构传递机房的路由、总部路由,或者通过路由聚合、null 0 静态路由宣告、BGP 通告缺省路由(此动作需要分支机构不再写缺省路由,而改为总部的明细公网路由条目)等等多种方式实现,并且有一个前提,就是 IP 地址规划要做好,如果做到一个 AS 内 1 到 2 条 汇总路由,那么你全网互通的情况下所需要的路由表数量是非常少的.

至于区分不同流量走不同链路而同时可以互相冗余备份的需求,也跟 IP 地址规划有关,我们要考虑路由的来回路径的问题,所以想实现这个需求网络层面上一定要求不同流量指的是源与目的 IP 均不相同,否则就要借助一些四层或者七层转发服务,例如 LVS 或者 HAProxy,通过建立多组转发服务实现流量区分,此种条件下依然需要一些业务网段进行区分.这里我不推荐用策略路由的方式,从运维的角度不利于管理维护,也会增加设备很多额外的开销,并且无法感知到深层次的链路故障.

地址转换用到 NAT,例如公司与客户内网对接时,需要同时做源 NAT 与目的 NAT 实现任意网络对接,不用考虑地址冲突的问题.

以上这些需求与本次公网统一接入的话题没那么密切,也不过多展开了.

总结

总结下来其实就是一句话：利用 IPsec 的野蛮模式实现总部模板部署、利用 IPsec 的 NAT 穿越功能实现公网、内网统一对接,用两端私网 IP 建立 GRE 隧道,最后再利用 GRE 接口 IP 运行动态路由协议.全网都可以实现互通,除了所有设备的 Loopback 10 接口是不可路由的,只存在于静态路由中.

既然标题我们叫做“面向总部与分支之间的公网统一安全对接方案”,那最后我们有没有实现统一了呢?如果你通篇阅读下来你会发现,无论面向何种分支公网对接,都可以用这一套模板,你要做的仅仅是修改修改接口 IP,运行同样的路由协议,同样的接口编号,性能不够了加几台设备.有人也会说,有些厂商的私有协议 DMVPN、DSVPN 也可以实现类似效果,但是那些技术要额外的 License,并且是私有协议,无法跨厂商设备对接.我们今天所介绍的所有内容均是路由设备最基础的功能,可以自由组合起来使用,希望对大家有帮助.

作者介绍

刘启,网络工程师,CCIE & HCIE,曾任职于神州信息互联网事业部、去哪儿网 OPS 负责数据中心网络运维,目前就职于本木医疗公司负责网络规划设计.

原文来自微信公众号：云技术实践