主頁 > 軟體設計 > DSVNP原理以及相關配置

DSVNP原理以及相關配置

2021-03-06 10:50:28 軟體設計

DSVPN簡介

動態智能VPN（Dynamic Smart Virtual Private Network），是一種在HUB-SPOKE組網方式下為公網地址動態變化的分支之間建立VPN隧道的解決方案，

背景

越來越多的企業希望建立Hub-Spoke方式的IPSec VPN網路將企業總部（Hub）與地理位置不同的多個分支（Spoke）相連，從而加強企業的通信安全、降低通信成本，當企業總部采用靜態的公網地址接入Internet，分支機構采用動態的公網地址接入Internet時，使用傳統的IPSec、GRE over IPSec等技術構建VPN網路將存在一個問題，即分支之間無法直接通信（源分支無法獲取目的分支公網地址，也就無法在分支之間直接建立隧道），所有分支之間的通信資料只能由總部中轉，

在這里插入圖片描述

缺點：

  • 總部在中轉分支之間的資料流時會消耗總部HUB的CPU及記憶體資源，造成資源緊張，

  • 總部要對分支間的資料流封裝和解封裝，會引入額外的網路延時，

  • 當IPSec網路規模不斷擴展時，為減少路由配置和維護，需要部署動態路由協議，但IPSec和動態路由協議之間存在一個基礎問題，動態路由協議依賴于組播協議報文或廣播協議報文進行路由更新，而IPSec不支持廣播報文和組播報文的傳輸，

DSVPN基本概念

DSVPN典型網路架構
在這里插入圖片描述

該網路中，當源Spoke需要向目的Spoke發送資料報文時，源Spoke將通過與Hub之間的靜態mGRE隧道互動NHRP協議獲取目的Spoke的公網地址，并與目的Spoke建立動態mGRE隧道，隧道建立完成后，Spoke與Spoke之間的資料報文將通過該動態mGRE隧道直接發送給對方，不再經過總部Hub中轉，

mGRE隧道介面

mGRE隧道介面包含以下元素：

  • 隧道源地址：GRE封裝后的報文源地址，圖中隧道一端的公網地址，
  • 隧道目的地址：GRE封裝后的報文目的地址，即圖中隧道另一端的公網地址，與GRE隧道介面手工指定目的地址不同，mGRE隧道目的地址來自于NHRP協議，
  • 隧道介面IP地址：隧道介面地址和其他物理介面上的IP地址一樣，用于設備之間的通信（例如獲取路由資訊等），即圖中的Tunnel地址，

采用mGRE隧道介面建立起來的GRE隧道稱為mGRE隧道，mGRE隧道分為靜態mGRE隧道和動態mGRE隧道兩種：

  • 靜態mGRE隧道建立于分支Spoke與總部Hub之間，靜態mGRE隧道永久存在，
  • 動態mGRE隧道建立于各分支Spoke之間，動態mGRE隧道在一定周期內沒有流量轉發將自動拆除，

DSVPN基本原理

DSVPN實作分支之間直接通信的關鍵是在分支之間建立隧道，DSVPN利用mGRE結合NHRP來建立分支之間的隧道，與GRE不同，mGRE建立隧道時不需要定義隧道目的地址，而是依賴NHRP告訴它，這就為在動態地址變化的分支間建立隧道創造了條件，

mGRE與NHRP結合建立隧道的基本原理是：當設備轉發一個IP報文時，根據路由表將IP報文傳給下一跳的出介面mGRE隧道介面，mGRE在NHRP映射表中查找獲取下一跳地址映射的對端公網地址，然后mGRE封裝IP報文，加上新IP頭，目的地址就是對端的公網地址，這樣IP報文就能發向隧道對端，隧道即可建立，

三個環節：

  1. 建立Spoke與Hub之間的mGRE隧道

    這一環節的目的是打通分支到分支報文轉發的通道，使得一端分支的報文可以借助Hub轉發到另一端分支，

    DSVPN在Spoke與Hub之間建立的mGRE隧道是一種靜態隧道，無論Spoke與Hub間是否有流量經過，該隧道一直存在，

  2. 分支間路由學習

    這一環節的目的是生成一端分支到另一端分支的路由，

  3. 建立Spoke與Spoke之間的mGRE隧道

    這一環節的目的是建立用于分支間直接通信的通道，當一個分支向另一個分支轉發資料報文時，如果源Spoke找不到目的Spoke的公網地址，則會觸發DSVPN建立Spoke與Spoke之間的mGRE隧道，

    Spoke與Spoke之間建立的mGRE隧道是一種動態隧道，當Spoke與Spoke間有流量通過時，隧道自動保活；當一定周期內沒有流量經過時，隧道自動拆除，

1.建立Spoke與Hub之間的mGRE隧道

在這里插入圖片描述

DSVPN網路開始時，總部Hub的NHRP映射表是空表，分支Spoke有一個靜態配置的NHRP映射表（Hub的Tunnel地址與公網地址的映射），分支Spoke和總部Hub有到彼此的路由，要建立Spoke與Hub之間的mGRE隧道，總部要生成各分支Tunnel地址/子網地址與公網地址的NHRP映射表，這主要通過分支Spoke向總部Hub進行NHRP注冊來實作

  1. Spoke向Hub注冊請求

    管理員在Spoke上手工配置Hub的Tunnel地址和公網地址以后，Spoke將定時向Hub發送NHRP注冊請求報文，該報文中包含Spoke的Tunnel地址和公網地址，

  2. Hub向Spoke注冊應答

    Hub從NHRP注冊請求報文中提取Spoke的Tunnel地址和公網地址，并生成NHRP映射表，進而建立兩者之間的mGRE隧道，

