win10系统vpn不能上网
网络世界永恒的话题,就是组网。从局域网,城域网到广域网,每个细分领域都有说不完的话题。今天,我们把话题聚焦在企业多分支互联的组网上。
企业多分支的组网,用通俗的话讲,就是企业的多个分支,通过虚拟专用网络技术,以Internet网络为基础,进行私有网络互联。当然,也有土豪套餐,就是全程采用专线技术,构建企业自己的私有网络。今天,我们暂不讨论土豪套餐,重点关注前者。
实际组网中最常见的是公司总部与多个分支机构通过点到多点IPSec VPN互通,典型组网如下图所示
从数据路径上分析,路径二缺点很明显:到总部中转的代价是,浪费带宽资源,浪费总部设备资源,延长数据路径,增加故障点。
从配置管理角度看,IPSec的底层配置逻辑还是略显复杂,需要资深网工才能驾驭,能理解下图,方能开工。
理解了配置原理,设计好了配置模板,再来看配置工作量:每添加一个分支,都要配置一遍。大规模部署,不得不考虑一下。
传统Hub-Spoke的组网模型,分支之间的流量需要绕行Hub,带来了诸多缺陷,在多数场景是不允许的。
一种简单的解决方案,就是需要通信的站点之间都建立IPSec隧道,流量按需选择隧道,也就是Full-Mesh组网模型。但这种只是理论上的解决方案,配置管理指数级增长,且要求每个站点都具备公网IP,落地不切实际。
先建立Hub-Spoke模型的IPSec隧道。Spoke与Spoke之间的隧道则是按需动态建立的,采用动态点对多点的GRE隧道技术 MGRE。Spoke与Spoke建立之前,必须知道对方的地址;这依赖NHRP(下一跳解析协议)来实现。NHRP,基于C/S模型,Hub端充当Server,Spoke端充当Client,Client端启动后,会向Server端注册,Server端会获取和管理所有Client端的隧道信息。DMVPN,当一个Spoke想向另一个Spoke发送数据时,首先需要到Server端查询对端Spoke的信息,然后动态建立隧道,进行数据传输;同时,需要进行隧道保活,当一段时间没有数据后,隧道拆除。动态路由,动态路由协议需要运行在隧道上,用于站点之间的业务路由学习与更新。
面向企业的SDWAN解决方案是对传统的IPSec VPN组网的延伸,在企业各个站点边缘的CPE间建立隧道,无论是走Internet还是其他专线,都只提供Underlay的传输线路,企业的组网完全在服务提供商提供的网络之上。从物理上来看,CPE可放在企业的总部/数据中心/分支网,而从组网上来看,无论是Hub-Spoke还是Full Mesh,各站点间逻辑上都是一跳可达。
从数据路径上看,面向企业的SDWAN模式,和传统的VPN组网并没有不同。那么,这种方案到底带来了哪些改进呢?概括起来,主要有以下几个方面:
引入了控制器的角色,用于CPE的发现与管理,并动态向其下发用于建立隧道的信息,以及组网所需要的路由信息,大大的提高了配置效率。
上述优势非常明显,但也有明显的不足,就是数通通路还是承载在公共网络之上的,所有的链路优化也是基于公共网络的,在某些场景下,质量与专线: 面向服务提供商的SDWAN
首先说明一下,SDWAN2.0并非SDWAN1.0简单的升级版本,准确的说,应该是两种不同的解决方案思路。所以,增加了”面向企业“和”面向服务提供商“的描述。
该方案的组网方式与数据路径较之前发生了较大的改变,CPE只需要与就近的POP点建立IPSec隧道,从而实现了个企业分支之间的互联。其优势总结如下:
该方案的基本思路是,在同城或同省互联,且公共网络的服务质量可以满足的场景下,采用CPE与CPE之间直接建立隧道的方式,其分支流量不经过POP节点;同城/省内的一台/两台Hub节点接入到POP点,为该城/省内其他分支访问其他城/省的分支提供数据通路win10系统vpn不能上网。其效果是,同城/省内直接互访,跨城/省经过POP节点互访,达到了不同场景下的路径最优化。
上述比较可以看出,面向企业+服务提供商相结合的SDWAN组网方式,对于跨地域多分支的组网,适应能力更强,应用更灵活。