SDWAN分支互联与互联网出口混合场景(Fortinet)

目录

项目背景与需求

  1. 稳定性要求：客户在会议上多次强调附近楼盘项目还在开发当中，经常出现某运营商的用着用着就断开的情况，客户希望要尽可能的稳定，在后期设计上要考虑到多运营商和多出口的冗余问题。
  2. 应用层分流需求：客户在通过在态势感知设备上发现公司内部微软windows更新类、icloud下载、在线短视频类等非生产流量占据了公司总流量的百分之四十左右，客户希望在出口设备实现应用层的分流，将非生产的类的流量指向性价比更高的家用宽带，将带有公网IP地址的链路专门留给生产类业务，传统防火墙无法实现应用层的分流，所以采用SD-WAN的分流功能以完成应用层面的分流选路。
  3. 分支互联要求，客户本身防火墙就通过gre over ipsec连接着杭州和西安两个分支机构，使用sd-wan依然要保持连接，而且要有冗余链路。

方案规则

拓扑图

image

总部Hub端

总部物理链路规划：

  • 第一条：带公网IP地址的电信链路
  • 第二条：带公网IP地址的联通链路
  • 第三条：MPLS 专线

总部上网规划

  • 利用带公网IP地址的电信链路出口SNAT
  • 利用带公网IP地址的联通链路出口SNAT
  • 将以上两个链路加入SD-WAN ZONE当中，充分利用SD-WAN优势，利用LSA链路质量进行选路

总部与分支互联规划：

  • 主用MPLS链路
  • 利用电信和联通做IPSEC，两条IPSEC虚拟链路做为备用

分支Spoke端

分支出口方案：

  • 带公网IP地址的电信链路(与总部要契合)
  • PPPOE拨号的联通链路(与总部要契合，可以采用PPPOE，也可以建立IPSEC隧道)
  • MPLS 专线

总部与分支互联方案：

  • 主用MPLS链路
  • 利用电信和联通做IPSEC，两条IPSEC虚拟链路做为备用

分支上网规划：

  1. 电信链路(带公网IP地址)，做SNAT
  2. 联通链路(PPPOE拨号)，做SNAT

实施思路

Hub端

需求分析

总部客户的需求整体来看比较简单：

  • 上网需求
  • 访问分支机构的需求

SD-WAN ZONE 规划（三实两虚共五根链路划分为两个SD-WAN区域）：

  • TO_Spoke_Zone（三根链路，一实两虚）
    • MPLS 主用
    • 电信虚拟IPSEC链路
    • 联通虚拟IPSEC链路
  • To_Internet_Zone（两根链路，两实）
    • 电信链路，通过IP地址池做SANT
    • 联通链路，通过IP地址池做SNAT

实施规划

Hub访问Spoke端sd-wan规则规划

  1. 利用性能LSA模块选择出最优的链路，成员选择MPLS专线接口、联通线路的IPSec接口和电信线路的IPSec接口。探测模式为tcp-connect，探测端口为80或443，指定探测的源IP为本端内网口IP，目的是分支机构内部的某个常用WEB应用，开启SLA目标：延迟<250ms/抖动<50ms/丢包率<5%。正常情况下，不出意外的话应该是TO_Spoke_Zone当中的MPLS链路最优；
  2. 新建SD-WAN规则，策略选择上一步新建的SLA，接口偏好使用MPLS专线，如果三条链路都满足LSA的话，默认使用接口编号靠前的接口。
  3. 规则完成之后通过日志界面进行验证，看是否匹配了我们新建的规则。注意，在规则新建之后默认会有一个探测和学习的过程，大约要等一分钟后才会在日志当中有所体现。