2.分支間路由學習

分支間相互學習路由（非shortcut方式）

每個分支需要學習到所有對端的路由資料，這種情況下，Spoke會消耗大量的CPU和記憶體資源，對其路由表容量和性能有較高的要求，而實際應用中，Spoke的性能往往較低，能存放的路由數量有限，因此，這種路由學習方式只適用于網路節點較少、路由資訊量小的中小型網路，

分支路由匯聚到總部（shortcut方式）

實作所有訪問目的分支的流量全部指向總部Hub，分支間不需要相互學習路由，通過總部對分支路由匯聚后進行通告，該路由學習方式適用于那些網路規模大、分支較多的大型網路，

3.建立Spoke與Spoke之間的mGRE隧道

  • 非shortcut方式下，源Spoke可以學習到目的Spoke的Tunnel地址，因此，源Spoke可以直接根據目的Spoke的Tunnel地址來查找目的Spoke的公網地址，生成目的Spoke的Tunnel地址與公網地址的NHRP映射表，
  • shortcut方式下，所有Spoke的路由下一跳全部都是Hub的Tunnel地址，源Spoke無法學習到目的Spoke的Tunnel地址，因此，源Spoke只能根據報文的目的地址來查找目的Spoke的公網地址，生成目的Spoke的子網地址與公網地址的NHRP映射表，

非shortcut方式

在這里插入圖片描述

當Spoke1下的用戶首次訪問Spoke2下的用戶時，將觸發Spoke1與Spoke2之間建立動態mGRE隧道，隧道建立程序如下：

  1. Spoke1收到其下用戶發往Spoke2的資料報文后：

    • 根據報文目的地址（192.168.2.0）在路由表中找到下一跳10.1.1.2（Spoke2的Tunnel地址），但在NHRP映射表中沒有查找10.1.1.2對應的公網地址，就默認將該資料報文直接轉發給Hub，
    • 構建并向Hub發送NHRP地址決議請求報文，請求10.1.1.2對應的公網地址，

  2. Hub收到Spoke1發送的資料報文和NHRP地址決議請求報文后，將報文通過Hub與Spoke2間的mGRE隧道轉發給Spoke2，

  3. Spoke2收到NHRP地址決議請求報文后：

    • 從NHRP地址決議請求報文中提取Spoke1的Tunnel地址和公網地址，并將該資訊更新到自己的NHRP映射表中（見圖4-5中的紅色字體），
    • 構建并向Spoke1發送NHRP地址決議應答報文（攜帶Spoke2的Tunnel地址10.1.1.2和公網地址2.2.2.2），

  4. Spoke1收到NHRP地址決議應答報文后，從應答報文中提取Spoke2的Tunnel地址和公網地址，更新到自己的NHRP映射表中（見圖4-5中的紅色字體），Spoke1與Spoke2之間的動態mGRE隧道隨即建立，

    當Spoke1再次收到其下用戶發送給Spoke2的資料報文時，Spoke1根據報文目的地址（192.168.2.0）在路由表中找到下一跳10.1.1.2，再根據10.1.1.2在NHRP映射表中找到公網地址2.2.2.2，即可按照公網地址2.2.2.2將此報文進行mGRE封裝后直接發送給Spoke2，不再經過總部Hub，

shortcut方式

在這里插入圖片描述

當Spoke1下的用戶首次訪問Spoke2下的用戶時，將觸發Spoke1與Spoke2之間建立動態mGRE隧道，隧道建立程序如下：

  1. Spoke1收到其下用戶發往Spoke2下用戶的資料報文后，根據報文目的地址（192.168.2.0）在路由表中找到下一跳10.1.1.3（Hub的Tunnel地址），并在NHRP映射表中找到10.1.1.3對應的公網地址3.3.3.3（Hub的公網地址），就將資料報文轉發給Hub，

  2. Hub收到Spoke1轉發的資料報文后：

    • 將此報文通過Hub與Spoke2間的mGRE隧道轉發給Spoke2，
    • 檢查發現接收和發送資料報文的Tunnel介面屬于同一個NHRP域（見nhrp network-id），就構建并向Spoke1發送NHRP重定向報文（攜帶Hub的Tunnel地址和公網地址，以及需要決議的資料報文的目的地址192.168.2.0），

  3. Spoke1收到NHRP重定向報文后，構建并向Hub發送NHRP地址決議請求報文（攜帶Spoke1的Tunnel地址10.1.1.1和公網地址1.1.1.1，以及需要決議的資料報文的目的地址192.168.2.0），

  4. Hub收到NHRP地址決議請求報文后轉發給Spoke2處理，

  5. Spoke2收到NHRP地址決議請求報文后：

    • 從NHRP地址決議請求中提取Spoke1的Tunnel地址和公網地址，并將該資訊更新到自己的NHRP映射表中（見圖4-6中的紅色字體），
    • 構建并向Spoke1發送NHRP地址決議應答報文（攜帶Spoke2的子網地址192.168.2.0、Spoke2的Tunnel地址10.1.1.2和公網地址2.2.2.2），

  6. Spoke1收到NHRP地址決議應答報文后，從應答報文中提取Spoke2的子網地址和公網地址，更新到自己的NHRP映射表中（見圖4-6中的紅色字體），Spoke1與Spoke2之間的動態mGRE隧道隨即建立，

    當Spoke1再次收到其下用戶發送給Spoke2的資料報文時，Spoke1根據報文目的地址（192.168.2.0）查找NHRP映射表，找到Spoke2的公網地址2.2.2.2，即可根據公網地址2.2.2.2將此報文進行mGRE封裝后直接發送給Spoke2，不再經過總部Hub，

