e-works数字化企业网  »  文章频道  »  基础信息化  »  网络与安全

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

2017/4/15    来源:运维派    作者:佚名      
关键字:公网  运维派  
公司与其他机构测试环境通过公网对接,对安全性有一定要求;公司有多个机房,不同办公场地需要同时访问多个机房内网。但是不同分支机构的网络场景可能会不一样,有的有固定公网 IP,有的只具备内网 IP。VPN 链路还需要实现冗余,一个总部挂了,要能自动切换到另一个总部,随着业务的发展,需求会越来越多。
    背景
 
    每个公司都有公网对接需求,比如全国各个办事处,各个门店需要访问总部、各个写字楼、办公室需要访问机房;公司与其他机构测试环境通过公网对接,对安全性有一定要求;公司有多个机房,不同办公场地需要同时访问多个机房内网。但是不同分支机构的网络场景可能会不一样,有的有固定公网 IP,有的只具备内网 IP。VPN 链路还需要实现冗余,一个总部挂了,要能自动切换到另一个总部,随着业务的发展,需求会越来越多。
 
面向总部与分支之间的公网统一安全对接方案
 
    每当网络工程师要做一件事,大家都会非常理想地提出 balabala 一堆需求,我们“简单”列举一下:
 
  • 多分支机构公网接入办公网总部,或者接入机房。
 
  • 网络全通,任意 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 链路,通过路由协议来维持全网的统一性。买十台低端路由器用以下方案组网,永远比你买一台高端设备睡得踏实。

责任编辑:李欢
本文来源于互联网,e-works本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供,并已尽力标明作者与出处,如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。联系方式:editor@e-works.net.cn tel:027-87592219/20/21。
兴趣阅读
公网  运维派  
相关资料
e-works
官方微信
掌上
信息化
编辑推荐
新闻推荐
博客推荐
视频推荐