是时候从VPN转向SD-WAN了，是时候从VPN转向SD-WAN了
是时候从VPN转向SD-WAN了，是时候从VPN转向SD-WAN了大部分SD-WAN供应商的方案和营销方向都是围绕自身优势制定，比如做广域网加速起家的会强调广域网加速技术的重要性，安全起家的会强调安全的重要性，自有线路或者云资源的一定会强调资源的重要性……其实这些都不重要，明确场景、明确需求、明确关键业务才是最重要的。这些明确了，你才知道到底需要什么样的SD-WAN方案。我把市场常见的所有类型的SD-WAN方案涉及到的产品功能特性和资源做了个整理，大概就是图里这些。一般来说，SD-WAN方案组成中一定会有一台实现主要技术功能的CPE，再按需搭配资源、管理平台、控制器等元素。对于不同场景的解决方案，只要针对需求选择图中元素的合理搭配即可。一些企业IT人员试图从业界权威机构获取正确答案，结果却更懵逼了。在这些权威机构给出的定义中，SD-WAN往往根本就不是个标准化的产品方案，有些甚至只是功能技术的集合。换句话说，产业界的SD-WAN，和市场上的SD-WAN并
去年这个时候，我的SD-WAN世界观刚形成，关注点几乎都放在了新技术带来的新体验，还写了几篇关上云加速场景和SaaS加速场景的使用心得。今天回想起来，我只能说当时图样图森破，以至于忽视了一个非常重要的场景——分支互联。
之所以这么说，是因为我活活被不停地问了一年。事实证明，分支互联才是企业客户目前对SD-WAN最大的需求所在，也是最大的市场所在。
适用于分支互联的SD-WAN方案到底是什么SD-WAN用到的技术很多，交付形态很多，能解决的问题也很多。但正是这种不确定，给企业客户带来了额外的困扰。
到底什么是适用于分支互联场景的SD-WAN？和上云加速、SaaS加速场景的SD-WAN又有什么不一样？
一些企业IT人员试图从业界权威机构获取正确答案，结果却更懵逼了。在这些权威机构给出的定义中，SD-WAN往往根本就不是个标准化的产品方案，有些甚至只是功能技术的集合。换句话说，产业界的SD-WAN，和市场上的SD-WAN并不是一个东西。
在我看来，市场层面的各种SD-WAN解决方案，其实都是以性价比为导向，针对关键业务品质与可用性提供保障的所有技术与资源的整合方案或服务。与其往某个技术定义上硬套，不如说它们是更大的场景化方案（例如Gartner提出的WAN Edge或SASE）的子集。
四个关键点必须满足。首先是性价比导向，能在满足需求的前提下有效降低成本，才有存在的意义；第二，需要保障的是关键业务的品质和可用性，钱不能花到非关键业务上；第三，要达到保障关键业务品质和可用性的目的，除了需要借助设备实现一些功能，也可能还需要线路资源或云资源做补充；最后，交付形态可能是传统的购买设备部署，也可能是纯服务形态的交付，尤其带着线路或者云资源的方案更是如此。
我把市场常见的所有类型的SD-WAN方案涉及到的产品功能特性和资源做了个整理，大概就是图里这些。一般来说，SD-WAN方案组成中一定会有一台实现主要技术功能的CPE，再按需搭配资源、管理平台、控制器等元素。对于不同场景的解决方案，只要针对需求选择图中元素的合理搭配即可。
大部分SD-WAN供应商的方案和营销方向都是围绕自身优势制定，比如做广域网加速起家的会强调广域网加速技术的重要性，安全起家的会强调安全的重要性，自有线路或者云资源的一定会强调资源的重要性……其实这些都不重要，明确场景、明确需求、明确关键业务才是最重要的。这些明确了，你才知道到底需要什么样的SD-WAN方案。
就以分支互联为例，可以认为关键业务就是需要进隧道的流量，那么基础网络、站到站的隧道是肯定要有的，否则没法组网；为了保障其品质和可用性，拨测选路能力也是必选项。其它元素依需求而定，比如分支数量非常多或存在分支间流量，那大概率需要零配置上线和网络统一编排能力；假如关键业务里有商业SaaS，那就又得用上应用路由……你只要能把企业业务需求清晰地拉出单子，需要的技术和资源也就能列出来了，这就是你的分支互联SD-WAN方案选型评估标准。
需要提醒的是，很多SD-WAN供应商会宣称自己的方案具备流量调度、网络统一编排在内的完整能力，如果选择部署其整体方案并将运维全部外包，企业就能共享这些能力。但现实情况是，大部分SD-WAN供应商的CPE设备在功能、性能、可靠性方面较传统大厂产品还有相当大的距离（尤其4-7层功能），很多企业IT部门不能接受将CPE串接入网乃至直接做为网关带来的额外风险，所以将其视作光猫一样的角色，将SD-WAN服务和传统的线路资源划等号。在这种情况下，供应商的SD-WAN能力就不再是企业的能力，企业依然需要自行建设维护分支互联SD-WAN产品技术方案。
个人感觉这种情况在几年内不会有根本改变。企业在进行网络建设时，建议还是多评估评估传统数通、安全产品方案的SD-WAN技术能力。顺便说一句，我一直以来比较看好安全背景的企业涉足SD-WAN，也认同安全是SD-WAN方案的必要属性，就是因为企业网络边缘既是安全功能的决策点，又是SD-WAN功能的决策点。理论上是可以通过串接两台设备（防火墙 CPE）的方式解决问题，但单台设备的建设成本和运维成本明显更低，当前这种经济环境下，你觉得企业会选择哪种方案？
用SD-WAN做分支互联比传统VPN组网好在哪知道了分支互联SD-WAN方案到底是什么，就逃不开一个问题——用分支互联SD-WAN方案比传统VPN好在哪？
实际上，这也是我近一年被问到最多的问题。
答案很简单，SD-WAN做分支互联就是VPN组网的升级。二者绝非泾渭分明，实际上，VPN恰恰是SD-WAN的底层实现。从上文图中就能看出，传统VPN组网方案实际就是基础网络、隧道协议再加一部分管理和安全功能；SD-WAN只是在此基础上，融入更多不同维度的技术与资源，更好地应对新业务带来的功能需求与挑战，同时靠自动化手段降低运维成本。
如果说VPN解决了有无问题，SD-WAN就进一步解决了好不好的问题——不仅是体验的提升，还包括OPEX的大幅降低。
在诸多新技术中，拨测选路是最最重要的一个特性，广泛应用于所有场景，可谓是SD-WAN方案的核心能力。换句话说，缺少这个能力，就不是SD-WAN方案。
传统VPN组网方案中，流量的调度靠策略路由实现，从而做到关键业务流量走隧道访问私有化部署的业务平台。这个机制平时毫无问题，但在链路品质劣化的时候，就会暴露出过于简单粗暴的弊端。
通常来说，基于传统VPN组网的情况下，如果承载隧道的线路出现异常，只要隧道协商不中断，策略路由还是会不停地把流量往隧道送，完全无视应用体验方面的下降。而拨测选路的意义就在于，它多了一个定期主动探测机制，可以在指定接口进行持续的质量探测。一旦拨测结果超出设定的阈值（而不是等待隧道中断），设备或控制器就会动态触发路由调整。
举个例子，当你承载隧道的线路从50ms延迟/0丢包/5ms抖动跳变到200ms延迟/5%丢包/30ms抖动时，传统VPN组网一般不为所动，但SD-WAN方案可能就已经自动把流量切到其它品质更好的线路去了，尽量保证了关键业务的使用体验。
这里又引出一个很多人关心的问题：控制器是不是必须的？
答案是要根据你的组网规模而定。假如你的分支数量不多，需求也不复杂，设备级的拨测选路就是你最好的选择。咱先不提建设成本，对成长型企业的IT运维人员来说，玩转控制器的技术门槛太高了，就算白送也很难用好，或者根本用不起来。
但在大规模组网环境下，由控制器基于拨测结果进行网络流量的全局统一编排，带来的效果是传统VPN组网难以实现的。更何况当VPN组网大到一定规模时，靠人肉也根本运维不过来。这两年我关注过几个连锁零售企业整体门店的升级改造，无不因此选择了带有控制器的SD-WAN组网方案。对他们来说，IT运维成本中人的成本已然是最大成本，需求和预算间的矛盾已经不可调和，控制器在这解决的已经不是好不好的问题，还真是能不能的问题。
最后一个被普遍关心的问题：分支互联SD-WAN方案中，线路和云资源是不是必须的？
答案是根据关键业务的品质要求而定。当你能获取的接入资源都无法满足要求时，外部资源就是必须的。比如互联需求涉及企业境外分支，那SD-WAN方案确实需要包含优质资源。或者企业业务非常关键，有明确的SLA要求，那么只有外部资源可以承诺，一切不包括资源的SD-WAN方案都只能做到尽力而为。
但如果你的分支数量不多，又都分布在互联网接入资源较为充裕的国内一二线城市，并且互联带宽需求不是很大，那外部资源也许就不是必须的。
能够省下资源这部分费用主要有两方面原因。首先，国内运营商的互联网接入品质已经足够优秀，尤其在一二线城市，就算定位较低的企业宽带/专线，链路品质也是有保障的，何况每年还提供着提速降费的福利。并且跨运营商互联互通的品质也较头些年有了显著提升，至少很多性能监测服务商在做非跨境线路监测时，已经普遍将丢包的合格率设定为小于3‰。
另一方面，应用对接入线路的品质要求在下降。尤其是比较新的互联网应用，往往在设计阶段就针对互联网乃至4G/5G而非专线品质做了考虑，用上了主动纠错等技术，具有更好的容忍度，降低了企业客户的使用门槛。这一点，ZOOM、腾讯会议、钉钉会议等都是很好的范例。
廉价线路的品质和带宽在提升，业务对线路品质的要求在降低，再通过SD-WAN方案中诸多新技术加持，大部分成长型企业的分支互联需求就是可以满足的。至少我深入参与过的这类项目，最终落地方案基本都是如此。
回想一下，这一年多找我咨询分支互联SD-WAN的基本就是两类诉求，第一是想砍专线降成本，第二是想提升传统VPN组网的品质。这两类诉求间原本是没有更好选择的，现在有了SD-WAN，把原本大颗粒的资源和产品技术敲打得足够碎，让企业能够更好“量体裁衣”的同时又提供了更好的性价比，才快速点燃了这个市场。
所以，忘了VPN，拥抱SD-WAN吧。
分支互联SD-WAN方案的挑战与未来前面是科普、方法论和经验，本节谈谈业界先进方案还做到什么，以及与之对应的场景价值（坑）。我会以Fortinet SD-WAN方案为例进行分析，如令您感到不适，请跳至下个小标题，于上帝视角见证某知名互联网企业的分支互联SD-WAN升级改造全过程，相信一定还能有所收获。
简而言之，Fortinet的分支互联SD-WAN方案集成度足够高，体验足够好，成本足够低，弹性足够大。
得益于在网络、安全等领域的长期积累，Fortinet的SD-WAN方案几乎提供了我总结的图中除资源外的所有技术元素，覆盖程度在我接触过的方案中较为罕见。无论是分支加速、上云加速、SaaS加速还是其它什么场景，都能找到匹配的支撑技术，搭建出相应解决方案（甚至是同时实现），且自带原生安全属性，属于十足的超大杯。
要知道，企业信息化建设总是一环套一环，不可能说现在分支互联有SD-WAN需求，未来绝不会有其它需求。比如我看到过的案例中，SaaS加速经常和分支互联加速前后脚出现，总不能为此搞两套方案吧？从保护IT投资的角度，未来SD-WAN方案势必会走向全场景化。
要说体验足够好，并不完全取决于技术实现的广度，更取决于技术实现的深度。我只举一个例子，更贴近业务模型的拨测选路。
现在，我们假设企业有视频会议和数据备份两个关键业务，他们的流量模型以及对线路的品质要求截然不同。视频会议对带宽要求相对较低，但对延迟抖动丢包十分敏感；数据备份通常正相反，需要尽量大的带宽，但对延迟抖动丢包没那么敏感，容忍度也高一些。
这种情况下，最合理的选路逻辑是在每条线路上都针对两种流量模型发不同的探测包，再分别根据不一样的容忍度阈值进行动态调度，才能更好地保障业务品质。遗憾的是，对于市面上大多数分支互联SD-WAN解决方案来说，都只做到在每条线路发固定参数的ICMP探测包，就算参数可以人为设定，显然也与某个关键业务的品质要求无法匹配，品质保障无从谈起。
而Fortinet基于FortiGate防火墙实现的拨测选路，允许用户针对不同业务模型设定不同的探测参数模版，再绑定到需要参与选路的线路上。不同的业务，只要调用对应模版返回的数据，即可达到更精准、更有针对性的选路效果。
其实去年我已经在FortiGate产品上看到了这个功能，还专门写了一篇文章介绍。不过当时因为没什么实践经验，我只看到了表象，没能深刻理解到它在真实场景中的价值。经过这一年时间的下沉，我确信拨测能力的深度是复杂场景下保证选路品质的关键因素，一定是未来各家SD-WAN方案PK的重点。
比如在中国特色的运营商组网结构里，你的ICMP包和HTTP包甚至可能走得都不是一样的路由，单纯使用ICMP做探测，怎么可能准确反应业务品质呢？
再比如你的关键业务集群前方有负载均衡，ICMP探测数据只能说明到负载均衡这一段的品质，岂能等同于真实业务的使用体验呢？
这些都是项目里趟过的坑。
至于成本低和弹性大，完全得益于Fortinet的SD-WAN方案中功能决策点的松耦合设计。
对于市面上大多数SD-WAN解决方案来说，它们的交付都是不可解耦的。想要部署SD-WAN？没问题，请使用我们的全家桶。什么？你只需要一部分设备级SD-WAN功能？对不起，无法交付。在这种情况下，企业部署SD-WAN的门槛自然变得很高，尤其对初创企业或成长型企业来说，基本是不可能的事。
一句话，全家桶虽好，一口吃不下啊。
Fortinet的解决方案则不然，它延续了之前其它方案的松耦合设计，不设置任何强捆绑。除了部署运维维度的管理和统一编排由独立产品实现，Fortinet把其它一切SD-WAN技术特性都装到了FortiGate里，并且不再收取额外的授权费用。这意味着简单的分支互联加速、上云加速和SaaS加速，都仅靠一台设备即可实现，建设成本和使用成本极低。
而FortiGate本身规格跨度又极大，最低甚至提供了满足几十人场景使用的型号，其成本甚至连十几个人的初创团队或外贸公司都能接受，让更多企业能用上品质优秀的SD-WAN。
这是绝大多数SD-WAN解决方案做不到的。
往下够低，还能往上够高。如果企业规模扩大了，需要建立更多分支，可以继续部署更多的FortiGate，并且考虑搭配使用Fortinet的交换机和AP搭建管理能力高、运维成本低的SD-Branch办公网方案；分支多到必须上控制器了，那就再加个Orchestrator编排模块；如果业务上云，不管私有云混合云还是公有云，都可以直接部署虚拟化版本的FortiGate，主流虚拟化环境都有原生支持……总之，不捆绑，不强制，穷能独善其身，达能兼济天下，这就是Fortinet的SD-WAN解决方案。
所以你明白我为什么一直认为Fortinet的方案是对初创企业、成长型企业和互联网为代表的数字原生企业最友好的一套SD-WAN解决方案了吧？我认为这才是业界权威咨询机构普遍给予它较高评价的根本原因。
实践是检验真理的唯一标准SD-WAN产品技术市场都很新，很多企业客户还没有足够的了解及经验。在这放一个前一阵刚竣工的具体案例，我全程参与的，希望能给大家提供有价值的参考。
某总部位于北京的知名互联网企业，在全国一线城市设有数个分支机构。他们的关键业务主要包括部署在某公有云海外节点的自研OA系统、部署在总部及多云环境下的开发环境、部署在多云下的生产环境和Microsoft 365海外版、ZOOM等办公协作平台。
之前，他们采用MPLS VPN的方式将分支与总部互联，再通过各分支机构的互联网接入线路起IPSEC VPN组网做为备份；所有流向研发环境和生产环境的流量都送回总部，再从总部申请的上云专线访问。随着业务流量越来越大，MPLS VPN带宽经常被跑满，并且由于采购成本较高，扩容的预算申请又迟迟得不到批复。另一方面，总部是有应用加速专线的，访问Microsoft 365和ZOOM品质没问题；分支没有这个待遇，投诉自然是居高不下。
此外，他们之前使用的传统网络和VPN组网方案也在不断受到挑战，比如内审和研发部门也一直在给IT部门施加压力，要求在网络层做更多、更严格的访问控制，确保访问跳板机的人员权限最小化。再比如远程办公使用的OpenVPN方案不够稳定，经常被员工投诉等等。
扛着这么大的压力，IT部门在今年初却接到行政部门的明确要求：降低IT运营成本。
火山爆发。
曲折的博弈过程就不提了，看看他们最终选择Fortinet SD-WAN分支互联方案带来的效果吧。
首先，IT部门在选型测试中发现，Fortinet SD-WAN分支互联方案基于普通企业专线/宽带的组网品质，就已经能够满足关键业务的体验要求。所以他们在部署阶段，将分支机构的互联网接入线路调整到两条，在充分满足带宽需求的情况下提升了可靠性。如果试运行阶段保持稳定，MPLS VPN到期后将不再续约，省下的都是真金白银。
他们并没有上Orchestrator（也就是Fortinet的控制器），只部署了FortiManager集中管理平台。毕竟现阶段分支数量不多，又没有需要调度的复杂流量，设备级SD-WAN就够用。另外就算现在上了控制器，能有点体验加成，但与投入也不成正比。需要的时候再说吧。
基于Fortinet SD-WAN方案的SaaS加速能力，IT部门还成功实现了将分支机构Microsoft 365和ZOOM的流量送回总部。这些流量从总部统一走应用加速线路，显著提升了体验，终于能向来自分支机构的大量投诉说再见了。
FortiGate本身就是优秀的下一代防火墙，其VPN性能及兼容性也久经考验，使得IT部门也借此机会解决了其它两个问题。他们将先前基于VLAN/IP段的访问控制策略升级为基于部门加应用的访问控制策略，满足了内审和研发部门的诉求，并且让运维管理变得更简单。而远程办公方案从OpenVPN切换到FortiGate的SSL VPN后，针对断线或稳定性的投诉频率从一两天下降到一两个月。
不过在这个过程中，他们也遇到一些挑战。最严重的一个问题就是，做为OA的一个大模块，他们的认证系统也是自己开发的，数据传输采用了私有协议，很难与通用商业方案对接。这也是他们之前办公网络始终没有打通认证平台的一个重要原因，并且在选型测试中也浪费了不少时间。而Fortinet的FortiAuthenticator统一认证平台具有足够多的开放接口及二次开发能力，让他们成功和自研认证系统对接，第一次将网络认证和平台认证融为一体，实现了单点登录。
比起SD-WAN、访问控制之类的地下工作，提升全体员工的上网体验才真正让IT部门站在了镁光灯下。
到此为止，Fortinet的SD-WAN方案在分支互联场景中已经体现了足够多的价值。但在IT部门眼中，他们似乎看到了更光明的未来。
一个有力的佐证是，他们正在加速验证VPC中部署的虚拟化版本的FortiGate的性能和稳定性。因为在之前的测试中他们已经发现，其实分支机构的互联网接入线路访问国内公有云上的业务品质也足够好。那既然统一认证都实现了，每个分支出口的安全需求也解决了，为什么还要让这部分流量到总部绕一圈呢？直接分支就SD-WAN上云，省下来更多总部的出口带宽不香嘛？
没错。未来，数字原生企业乃至所有企业的信息化路径中，零信任和SASE都是明确的路标。你看，当企业IT找到合适自身发展的技术路线，很多东西不用教、不用学，他自己就能明白了。
对了，在这个案例中，Fortinet的SD-WAN方案让IT部门在成就企业的同时还成就了自我——他们的KPI考核很有意思，IT部门可以申请采购，一般也都会被批准，但如果不在预算内且采购并没有达到降低成本的目的，IT部门所有人的绩效就没了。现在，我只能说感觉到他们发自肺腑的愉悦。
如果您想了解更多SD-WAN实战经验和关于本案例的解读，可以订阅关注我的号，再往前翻翻，相信会有更多收获；如果您有SD-WAN方面的疑问，或者项目遇到困惑，也欢迎后台留言讨论。