DSVPN NAT穿越

在這里插入圖片描述

DSVPN NAT穿越主要通過在NHRP注冊應答報文、NHRP決議請求/應答報文中的NAT擴展欄位中填充分支NAT前后的地址資訊而實作，具體作業原理如下：

  1. 分支Spoke向總部Hub注冊，NHRP注冊請求報文中攜帶分支原始的公網或私網地址，
  2. 總部Hub的NHRP協議感知分支路徑中有NAT設備存在，就在NHRP注冊請求應答報文的NAT擴展欄位中將分支NAT轉換后的公網地址告知分支Spoke，
  3. 源Spoke向目的Spoke發起NHRP地址決議請求時，攜帶源分支NAT轉換前的地址和NAT轉換后的公網地址（通過NAT擴展欄位）告知目的Spoke，
  4. 目的Spoke向源Spoke回傳NHRP地址決議請求應答時，攜帶目的分支NAT轉換前的地址和NAT轉換后的公網地址（通過NAT擴展欄位）告知源Spoke，
  5. 源分支和目的分支互相知道對端NAT轉換前的地址和NAT轉換后的公網地址后，根據NAT轉換后的公網地址建立動態mGRE隧道，實作分支間穿越NAT直接通信
  • DSVPN不支持兩個分支位于同一NAT設備之后且NAT轉換后IP地址相同的NAT穿越，
  • DSVPN不支持兩個分支位于不同NAT設備之后且啟用PAT（Port Address Translation）功能的NAT穿越，
  • 分支間互訪時，NAT設備必須配置為NAT Server或Static NAT，DSVPN不支持配置為NAT outbound的NAT穿越，
  • 在DSVPN中部署IPSec時，如果兩個分支位于不同NAT設備之后或者總部位于NAT設備之后，則IPSec封裝模式僅支持為傳輸模式，因為IPSec封裝模式為隧道模式時，NHRP無法學習到NAT轉換后的地址，

DSVPN IPSec保護

在這里插入圖片描述

DSVPN網路中，通過在總部Hub和分支Spoke配置IPSec安全框架并系結于mGRE隧道介面，mGRE隧道建立的同時會立即觸發IPSec隧道建立，具體作業原理如下：

  1. 網路中的所有Spoke向總部Hub發起注冊請求，同時將NHRP映射表資訊告知IPSec，觸發分支和總部的IKE模塊進行IPSec隧道的協商，
  2. 總部Hub根據接收的注冊請求報文，記錄Spoke的Tunnel地址和公網地址的對應關系，生成分支的NHRP映射表，并向Spoke發送注冊請求應答訊息，
  3. 分支間根據流量觸發建立動態mGRE隧道，
  4. 分支Spoke間動態mGRE隧道建立時，IPSec模塊獲取NHRP映射表資訊，根據該資訊添加或洗掉IPSec對等體節點，觸發分支間動態建立IPSec隧道，
  5. 分支Spoke間IPSec隧道建立成功后，后續資料轉發根據IP報文的目的地址查找路由，如果出介面型別是mGRE隧道介面，則根據路由下一跳找NHRP映射表，獲取公網地址，根據公網地址，找IPSec SA，對報文進行IPSec加密發送，

相對于傳統Hub-Spoke組網的IPSec技術，DSVPN與IPSec聯合部署具有如下優勢：

  • 傳統IPSec技術使用ACL識別待加密的單播流量，需進行復雜的ACL定義，配置和維護困難，而DSVPN中只需將mGRE隧道介面與IPSec安全框架系結，無需再定義復雜的ACL，網路部署更加簡單，
  • 由于動態建立了分支間的IPSec隧道，分支Spoke間互動的IPSec資料不用通過總部Hub進行解密和加密操作，降低了資料傳輸時延，

在DSVPN中部署IPSec時，如果兩個分支位于不同NAT設備之后或者總部位于NAT設備之后，則IPSec封裝模式僅支持為傳輸模式，因為IPSec封裝模式為隧道模式時，NHRP無法學習到NAT轉換后的地址，

DSVPN可靠性

雙HUB主備備份

在這里插入圖片描述

DSVPN雙Hub主備備份的作業機制如下：

  1. 所有分支Spoke同時向主用Hub1和備用Hub2注冊，并分別與Hub1建立主用靜態mGRE隧道、與Hub2建立備用靜態mGRE隧道，
  2. 當分支間需要建立動態mGRE隧道時，源Spoke向Hub發送NHRP地址決議請求報文：
    • 在Hub1和Hub2都運行正常的情況下，根據路由策略，Spoke到Hub1的路由優先級較高，NHRP地址決議請求報文將沿主用靜態mGRE隧道發送到Hub1，由Hub1將此決議報文轉發至目的Spoke，
    • 當Hub1出現故障時，Spoke到Hub1的路由優先級降低，NHRP地址決議請求報文沿備用靜態mGRE隧道發送到Hub2，由Hub2將此決議報文轉發至目的Spoke，
    • 當Hub1故障恢復后，各分支Spoke到Hub1的路由優先級又重新高于到Hub2的路由優先級，NHRP地址決議請求報文重新交由Hub1轉發，
  3. 目的Spoke向源Spoke回應NHRP地址決議回應報文，動態mGRE隧道建立，
  4. 動態mGRE隧道建立后，分支Spoke間可直接進行通信，此時，Hub設備運行正常與否不會對各分支Spoke間的業務流產生影響，如果分支Spoke之間的動態mGRE隧道由于長時間沒有流量經過被拆除了，Spoke與Spoke之間通信時就需要重新建立動態mGRE隧道，Spoke會重新根據路由優先級判斷向哪個Hub發送NHRP地址決議請求報文，

雙HUB負載分擔

在這里插入圖片描述

不同Hub下的Spoke間直接通信原理如下：

  1. 源Spoke1發送NHRP地址決議請求報文發送給Hub1，請求目的SpokeN的公網地址，
  2. Hub1將源Spoke1的NHRP地址決議請求報文通過Hub1與Hub2之間的靜態mGRE隧道轉發給Hub2，
  3. Hub2將源Spoke1的NHRP地址決議請求報文轉發給目的SpokeN，
  4. 目的SpokeN從報文中獲取源Spoke1的公網地址，并給源Spoke1回應NHRP地址決議應答報文，
  5. 源Spoke1從NHRP地址決議應答報文中獲取目的SpokeN的公網地址，并與目的SpokeN建立動態mGRE隧道，

動態mGRE隧道建立后，兩個不同Hub下的Spoke之間即可進行直接通信，

DSVPN應用場景

中小型網路部署DSVPN

在這里插入圖片描述

大型網路部署DSVPN

在這里插入圖片描述

Hub級聯網路部署DSVPN

在這里插入圖片描述

部署DSVPN時，Hub1和Hub2上需創建兩個Tunnel介面，分別與Hub和對應的Spoke建立靜態mGRE隧道，對于Hub來說，Hub1和Hub2可以當做分支Spoke，

Hub級聯網路部署DSVPN時，分支間路由學習方式僅支持shortcut方式，

配置舉例

配置shortcutDSVPN示例（ospf路由協議）

在這里插入圖片描述
在這里插入圖片描述

查看spoke1的nhrp表
請添加圖片描述
請添加圖片描述
請添加圖片描述

請添加圖片描述

HUB上配置

[Hub] interface tunnel 0/0/0
[Hub-Tunnel0/0/0] tunnel-protocol gre p2mp
[Hub-Tunnel0/0/0] source GigabitEthernet 1/0/0
[Hub-Tunnel0/0/0] nhrp entry multicast dynamic
[Hub-Tunnel0/0/0] ospf network-type p2mp
[Hub-Tunnel0/0/0] nhrp redirect
[Hub-Tunnel0/0/0] quit

Spoke上配置

[Spoke1] interface tunnel 0/0/0
[Spoke1-Tunnel0/0/0] tunnel-protocol gre p2mp
[Spoke1-Tunnel0/0/0] source GigabitEthernet 1/0/0
[Spoke1-Tunnel0/0/0] nhrp entry 172.16.1.1 1.1.1.10 register
[Spoke1-Tunnel0/0/0] ospf network-type p2mp
[Spoke1-Tunnel0/0/0] nhrp shortcut
[Spoke1-Tunnel0/0/0] quit

配置非shortcut方式DSVPN（ospf協議）

在這里插入圖片描述

  • 正常情況下，配置介面網路模式為p2mp模式，R2與R3相互通信需要經過R1中轉，不可以直接互通，
  • 如果修改介面網路模式為broadcast模式，R2與R3通信可以直接通信，不用R1中轉，但是需要選舉DR/BDR，而且需要修改非DR的ospf-dr-priority為0，放棄選舉來固定DR位置，雖然可以實作分支間的vpn互聯，但是在DSVPN Hub級聯情況下，不可以實作分支間互聯，如下面的實驗，
  • p2mp模式下，配置shortcut以及reflect可以實作分支間的vpn互聯

AR1配置

#
 sysname R1
#
interface GigabitEthernet0/0/0
 ip address 11.1.1.1 255.255.255.0 
#
interface GigabitEthernet0/0/1
#
interface GigabitEthernet0/0/2
#
interface LoopBack0
 ip address 192.168.1.1 255.255.255.0 
#
interface Tunnel0/0/0
 ip address 10.1.1.1 255.255.255.0 
 tunnel-protocol gre p2mp
 source GigabitEthernet0/0/0
 ospf network-type broadcast
 nhrp entry multicast dynamic
#
ospf 1 router-id 1.1.1.1 
 area 0.0.0.0 
  network 11.1.1.0 0.0.0.255 
#
ospf 2 router-id 1.1.1.1 
 area 0.0.0.0 
  network 10.1.1.0 0.0.0.255 
  network 192.168.0.0 0.0.255.255 
#

AR2配置

#
 sysname R2
#
interface GigabitEthernet0/0/0
 ip address 12.1.1.1 255.255.255.0 
