面向总部与分支之间的公网统一安全对接方案
副标题[/!--empirenews.page--]
《面向总部与分支之间的公网统一安全对接方案》要点: 背景
理想很完美,现实很骨感,总结起来就是用最少的钱实现最牛逼的效果,老板们的脸上乐开了花. 让我们先看看分支机构通过公网接入一般会有哪些网络场景? 多种不同网络环境如下: 选型思路公网对接首要考虑的是安全,比较安全可靠的三层 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 功能,正好能满足我们不同网络对接模型. 常用加密、验证方法: 无论是加密还是验证方法,两端的安全提议保持其中一组一致即可.
选定了 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 等技术实现一些链路自动切换效果,但这种切换是无法对更远的链路故障进行感知的,不如动态路由协议,可以感知到全网任何一条链路故障. (编辑:开发网_开封站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |