记一次完整的安全技术解决方案遭遇成本考验后的“退步与博弈”

Posted 2020-09-19

写在前面，出于保护客户隐私和坚守网工的职业道德素养，本文不得出现的所有完整ip、客户名称、信息、以及详细的业务模型阐述。最近确实走心的在分享案例，2017年5月21日在家里写了近四小时，女票已经暴走，请大家掩护我！！！！！

                             ——————Allen

项目背景：

客户要在国外上一套业务系统，并接入国内用户，开展国内和国际的业务。

关键点1：因公司注册地在海外，也就是说主体不在国内，无法完成国内网安备案这件事情

关键点2：即业务系统不可涉及到国内域名解析

关键点3：国内互联网出口与国际互联网出口的需从架构是进行剥离，意味着存在双出口。这直接会导致web和DB的物理（这一点若大家不是很明白为何这样讲，欢迎大家建群讨论，这里不展开探讨）

关键点4：国内一块区域、国际一块区域，中间访问与传输如何解决？客户要求必须达到企业级专线水准（丢包千分之三的水平）

关键点5：针对海外特殊的点，例如日本、新加坡、英国、美国进行特殊的路径优化。

 

项目第一次逻辑网络拓扑图：

 

项目第一次讨论提供的设备清单（和谐过）：

1.    思科防火墙（ASA-5515系列）

2.    华三交换机（S5500-EI系列）

3.    负载均衡（软件级）

4.    服务器（惠普、戴尔都有）

5.    存储（惠普），另外还有一台磁带机

6.    光纤交换机（Brocade）

 

项目经过：（希望大家感同身受的去感觉下我当时的状态）

按照惯例，我作为架构师的角色兼任项目交付的PM角色前往客户现场与客户进行为期长达20+天的沟通与相关技术确认，期间也不得不出差到北京、深圳、香港。

 

这里重点聊几个里程碑的事件。第一次与客户的会面，我们在自己公司总部进行了长达两个小时的会面与讨论，包含但不仅限商务洽谈、公司资质介绍、技术难点、最佳实践案例分享。

在此次会议中，我是最后进入会议的一名“工程师”的角色参与的此次会议，（这是极其不礼貌的事情，不过我巧妙的化解了此次不礼貌的行为），因为即将会议结束，我就没发名片直接进入了个人提问和展开的讨论。提了四问：

 

哪四问？大家往下看。

第一问：您这边对于高可用故障切换过程中，会话级层面的实时切换的控制到哪一个等级？有没有针对TCP的长连接的会话保持要求？负载均衡在程序上做的是四层还是七层、还是四层+七层？

注释：我这里一上来问这些，主要是要分清在场会议中的客户侧有哪些角色，并哪些占主要？这样有利于我直击客户的“痛点”，或者说是“兴奋点”。

 

第二问：您提供的逻辑网络拓扑，物理机柜拓扑，我都看了，但根据以往的经验和实践的情况看，有存在不少资源上的空置情况，（随后我走到投影区域，分别进行了讲解）

 

第三问：您这边提供的设备清单，我关注了下您的网络设备选型以及在采购明细备注中的内容，因为您关注业务的连续性，那即意味着所有硬件节点均是高可用才是，但在您的采购清单中未看到firewall的高可用license和switch的专用堆叠电缆，往往这些license或可能比一台设备都贵，您若已经选型定好，您勿忘叮嘱采购的同事关注下，避免预算被打回重做。

 

第四问：我这里有与您业务极其相似的客户实践案例（包括了售后运维的各个情况说明），我这里投出来分享给各位，看看是否有哪些可以参考的地方？（随后我把自己整理的一份最佳实践的案例PPT分享给了客户，此时客户表示非常有兴趣，也想看看自己的架构是不是可能存在什么问题？）

 

随后，我简单的分享了一个我们具体做过的一个案例，然后就没再多讲（记住，做工程师并不是搞定对方技术主管这么简单，更重要的是要用一个非技术语言的方式阐述给对方的运营者去听去理解，然后有点情商的去处理任何一个环节），然后我关闭了分享PPT，总结说：“因为是第一次沟通，我也是比较表面的去理解了您这边的情况，所以有哪些地方说错了，您这边多体谅。”随后我转过头来和此次会议的主持人（销售）大声的说：“我们下一次会议在什么时候？”~~~~~~~~~~~~~~~~~~会议结束后，销售给予我反馈，客户对我分享的内容非常感兴趣，下一次沟通我们定在下周三，地点北京（望京SOHO）。

 

 

至此，这里第一次沟通结束了，在次日，我将基于第一次“过于表面”的理解的分析报告汇总成了PPT，发送给了甲方。以下，我展示几页有关于技术的。

 

 

 

结合如上的一些分析与之前客户提供的拓扑，我进行了三个版本的visio的整合和梳理优化，这里share给大家最终提供给客户的拓扑（已和谐）：

 

写在前面，除之前提到的问题全部优化妥善解决后。为客户带来的价值优势新增如下：（首次分析重点，请大家仔细品位和研读，我费了不少脑子，出于实际，技术完全可落地）

• 三个area完全环网并可以通过部署高敏捷检测机制实现毫秒级切换实现应用服务备用网关寻址持续提供对外服务，并设置对应routing policy，并部署ipsec-vpn or P2P gre overipsec依托公网进行冗余线路部署，实现灾难发生时的应对方案

• 前置area与APP area流量可经过内网墙也可以通过明细routing policy使不经过internal-firewall，避免流量数据多次被firewall拆解封装影响，既而造成网内无用流量增多，应用转发效率低下

• DB area 与 APP area实现完全分离的，若internal-firewall外挂特征库查询机制，可实现基于特征的调用级层的访问控制。

• 新增monitor（基于KVM资源利用），完全独立使用一套公网（BGP），实现内网应用、硬件、中间件、DB的明细监控与alert，并接入wechat企业账号，实现告警完全移动化，减轻运维人力方面的投入，远程运维团队实时接收告警real-time响应

• 若IDC存在大量不可预见性的扩容，通过此次infra的架构部署优化，可以更好进行适应性部署，无需进行“大手术”，完全平行扩展。但建议边界设备在项目首期上线前一定选择基于当前业务量的3-5倍容量去选型，方可实现无缝升级

 

 

时间悄然的到了第二周去北京的路上，这里还是要秀一下网工对时间重视，一路上，我们和俩位同事讨论了很久此次项目上的问题，然后打开电脑记录了许久，直至夜里23:53分到达了北京。

 

次日，客户如约到达了我们北京的分公司地点，我们开始了第二次的讨论和对接，并在会议室接触了客户业务系统的软件提供商。自此我们就确认了项目已八九成单了。

~~~技术讨论这里省略，不过应软件商要求，我们再次对visio的网络拓扑图进行了修改，如下所示（已和谐）：

 

注释：大家注意仔细观察区域和区域之间为什么都过了防火墙，至于为什么这么链接，一定是他的考虑。这里就不详细的阐述了。

 

这一次的整合拓扑发出后，我和软件商侧再次产生了很多架构设计上的分歧，讨论了很久，这期间客户也为我们协调了好几次，不过最后结果是好的。大家都认同了这样的部署，所以在看此文的读者记住，技术讨论不可涉及人情味道，一旦涉及，你就无法保证你的方案是完整、可扩展性强的。只有激烈的讨论，技术的创新才能出来，这里也吐槽一句，在国内做售前、做架构。很难纯粹的做技术。相反国外就会好很多，我不是说国外的技术牛，我只是表达国内的关系型销售越来越多的侵蚀着很多需要专注、专业、严肃的行业。

 

第二次的拓扑整合，我这里不share给大家，因为涉及到了客户信息，大家理解下。

 

项目的最关键的阶段来了，设备选型的敲定和采购。我参与了此次网络设备型号的推荐建议。并提交给了客户。可是最后因为种种原因，我和软件商提供的方案都打了极大的折扣，这意味着我们双方的公司需要承担甲方业务连续性-不可用的风险和责任。所以，这个时候我们站在技术的角度再次将打完折扣后的方案进行了完整的讨论和风险告知！

PS：大家在做售前咨询的时候，一定要注意风险告知！！！这一点不说，就会成为未来甲方不认可你很重要的一个点。若读者有同行的话，应该都明白，甲方很痛恨那种问题一次性不说清楚，遇到一个说一个的乙方。所以大家一定要谨记在心，我就入过坑。

 

项目中的方案折扣：

        思科ASA的failover许可证不购买，采用双物理防火墙，不同outside对外提供服务的方式部署

 

PS：oh myladygaga！！！！

 

好了，不扯其他的，接着说本文最最最最最最最精华的技术分析篇幅，大家别拿砖头砸我，我只是想让大家更好的进入角色，设身处地的去体会我在此次项目中扮演的角色和如何处理技术与非技术问题的应对行为，这样大家即学到了技术，又get到了技能。又得到了一个技术案例，多耐心的读一点何乐而不为呢？：）

 

方案遭遇了打折，技术遭遇了挑战，这一点对于很多纯售前工程师相当的头疼，因为是当场提出来的挑战，若没有经历几年售后详细的技术支持和心得总结，很难在这样的情况下应对自如。恰好，这个就是我个人的优势，我本身就是项目交付的主要负责人之一，那对于网络的细节把控上还算是“及格”的，所以场面一度被我hold住，进行非常详细技术细节讨论，并在会议结束后，我输出了这样一份报告。

 

什么报告呢？容我一一的上传给大家解释（已和谐），我的分析与考虑，往下看。

图解：

红色直线为此次项目中，正常流量的访问路径走向

绿色直线为此次项目中，failover后的访问路径走向

 

注意，我这里的firewall是没有HA部署，所以中间没有直连线，但我曾考虑过，是否直连起来，内网跑个动态或者静态，使故障的流量路径有这样的切换选择。

 

分析：

    当我把图画出来后，立刻就否定了这个方案，因为GW在交换机上，若要达到路径绕行，上层就会涉及全路由环境。而对于故障侧（左边）防火墙来讲，下游的接入inside一定是挂了nat模式，若要强行这么做，做nat 0豁免也是可以，但这一定程度上加大了配置设计的难度和维护难度，同样对于右侧的防火墙，就会有双inside口，所以这样做非常不理智。

 

 

补充一个前提：

这里的firewall上联故障后（被DDOS、网线损坏、硬件故障），切换都是在程序上做的，对于程序来讲，他自身即可实现双链路进入，即：程序上就有（主备）的概念，同时结合应用心跳的检测机制，即完成了异常实时自动将用户访问重新reload即可，即：客户重新login下即可。

 

分析：

目前在边界firewall上没有实现平滑HA高可用切换的话，遇到的挑战非常大，但是我和我的团队还是想到了解决办法，虽然效果不理想，但结合程序和基本的路由检测技术，完成因硬件故障导致的故障，且需要将路由进行人工或手工切换事情，全部都自动化了。

 

大家在我以往的文章中，都应该明白HA的检测机制常见的都是检测端口的up/down，好一点的带源检测一个IP，或者一个协议。但我们常见的做法都是检测物理端口，因为你检测GW，很有可能你的服务提供商把GW做了ICMP保护，延迟不定时丢。检测某一个信任的IP地址，你又没办法保证，中间任一一个节点的割接升级优化不影响你。更狗血的是，对端若维护不通知你，那就尴尬了。

 

所以这里想了一个办法，利用思科一个非常老的技术，解决了此次方案中检测和切换的问题——思科ios IP SLA，如果大家需要了解，可以跳转到鸿鹄，有一篇帖子讲的非常详细链接如下：

http://bbs.hh010.com/thread-109542-1-1.html

 

解决问题需要的技术：

1.    IP SLA

2.    浮动静态路由

 

备注：简单的技术，灵活用，这才是网工存在的意义，不要天天喊大二层VPLS、MPLS、各种高端技术，能落地且使用的方案才是好方案！！！

接着讲思路：

——通过三层交换机部署 IP SLA的技术检测防火墙outside口的IP

Allen：我们检测该outside的接口ip，相当于实现了HA中检测端口UP/DOWN，因为接口donw了，接口协议就down了，ip自然就ping不通了。

 

——通过写浮动静态路由，优先级低的先指到右边的主角色-firewall上，优先级高的指到右边备角色-firewall上，配合IP SLA + TRACK

       Allen：通过在优先级低路由后面挂Track联动IP SLA检测，我们就可以实现非直连链路的检测和切换，这样就成功的化解了此次技术的挑战。

 

不过这里要多唠叨一句，高可用部署并非像我上面利用简单的技术解决而达到的效果，这里切记，高可用实现的不是仅仅是切换联动，还有RTO会话的和session状态的同步，HA在整个拓扑设计上，在上层是一个整体，并非两台独立的物理形式存在。

 

所以，你在遇到我这样的类似的案例的时候，切记，如果你核心交换机与防火墙对接你没用浮动静态，而是等价路由，就会出现如下问题：

分析：

服务器向上的流量，就会被均分到上联两台防火墙上，（交换机不维持会话，且防火墙并没有部署HA，RTO没有会话保存），所以路由层面的等价后，这样就会导致，TCP三次握手出现问题，当恰好走到备角色上后，防火墙一定作Drop的action处理，因为它就没有会话，怎么会得到一个ACK+1的会话呢！！。虽然在客户使用的程序上做了主备访问的路径处理，但是GW它就是不管，所以大家还是要注意下，这样类似源进源出的问题。

 

 

思科配置截图如下：

Lab_R2811_rack1(config)#iproute 0.0.0.0 0.0.0.0 10.19.1.1 ?

  <1-255>    Distance metric for this route

  name      Specify name of the next hop

  permanent permanent route

  tag       Set tag for this route

  track      Install route depending on tracked item

  <cr>

 

华为配置截图如下：

[Lab_2204S_rack1]iproute-static 0.0.0.0 0.0.0.0 10.19.1.1 track ?

  bfd-session  Specify BFD session

  efm-state   Specify tracked ETHOAM state interface

  nqa          Specify NQA test instance

 

备注：实现检测的技术并联动路由有很多（BFD/TRACK/IP SLA），大家多看看技术手册，多学习！！详细的配置我就不晒了，大家多花点时间去理解原理，去由衷的探讨，这才是我的希望大家做的。

 

写在最后，这个案例我在本文中只写了网络部分，当然也有相当多的存储和光纤以及虚拟化的技术挑战，因为这一块毕竟不是自己的想法，我搬出来写就相当于抄袭，所以我在本文中只写了自己的思考和总结，当然，我个人的能力是有限的，其实回过头来看看，漏洞也是有的，不过这就是博客的有意义的地方，等过了三五个月，我再回来看的时候，我就知道我的成长在哪里了。

近期我个人接触了很多代理商的负责人，因为个人工作的关系，我们对每一个产商的产品线以及特色产品都需要非常的了解，所以这就迎来了很多测试样机。后面我会用用户体验的角度去分析目前送过来的样机体验分享文章，希望大家期待一下。我也趁这个机会，平行的对比下各个产商的产品的特点，加油！

 

虽然这个项目是我（PM）全栈负责完成，但各个我不懂的部分都是同事倾力帮忙分析和提出的解决方案。所以这里赞一下我的同事：

       小鸡（尚未开通）、登锋（http://2183517.blog.51cto.com/）、文浩（尚未开通）

PS：未来他们也会在CTO上更多去描述自己的所负责的案例中的Part，本着专业的职业操守和信息保护的状态。祝大家521欢乐

对于这篇文章，仅代表我个人观点，若存在问题，大家及时回复即可。

 

我的初心一直是这样，我在尝试着真诚地描述自己遇到的问题和解决经历。

                                                 ——————来自一个正处于人生转折点的网工Allen

 

QQ:549675970

QZONE:http://user.qzone.qq.com/549675970

E-mail：

          [email protected]

          [email protected]

 

人生格言：越努力、越幸运

本文出自 “Allen在路上-从零到壹” 博客，转载请与作者联系！