#
interface GigabitEthernet0/0/1
#
interface GigabitEthernet0/0/2
#
interface LoopBack0
 ip address 192.168.2.1 255.255.255.0 
#
interface Tunnel0/0/0
 ip address 10.1.1.2 255.255.255.0 
 tunnel-protocol gre p2mp
 source GigabitEthernet0/0/0
 ospf network-type broadcast
 ospf dr-priority 0
 nhrp entry 10.1.1.1 11.1.1.1 register
#
ospf 1 router-id 2.2.2.2 
 area 0.0.0.0 
  network 12.1.1.0 0.0.0.255 
#
ospf 2 router-id 2.2.2.2 
 area 0.0.0.0 
  network 10.1.1.0 0.0.0.255 
  network 192.168.0.0 0.0.255.255 
#

R1配置

#
sysname ISP
#
interface Ethernet0/0/0
 ip address 11.1.1.2 255.255.255.0
#
interface Ethernet0/0/1
 ip address 12.1.1.2 255.255.255.0
#
interface GigabitEthernet0/0/0
 ip address 13.1.1.2 255.255.255.0
#
ospf 1 router-id 11.11.11.11
 area 0.0.0.0
  network 0.0.0.0 255.255.255.255
#

normal
必須是明細路由
spoke可以主動發起
得到NHRP映射關系是 tunnle-公網地址

shortcut
必須是匯總路由
spoke被動發起
得到NHRP映射關系是 私網地址----公網地址

配置跨NAT DSVPN

分支通過NAT設備進行地址轉換后接入公網，企業現網網路規劃使用OSPF路由協議，

現在用戶希望能夠實作分支之間的VPN互聯，

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-1SL5mcU1-1614856053143)(E:\Typora\image\image-20210304161812585.png)]
在這里插入圖片描述

配置DSVPN雙Hub主備備份示例

在這里插入圖片描述

簡單配置不在贅述

[Hub1-Tunnel0/0/0] ospf cost 1000
[Hub2-Tunnel0/0/0] ospf cost 3000
[Spoke1-Tunnel0/0/0] nhrp registration interval 300
  • 在Hub1和Hub2配置不同的ospf cost值是為了讓Spoke優先選取Hub1作為路由的下一跳，
  • 在Hub1從故障中恢復之后，只有等到Spoke向其進行注冊之后，才能重新進行OSPF協議報文互動，Spoke在原有路由老化之后學習到Hub1的路由，為了讓Spoke快速感知Hub1，可以將Spoke的注冊間隔調整到合適的值（默認注冊間隔為1800秒），

配置IPSec保護的DSVPN示例

在這里插入圖片描述

1.配置介面IP地址

在各Router上配置介面IP地址，

system-view
[Huawei] sysname Hub
[Hub] interface GigabitEthernet 1/0/0
[Hub-GigabitEthernet1/0/0] ip address 1.1.1.10 255.255.255.0
[Hub-GigabitEthernet1/0/0] quit
[Hub] interface tunnel 0/0/0
[Hub-Tunnel0/0/0] ip address 172.16.1.1 255.255.255.0
[Hub-Tunnel0/0/0] quit
[Hub] interface loopback 0
[Hub-LoopBack0] ip address 192.168.0.1 255.255.255.0
[Hub-LoopBack0] quit
按照圖4-23配置Spoke1、Spoke2各介面的IP地址，具體配置程序與配置Hub相同（略），

2.配置各Router之間公網路由可達

在各Router上配置OSPF路由協議，實作公網路由可達，

在Hub上配置OSPF，

[Hub] ospf 2 router-id 1.1.1.10
[Hub-ospf-2] area 0.0.0.1
[Hub-ospf-2-area-0.0.0.1] network 1.1.1.0 0.0.0.255
[Hub-ospf-2-area-0.0.0.1] quit
[Hub-ospf-2] quit

在Spoke1上配置OSPF，

在Spoke2上配置OSPF，

3.配置OSPF基本功能

配置Hub，

[Hub] ospf 1 router-id 172.16.1.1
[Hub-ospf-1] area 0.0.0.0
[Hub-ospf-1-area-0.0.0.0] network 172.16.1.0 0.0.0.255
[Hub-ospf-1-area-0.0.0.0] network 192.168.0.0 0.0.0.255
[Hub-ospf-1-area-0.0.0.0] quit
[Hub-ospf-1] quit

配置Spoke1，

配置Spoke2，

4.配置IKE提議

在Hub和Spoke上配置IKE提議，選擇相同的認證方式，

配置Hub，

[Hub] ike proposal 1
[Hub-ike-proposal-1] dh group5
[Hub-ike-proposal-1] authentication-algorithm sha2-256
[Hub-ike-proposal-1] prf aes-xcbc-128
[Hub-ike-proposal-1] quit

配置Spoke1，

配置Spoke2，

5.配置IKE peer

在Hub和Spoke上配置進行IKE協商時需要的IKE peer，

配置Hub，

[Hub] ike peer hub
[Hub-ike-peer-hub] ike-proposal 1
[Hub-ike-peer-hub] pre-shared-key cipher Huawei@1234
[Hub-ike-peer-hub] dpd type periodic
[Hub-ike-peer-hub] dpd idle-time 40
[Hub-ike-peer-hub] quit

配置Spoke1，

配置Spoke2，

6.創建安全提議

在Hub和Spoke上配置安全提議，

配置Hub，