Hub端访问internet端sd-wan规则规划：

  1. 利用性能LSA模块选择出最优的链路，成员选电信链路和联通链路。探测模式依然为TCP，目标指向微信、阿里或百度等大型应用WEB，开启SLA目标：延迟<250ms/抖动<50ms/丢包率<5%。正常情况下，两条链路应该是差不多的延迟。
  2. 新建第二条SD-WAN规则，策略选择上一步新建的SLA，接口偏好使用电信（电信较联通相对稳定，根据地域差异有所不同），如果两条条链路都满足LSA的话，默认使用接口编号靠前的接口。
  3. 规则完成之后通过日志界面进行验证

Spoke端

需求分析

总部客户的需求整体来看比较简单：

  • 上网需求
  • 访问总部的需求

SD-WAN ZONE 规划（三实两虚共五根链路划分为两个SD-WAN区域）：

  • TO_Hub_Zone（三根链路，一实两虚）
    • MPLS 主用
    • 电信虚拟IPSEC链路备用
    • 联通虚拟IPSEC链路备用（分支没有固定IP地址，所以做IPSEC时需要分支先发起链接）
  • To_Internet_Zone（两根链路，两实）
    • 电信链路，通过IP地址池做SANT
    • 联通链路，通过IP地址池做SNAT

实施规划

Spoke访问Spoke端sd-wan规则规划

  1. 利用性能LSA模块选择出最优的链路，成员选择MPLS专线接口、联通线路的IPSec接口和电信线路的IPSec接口。探测模式为tcp-connect，探测端口为80或443，指定探测的源IP为本端内网口IP，目的是分支机构内部的某个常用WEB应用，开启SLA目标：延迟<250ms/抖动<50ms/丢包率<5%。正常情况下，不出意外的话应该是TO_Hub_Zone当中的MPLS链路最优；
  2. 新建SD-WAN规则，策略选择上一步新建的SLA，接口偏好使用MPLS专线，如果三条链路都满足LSA的话，默认使用接口编号靠前的接口。
  3. 规则完成之后通过日志界面进行验证，看是否匹配了我们新建的规则。注意，在规则新建之后默认会有一个探测和学习的过程，大约要等一分钟后才会在日志当中有所体现。

Spoke端访问internet端sd-wan规则规划：

  1. 利用性能LSA模块选择出最优的链路，成员选电信链路和联通链路。探测模式依然为TCP，目标指向微信、阿里或百度等大型应用WEB，开启SLA目标：延迟<250ms/抖动<50ms/丢包率<5%。正常情况下，两条链路应该是差不多的延迟。
  2. 新建第二条SD-WAN规则，策略选择上一步新建的SLA，接口偏好使用电信（电信较联通相对稳定，根据地域差异有所不同），如果两条条链路都满足LSA的话，默认使用接口编号靠前的接口。
  3. 规则完成之后通过日志界面进行验证

注意事项

关于IPSEC

  1. 当我们做完IPSEC之后，在配置都没错的情况下，可能会发现IPSEC隧道并没有起来，原因是因为IPSEC并非GRE通过路由驱动，而是通过感兴趣的流来驱动，所以当做完IPSEC之后需要通过感兴趣的流来探测是否生效。
  2. 在spoke端设置两条ipsec的源地址时，两条ipsec是相互备用，所以感兴趣流当中的源地址是一样的，不要忘记在IPSEC的第二阶段勾选“set route-overlap allow”配置。

关于带宽问题

在做完IPSEC之后要测试是否能跑满带宽，这一步一定要做，尤其是在PPPOE的链路的IPSEC链路，如果跑不满的话可以在防火墙上进行抓包分析，看是否是因为MTU导致分片问题，如果是分片问题需要调整mss值。

关于验收

在项目完成之后，要进行链路故障的模拟，看是否主用挂了之后备用是否会自动生效，当主用恢复之后，看流量是否会从备用再切换回主用，完成测试之后除了要在微信群当中反馈，还要通过邮件发送给客户并抄送本公司领导。

posted @ 2020-04-06 13:56  张贺贺呀  阅读(565)  评论(0)    收藏  举报