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

总部：

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 均为提前规划,在上线前可以批量添加监控项目,这里就不做过多展开了.

（编辑：源码网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!