[Hub] ipsec proposal pro1
[Hub-ipsec-proposal-pro1] transform ah-esp
[Hub-ipsec-proposal-pro1] ah authentication-algorithm sha2-256
[Hub-ipsec-proposal-pro1] esp authentication-algorithm sha2-256
[Hub-ipsec-proposal-pro1] esp encryption-algorithm aes-192
[Hub-ipsec-proposal-pro1] quit

配置Spoke1，

配置Spoke2，

7.配置安全框架

在Hub和Spoke上配置安全框架，

配置Hub，

[Hub] ipsec profile profile1
[Hub-ipsec-profile-profile1] ike-peer hub
[Hub-ipsec-profile-profile1] proposal pro1
[Hub-ipsec-profile-profile1] quit

配置Spoke1，

配置Spoke2，

7.配置Tunnel介面

在Hub上配置Tunnel介面和OSPF相關屬性，應用安全框架，

[Hub] interface tunnel 0/0/0
[Hub-Tunnel0/0/0] tunnel-protocol gre p2mp
[Hub-Tunnel0/0/0] source GigabitEthernet 1/0/0
[Hub-Tunnel0/0/0] nhrp entry multicast dynamic
[Hub-Tunnel0/0/0] ospf network-type p2mp
[Hub-Tunnel0/0/0] nhrp redirect
[Hub-Tunnel0/0/0] ipsec profile profile1
[Hub-Tunnel0/0/0] quit

在Spoke1上配置Tunnel介面，OSPF路由相關屬性以及Hub的靜態NHRP peer表項，應用安全框架，

[Spoke1] interface tunnel 0/0/0
[Spoke1-Tunnel0/0/0] tunnel-protocol gre p2mp
[Spoke1-Tunnel0/0/0] source GigabitEthernet 1/0/0
[Spoke1-Tunnel0/0/0] nhrp entry 172.16.1.1 1.1.1.10 register
[Spoke1-Tunnel0/0/0] ospf network-type p2mp
[Spoke1-Tunnel0/0/0] nhrp shortcut
[Spoke1-Tunnel0/0/0] ipsec profile profile1
[Spoke1-Tunnel0/0/0] quit

在Spoke2上配置Tunnel介面，OSPF路由相關屬性以及Hub的靜態NHRP peer表項，應用安全框架，

測驗：
檢查IPSec SA資訊

<SPOKE1>dis ipsec sa

===============================
Interface: Tunnel0/0/0
 Path MTU: 1500
===============================

  -----------------------------
  IPSec profile name: "profile1"
  Mode              : PROF-ISAKMP
  -----------------------------
    Connection ID     : 18
    Encapsulation mode: Tunnel
    Tunnel local      : 13.1.1.1
    Tunnel remote     : 12.1.1.1
    Qos pre-classify  : Disable

    [Outbound ESP SAs] 
      SPI: 486152828 (0x1cfa1a7c)
      Proposal: ESP-ENCRYPT-AES-128 ESP-AUTH-SHA1
      SA remaining key duration (bytes/sec): 1887432656/2736
      Max sent sequence-number: 43
      UDP encapsulation used for NAT traversal: N

    [Outbound AH SAs] 
      SPI: 4233317404 (0xfc534c1c)
      Proposal: AH-SHA1-96
      SA remaining key duration (bytes/sec): 1887436800/2736
      Max sent sequence-number: 43
      UDP encapsulation used for NAT traversal: N

    [Inbound AH SAs] 
      SPI: 2280211258 (0x87e9433a)
      Proposal: AH-SHA1-96
      SA remaining key duration (bytes/sec): 1887436800/2736
      Max received sequence-number: 54
      Anti-replay window size: 32
      UDP encapsulation used for NAT traversal: N

    [Inbound ESP SAs] 
      SPI: 3683871072 (0xdb936960)
      Proposal: ESP-ENCRYPT-AES-128 ESP-AUTH-SHA1
      SA remaining key duration (bytes/sec): 1887431484/2736
      Max received sequence-number: 54
      Anti-replay window size: 32
      UDP encapsulation used for NAT traversal: N

  -----------------------------
  IPSec profile name: "profile1"
  Mode              : PROF-Template
  -----------------------------
    Connection ID     : 20
    Encapsulation mode: Tunnel
    Tunnel local      : 13.1.1.1
    Tunnel remote     : 14.1.1.1
    Qos pre-classify  : Disable

    [Outbound ESP SAs] 
      SPI: 562038613 (0x21800755)
      Proposal: ESP-ENCRYPT-AES-128 ESP-AUTH-SHA1
      SA remaining key duration (bytes/sec): 1887436260/3031
      Max sent sequence-number: 5
      UDP encapsulation used for NAT traversal: N

    [Outbound AH SAs] 
      SPI: 1039987349 (0x3dfcf295)
      Proposal: AH-SHA1-96
      SA remaining key duration (bytes/sec): 1887436800/3031
      Max sent sequence-number: 5
      UDP encapsulation used for NAT traversal: N

    [Inbound AH SAs] 
      SPI: 3575017841 (0xd5167171)
      Proposal: AH-SHA1-96
      SA remaining key duration (bytes/sec): 1887436800/3031
      Max received sequence-number: 10
      Anti-replay window size: 32
      UDP encapsulation used for NAT traversal: N

    [Inbound ESP SAs] 
      SPI: 299733519 (0x11dd920f)
      Proposal: ESP-ENCRYPT-AES-128 ESP-AUTH-SHA1
      SA remaining key duration (bytes/sec): 1887435684/3031
      Max received sequence-number: 10
      Anti-replay window size: 32
      UDP encapsulation used for NAT traversal: N

注：模擬器中切忽使用SM3，不支持，親測！！！

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/266701.html

標籤：其他

上一篇：Java中通過流下載檔案

下一篇：Vue.js-總結

標籤雲
其他(157675) Python(38076) JavaScript(25376) Java(17977) C(15215) 區塊鏈(8255) C＃(7972) AI(7469) 爪哇(7425) MySQL(7132) html(6777) 基礎類(6313) sql(6102) 熊猫(6058) PHP(5869) 数组(5741) R(5409) Linux(5327) 反应(5209) 腳本語言(PerlPython)(5129) 非技術區(4971) Android(4554) 数据框(4311) css(4259) 节点.js(4032) C語言(3288) json(3245) 列表(3129) 扑(3119) C++語言(3117) 安卓(2998) 打字稿(2995) VBA(2789) Java相關(2746) 疑難問題(2699) 细绳(2522) 單片機工控(2479) iOS(2429) ASP.NET(2402) MongoDB(2323) 麻木的(2285) 正则表达式(2254) 字典(2211) 循环(2198) 迅速(2185) 擅长(2169) 镖(2155) 功能(1967) .NET技术(1958) Web開發(1951) python-3.x(1918) HtmlCss(1915) 弹簧靴(1913) C++(1909) xml(1889) PostgreSQL(1872) .NETCore(1853) 谷歌表格(1846) Unity3D(1843) for循环(1842)

熱門瀏覽
  • 面試突擊第一季，第二季，第三季

    第一季必考 https://www.bilibili.com/video/BV1FE411y79Y?from=search&seid=15921726601957489746 第二季分布式 https://www.bilibili.com/video/BV13f4y127ee/?spm_id_fro ......

    uj5u.com 2020-09-10 05:35:24 more
  • 第三單元作業總結

    1.前言 這應該是本學期最后一次寫作業總結了吧。總體來說，對作業的節奏也差不多掌握了，作業做起來的效率也更高了。雖然和之前的作業一樣，作業中都要用到新的知識，但是相比之前，更加懂得了如何利用工具以及資料。雖然之間卡過殼，但總體而言，這幾次作業還算完成的比較好。 2.作業程序總結 相比前兩個單元，此單 ......

    uj5u.com 2020-09-10 05:35:41 more
  • 北航OO（2020）第四單元博客作業暨課程總結博客

    北航OO（2020）第四單元博客作業暨課程總結博客 本單元作業的架構設計 在本單元中，由于UML圖具有比較清晰的樹形結構，因此我對其中需要進行查詢操作的元素進行了包裝，在樹的父節點中存盤所有孩子的參考。考慮到性能問題，我采用了快取機制，一次查詢后盡可能快取已經遍歷過的資訊，以減少遍歷次數。 本單元我 ......

    uj5u.com 2020-09-10 05:35:48 more
  • BUAA_OO_第四單元

    一、UML決議器設計 ? 先看下題目：第四單元實作一個基于JDK 8帶有效性檢查的UML(Unified Modeling Language)類圖，順序圖，狀態圖分析器 MyUmlInteraction，實際上我們要建立一個有向圖模型，UML中的物件（元素）可能與同級元素連接，也可與低級元素相連形成 ......

    uj5u.com 2020-09-10 05:35:54 more
  • 6.1邏輯運算子

    邏輯運算子 1. && 短路與 運算式1 && 運算式2 01.運算式1為true并且運算式2也為true 整體回傳為true 02.運算式1為false，將不會執行運算式2 整體回傳為false 03.只要有一個運算式為false 整體回傳為false 2. || 短路或 運算式1 || 運算式2 ......

    uj5u.com 2020-09-10 05:35:56 more
  • BUAAOO 第四單元 & 課程總結

    1. 第四單元：StarUml檔案決議 本單元采用了圖模型決議UML。 UML檔案可以抽象為圖、子圖、邊的邏輯結構。 在實作中，圖的節點包括類、介面、屬性，子圖包括狀態圖、順序圖等。 采用了三次遍歷UML元素的方法建圖，第一遍遍歷建點，第二、三次遍歷設定屬性、連邊，實作圖物件的初始化。這里借鑒了一些 ......

    uj5u.com 2020-09-10 05:36:06 more
  • 談談我對C# 多型的理解

    面向物件三要素：封裝、繼承、多型。 封裝和繼承，這兩個比較好理解，但要理解多型的話，可就稍微有點難度了。今天，我們就來講講多型的理解。 我們應該經常會看到面試題目：請談談對多型的理解。 其實呢，多型非常簡單，就一句話：呼叫同一種方法產生了不同的結果。 具體實作方式有三種。 一、多載 多載很簡單。 p ......

    uj5u.com 2020-09-10 05:36:09 more
  • Python 資料驅動工具：DDT

    背景 python 的unittest 沒有自帶資料驅動功能。 所以如果使用unittest，同時又想使用資料驅動，那么就可以使用DDT來完成。 DDT是 “Data-Driven Tests”的縮寫。 資料：http://ddt.readthedocs.io/en/latest/ 使用方法 dd. ......

    uj5u.com 2020-09-10 05:36:13 more
  • Python里面的xlrd模塊詳解

    那我就一下面積個問題對xlrd模塊進行學習一下： 1.什么是xlrd模塊？ 2.為什么使用xlrd模塊？ 3.怎樣使用xlrd模塊？ 1.什么是xlrd模塊？ ?python操作excel主要用到xlrd和xlwt這兩個庫，即xlrd是讀excel，xlwt是寫excel的庫。 今天就先來說一下xl ......

    uj5u.com 2020-09-10 05:36:28 more
  • 當我們創建HashMap時，底層到底做了什么？

    jdk1.7中的底層實作程序（底層基于陣列+鏈表） 在我們new HashMap()時，底層創建了默認長度為16的一維陣列Entry[ ] table。當我們呼叫map.put(key1,value1)方法向HashMap里添加資料的時候： 首先，呼叫key1所在類的hashCode()計算key1 ......

    uj5u.com 2020-09-10 05:36:38 more
最新发布
  • 【中介者設計模式詳解】C/Java/JS/Go/Python/TS不同語言實作

    * 中介者模式是一種行為型設計模式，它可以用來減少類之間的直接依賴關系，
    * 將物件之間的通信封裝到一個中介者物件中，從而使得各個物件之間的關系更加松散。
    * 在中介者模式中，物件之間不再直接相互互動，而是通過中介者來中轉訊息。 ......

    uj5u.com 2023-04-20 08:20:47 more
  • 露天煤礦現場調研和交流案例分享

    他們集團的資訊化公司及研究院在一個礦區正在做智能礦山的統一平臺的 試點，專案投資大概1億，包括了礦山的各方面的內容，顯示得我們這次交流有點多余。他們2年前開始做智能礦山的規劃，有很多煤礦行業專家的加持，他們的描述是非常完美，但是去年底應該上線的平臺，現在還沒有看到影子。他們確實有很多場景需求，但是被... ......

    uj5u.com 2023-04-20 08:20:25 more
  • 《社區人員管理》實戰案例設計&個人案例分享

    設計是一個讓人夢想成真程序，開始編碼、測驗、除錯之前進行需求分析和架構設計，才能保證關鍵方面都做正確 ......

    uj5u.com 2023-04-20 08:20:17 more
  • 軟體架構生態化-多角色交付的探索實踐

    作為一個技術架構師，不僅僅要緊跟行業技術趨勢，還要結合研發團隊現狀及痛點，探索新的交付方案。在日常中，你是否遇到如下問題 “ 業務需求排期長研發是瓶頸；非研發角色感受不到研發技改提效的變化；引入ISV 團隊又擔心質量和安全，培訓周期長“等等，基于此我們探索了一種新的技術體系及交付方案來解決如上問題。 ......

    uj5u.com 2023-04-20 08:20:10 more
  • 【中介者設計模式詳解】C/Java/JS/Go/Python/TS不同語言實作

    * 中介者模式是一種行為型設計模式，它可以用來減少類之間的直接依賴關系，
    * 將物件之間的通信封裝到一個中介者物件中，從而使得各個物件之間的關系更加松散。
    * 在中介者模式中，物件之間不再直接相互互動，而是通過中介者來中轉訊息。 ......

    uj5u.com 2023-04-20 08:19:44 more
  • 露天煤礦現場調研和交流案例分享

    他們集團的資訊化公司及研究院在一個礦區正在做智能礦山的統一平臺的 試點，專案投資大概1億，包括了礦山的各方面的內容，顯示得我們這次交流有點多余。他們2年前開始做智能礦山的規劃，有很多煤礦行業專家的加持，他們的描述是非常完美，但是去年底應該上線的平臺，現在還沒有看到影子。他們確實有很多場景需求，但是被... ......

    uj5u.com 2023-04-20 08:19:07 more
  • 《社區人員管理》實戰案例設計&個人案例分享

    設計是一個讓人夢想成真程序，開始編碼、測驗、除錯之前進行需求分析和架構設計，才能保證關鍵方面都做正確 ......

    uj5u.com 2023-04-20 08:18:57 more
  • 軟體架構生態化-多角色交付的探索實踐

    作為一個技術架構師，不僅僅要緊跟行業技術趨勢，還要結合研發團隊現狀及痛點，探索新的交付方案。在日常中，你是否遇到如下問題 “ 業務需求排期長研發是瓶頸；非研發角色感受不到研發技改提效的變化；引入ISV 團隊又擔心質量和安全，培訓周期長“等等，基于此我們探索了一種新的技術體系及交付方案來解決如上問題。 ......

    uj5u.com 2023-04-20 08:18:49 more
  • 05單件模式

    #經典的單件模式 public class Singleton { private static Singleton uniqueInstance; //一個靜態變數持有Singleton類的唯一實體。 // 其他有用的實體變數寫在這里 //構造器宣告為私有，只有Singleton可以實體化這個類! ......

    uj5u.com 2023-04-19 08:42:51 more
  • 【架構與設計】常見微服務分層架構的區別和落地實踐

    軟體工程的方方面面都遵循一個最基本的道理：沒有銀彈，架構分層模型更是如此，每一種都有各自優缺點，所以請根據不同的業務場景，并遵循簡單、可演進這兩個重要的架構原則選擇合適的架構分層模型即可。 ......

    uj5u.com 2023-04-19 08:42:41 more

Copyright © 2010-2020 有解無憂