• 多分支機構公網接入辦公網總部,或者接入機房.
• 網絡全通,任意 IP 有能力訪問任意網段
• 設備冗余
• 鏈路冗余
• 故障自動并快速切換,最好用戶無感知
• 能夠適應多種不同網絡環境
• 統一配置模板
• 簡化配置部署
• 具有較高安全加密功能
• 能夠區分流量走不同的鏈路,同時某條鏈路故障了又可以自動切換
• 日后升級設備可以無縫替換,網絡不中斷
• 能夠做地址轉換,打通多個相同網段的網絡
• 能夠平滑的橫向擴展接入能力
• 部署起來性價比高
• 優化分支機構的路由,避免過多路由
• 便于監控,能夠抓取不同 VPN 流量

理想很完美,現實很骨感,總結起來就是用最少的錢實現最牛逼的效果,老板們的臉上樂開了花.

讓我們先看看分支機構通過公網接入一般會有哪些網絡場景?

多種不同網絡環境如下：

選型思路

公網對接首要考慮的是安全,比較安全可靠的三層 VPN 類型有 IPsec、SSL VPN、L2TP over IPsec,鑒于我們的適用場景是 Site to Site,所以決定采用 IPsec VPN.這里我們對 IPsec 稍微多介紹一點,但是也不過多展開,網上資料一大堆,歡迎大家自行了解.我也在很多公司場景里見到使用 IPsec VPN,但是見到最多的用法為 IPsec VPN + Static Route,最多再加個 track 做切換,這樣有一些缺陷,而且不便于大規模網絡擴展,我們其實可以把 IPsec 用得更好.

IPSEC 協議：

IPsec 存在兩種安全協議,一種是 AH(Authentication Header),一種是 ESP(Encapsulating Security Payload),其中 AH 只能做數據源驗證、數據完整性校驗、防報文重放功能,不具備數據加密功能,所以我們必須選用 ESP 協議. ESP 可以提供加密、數據源驗證、數據完整性校驗、防報文重放、穿越 NAT 功能,正好能滿足我們不同網絡對接模型.

常用加密、驗證方法：

無論是加密還是驗證方法,兩端的安全提議保持其中一組一致即可.

• 數據來源驗證：接收方驗證發送方身份是否合法.
• 數據加密：發送方對數據進行加密,以密文的形式在Internet上傳送,接收方對接收的加密數據進行解密后處理或直接轉發.
• 數據完整性：接收方對接收的數據進行驗證,以判定報文是否被篡改.
• 抗重放：接收方會拒絕舊的或重復的數據包,防止惡意用戶通過重復發送捕獲到的數據包所進行的攻擊.

選定了 IPsec VPN,其實已經解決了很多需求,比如安全加密、穿越 NAT,通過野蠻模式可以實現總部配置一個 IPsec Policy Template,不用指向分支對端的 remote-ip 或 remote-name,起到簡化配置的作用.

讓我們繼續來看看其他需求如何滿足.

我們需要全網互通、設備冗余、鏈路冗余、故障自動切換這些很符合常理的需求,在 IDC 或者辦公網內,我們通過 VRRP、HSRP、堆疊、虛擬化等技術實現網關冗余,通過鏈路捆綁或 STP 實現二層鏈路冗余,通過鏈路捆綁、動態路由實現三層鏈路冗余,通過 BFD 和 Track 實現三層鏈路快速切換,通過 ACL 和路由策略控制不同網絡區域互訪.考慮到公網對接場景跨三層,跨區域二層互訪等需求本次不做過多考慮,最簡單也是最容易擴展維護的方式就是通過動態路由協議來自動維護,切換鏈路,切換故障設備.

考慮到我們后期往往還會提出一些數據流量選路,不同網段之間互訪,分支機構之間互訪的更多的需求,我們推薦不同分支機構、不同機房、不同辦公網之間互聯采用 BGP 協議,可以滿足后期各種復雜的選路需求,以下網絡對接方案建立在目前已有網絡已經同時運行了 IGP 與 BGP,在公網統一對接設計這里,繼續用 BGP 是最好的選擇.當然,如果您現有網絡全網都是 OSPF,繼續用 OSPF 完全可以,可以在規劃一些非骨干區域用于 ABR 上匯總路由,優化網絡,只是路由策略這塊沒有 BGP 那么靈活.

各大廠商均有一些 IPsec 冗余鏈路的特性支持,一般為主備的方式,需要增加一些額外的配置,并且在擴展性上沒有那么好,因此我們決定采用多條 Tunnel 上運行動態路由協議的方式來做雙鏈路、三鏈路、多鏈路的冗余.這里的 Tunnel 指的是 GRE Tunnel,也就是我們平常所說的 GRE over IPsec.

大家可能會問,你這里說的是公網統一對接方案,要求是不論公網還是內網均能夠統一對接,而 GRE 協議由于報文格式里沒有類似 seq 字段,是不可以穿越 NAT 的,而且 GRE Tunnel 兩端均必須指對方與自己的源和目的 IP,所以做 GRE 的時候經常兩端均具備公網 IP.

是的,通常我們在公網 VPN 對接中,會采用 GRE over IPsec 的方式,既跑動態路由協議,又對公網數據加密,GRE Tunnel 的源與目的 IP 一般為兩端公網 IP,IPsec 針對兩端公網 IP 匹配感興趣數據流進而加密 GRE Tunnel.之所以用 GRE 的原因是因為 GRE 支持組播,可以更好的支持動態路由協議,并且不用為新增路由網段去修改 IPsec ACL,只需要通過路由協議去宣告新的網段即可,十分方便.而用純 IPsec VPN 對接時,我們往往會在總部的設備上看到一堆的靜態路由,雖然也可以通過靜態路由加 Track、nqa、ip sla 等技術實現一些鏈路自動切換效果,但這種切換是無法對更遠的鏈路故障進行感知的,不如動態路由協議,可以感知到全網任何一條鏈路故障.

前面我們強調過 GRE 不可以穿越 NAT,這里其實我們變換一下思路,把 GRE 的源與目的 IP 修改為兩端的 Loopback 口 IP,即兩端設備的內網 IP,通過總部與分支機構的內網 IP 建立 GRE 隧道,利用 IPsec 的穿越 NAT 特性統一接入不同網絡場景,再通過動態路由協議 OSPF、BGP 統一控制路由層面,即可滿足我們之前提到的所有需求,并且可以統一公網對接模式.

在橫向擴展方面,我的思路是通過大量低端的設備完成,將 VPN 鏈路分散開來,某一臺設備故障只會影響一小部分 VPN 鏈路,通過路由協議來維持全網的統一性.買十臺低端路由器用以下方案組網,永遠比你買一臺高端設備睡得踏實.

實驗配置

手邊現有幾臺華為設備,以此配置舉例,其他廠商的配置思路一模一樣.

規劃需求

我們將配置分為幾個階段：基礎配置、IPsec 配置、GRE 配置、BGP 配置

演示拓撲如下：

基礎接口配置部分

目標：實現分支能夠訪問到總部的公網固定 IP,分支可以是公網固定 IP,也可以是內網 IP 通過其他 NAT 設備訪問總部,創建 Loopback 10 接口用于后面建立 IPsec VPN 使用.

總部：

sysname Hub
# 配置 WAN 口 IP
interface GigabitEthernet0/0/0
 ip address 200.1.1.100 255.255.255.0

# 配置用于建立 GRE Tunnel 的 Loopback 口 IP
interface LoopBack10
 ip address 172.20.1.1 255.255.255.255

分支：

sysname Spoke
# 配置 WAN 口 IP,如處于內網
interface GigabitEthernet0/0/0
ip address 192.168.1.100 255.255.255.0

# 配置用于建立 GRE Tunnel 的 Loopback 口 IP
interface LoopBack10
 ip address 172.20.1.2 255.255.255.255

分支防火墻：

確保 192.168.1.100 可以經過 SNAT 訪問 200.1.1.100

公網：

確保總部出口 200.1.1.100 可以和分支機構公網出口 IP 通

基礎路由配置部分

目標：確保兩端經過 IPsec 加密流量從物理接口出去

總部：

ip route-static 172.20.1.2 255.255.255.255 GigabitEthernet0/0/0 200.1.1.1 description REMOTE-LOOPBACK10

分支：

ip route-static 172.20.1.1 255.255.255.255 GigabitEthernet0/0/0 192.168.1.1 description REMOTE-LOOPBACK10

IPsec 配置部分：

目標：總部實現一個 IPsec 配置模板,對接不同網絡場景的分支機構,隨著分支機構的增加不需要額外的 IPsec 配置.

總部采用 Template 模板方式,ESP 協議,開啟野蠻模式、NAT 穿越. 分支采用 IPsec 策略配置一條或多條 IPsec 隧道,ESP 協議,開啟野蠻模式、NAT 穿越,指向總部的公網 IP,并且匹配 ACL,ACL 匹配的源 IP 與目的 IP 是雙方的 Loopback 10 接口 IP 地址.注意：實驗中只有分支機構需要指定 remote-address.

兩端都采用 IKE 協商方式對接 IPsec.這里不采用 ike v2 的模式,因為 v2 不支持野蠻模式,無法傳遞給總部感興趣 ACL(security ACL).

這里放上一張主模式與野蠻模式的協商過程對照圖：

貼一段華為產品手冊里總結的話：

• 如果發起方的 IP 地址不固定或者無法預知,而雙方都希望采用預共享密鑰驗證方法來創建 IKE SA,則只能采用野蠻模式.
• 如果發起方已知響應方的策略,或者對響應者的策略有全面的了解,采用野蠻模式能夠更快地創建 IKE SA.

總部：

# 創建 IPsec 安全提議
ipsec proposal PROPOSAL
 esp authentication-algorithm sha2-256 
 esp encryption-algorithm aes-128

# 創建 IKE 安全提議
ike proposal 5
 encryption-algorithm aes-cbc-128
 dh group2
 authentication-algorithm sha2-256
 prf hmac-sha2-256

# 配置 ipsec 對等體
ike peer REMOTE v1
 exchange-mode aggressive #野蠻模式
 pre-shared-key cipher test123 #兩端 PSK 密碼需要保持一致
 ike-proposal 5 #關聯 ike 安全提議
 nat traversal #兩端即使都為公網 IP,也可以開啟 nat 穿越功能,不影響 IPsec VPN 建立.
# 注意：這里不指定 remote-name 和 remote-address,總部需要同時與多個分支建立多條 IPsec VPN.

# 創建 ipsec 策略模板,關聯 ike 對等體和 IPsec 安全提議
ipsec policy-template TEMP 10
 ike-peer REMOTE
 proposal PROPOSAL
#注意：由于每條 VPN 加密數據流源目的均不同,這里不需要關聯感興趣數據流(security ACL),由分支機構負責傳遞 ACL 過來.

# 關聯 IPsec 模板與 IPsec Policy,只能關聯一個模板
ipsec policy POLICY 10 isakmp template TEMP

# 應用 IPsec 策略到接口上
interface GigabitEthernet0/0/0
 ipsec policy POLICY

分支：

# 創建 IPsec 安全提議
ipsec proposal PROPOSAL
 esp authentication-algorithm sha2-256 
 esp encryption-algorithm aes-128

# 創建 IKE 安全提議
ike proposal 5
 encryption-algorithm aes-cbc-128
 dh group2
 authentication-algorithm sha2-256
 prf hmac-sha2-256

# 配置 ipsec 對等體
ike peer REMOTE v1
 exchange-mode aggressive
 pre-shared-key cipher test123 #兩端 PSK 密碼需要保持一致
 ike-proposal 5 #關聯 ike 安全提議
 nat traversal
 remote-address 200.1.1.100 #只有分支這里需要指定總部的公網 IP
# 注意：作為分支需要指定總部的 remote-address,不需要修改驗證類型為 name.

acl number 3000 ?
# 匹配感興趣數據流,源為分支設備的 Loopback 10 IP,目的為總部設備的 Loopback 10 IP
 rule 5 permit ip source 172.20.1.2 0 destination 172.20.1.1 0 

# 創建 ipsec 策略,關聯 ike 對等體和 IPsec 安全提議,關聯感興趣數據流(security ACL)
ipsec policy POLICY 10 isakmp
 security acl 3000
 ike-peer REMOTE
 proposal PROPOSAL
# 注意：如果分支同時與多個總部建立 IPsec VPN,在此創建多個 Policy 節點,例如："ipsec policy POLICY 20 isakmp"

# 應用 IPsec 策略到接口上
interface GigabitEthernet0/0/0
 ipsec policy POLICY

GRE 配置部分：

目標：通過兩端內網 Loopback 口建立起 GRE Tunnel,用于以后運行動態路由協議,開啟 keepalive 功能.

總部：

interface Tunnel0/0/0
 ip address 172.30.1.1 255.255.255.252 #GRE IP,用于建立 BGP 協議
 tunnel-protocol gre
 keepalive period 1 retry-times 5 #每隔一秒心跳包檢測,五秒超時
 gre key cipher test321 #只校驗,不加密
 source LoopBack10 #源地址為總部 Loopback 10 IP
 destination 172.20.1.2 #目的地址為分支 Loopback 10 IP

分支：

interface Tunnel0/0/0
 ip address 172.30.1.2 255.255.255.252 #GRE IP,用于建立 BGP 協議
 tunnel-protocol gre
 keepalive period 1 retry-times 5 #每隔一秒心跳包檢測,五秒超時
 gre key cipher test321
 source LoopBack10 #源地址為總部 Loopback 10 IP
 destination 172.20.1.1 #目的地址為總部 Loopback 10 IP

BGP 路由配置部分：

目標：BGP EBGP 鄰居建立

總部：

bgp 100
 peer 172.30.1.2 as-number 200
 peer 172.30.1.2 path-mtu auto-discovery
 #
 ipv4-family unicast
 ?undo synchronization
 ?peer 172.30.1.2 enable

分支：

bgp 200
 peer 172.30.1.1 as-number 100
 peer 172.30.1.1 path-mtu auto-discovery
 #
 ipv4-family unicast
 ?undo synchronization
 ?peer 172.30.1.1 enable

檢查

檢查 ike sa、ipsec sa、GRE Tunnel 狀態、BGP 鄰居狀態、BGP 路由

為什么不使用 BFD

既然用到了路由協議,BFD 是一個很好的搭配,可以用來快速鏈路檢測,通常 BFD 可以實現 10ms 一次的心跳,三次失敗的話僅需 30ms 就可以切換鏈路,純內網環境非常適合.為什么不用 BFD 呢?

首先我們這里討論的是公網環境,對延遲沒有那么敏感,一些對延遲非常敏感的業務也不太可能通過公網傳輸.

其次關鍵的一點是 BFD over GRE 無法 over IPsec,大家可以抓包看看,BFD 可以進入 GRE 隧道,當你兩端都做 GRE over IPsec 公網 IP 對 公網 IP 對接時,BFD 鄰居可以起來,但是 BFD 報文外層僅有 GRE 報頭,不會被 IPsec 加密,但是這樣不影響公網對公網使用 BFD 協議,但如果我們的分支處于內網環境里就無法使用 BFD 了,因為 GRE 無法穿越 NAT,這里如果有人發現和我說的不同現象可以與我交流,因為我也沒有把所有廠商的設備都測一遍,目前手里有的設備測試出來是這么個結果.

其次 GRE 自帶的 keepalive 可以實現一秒一次的心跳包檢測,三秒超時接口會 down,對應的 BGP 鄰居會立刻 down,這個切換效果其實也可以接受,用戶的感覺就是卡了一下就切走了.

再不然你還可以做 BGP 鄰居的 Track,關聯一些 nqa 和 ip sla 配置,實現更豐富的故障鏈路檢測 & 切換效果.

如果分支的設備故障怎么辦?

增加一臺,與分支的內網里跑起來動態路由協議.

新建節點

我們假定一個工作場景,所有用于分支對接的網絡設備需要總部網絡工程師配置,那我們的網絡工程師可以提前對設備進行配置,或者讓分支機構的 IT 工程師協助配置,有哪些配置是需要后期完成的呢?

• WAN 口 IP,需要提前知道是何種方式,公網 IP 還是內網 IP,手工配置、DHCP 還是 PPPoE 撥號方式
• 缺省路由配置,若上一條可以提前配置,則此條不需要現場配置.

通常在分支設備 WAN 口可訪問總部公網 IP 時,IPsec、GRE、BGP 一系列的狀態都會自動 UP,遠程管理地址也會自動接入網絡,可以開始遠程操作.

維護

讓我們從后期維護角度看看此套方案的工作量新增公網 VPN 鏈路時需要新增的配置部分：

對于總部設備來說,增加一家分支機構接入：

• 增加一條指向分支機構的 Loopback 10 32 位靜態路由
• 增加一條用來與分支機構建立動態路由協議的 Tunnel 口,運行 GRE 協議
• 動態路由協議里與分支機構建立鄰居關系

對于分支機構來說,增加一家總部用于接入：

• 增加一條指向總部的 Loopback 10 32 位靜態路由
• 增加一條 ACL 用于匹配不同鏈路的 IPsec 感興趣數據流(security ACL)
• ipsec policy 里增加一個節點,關聯上新的 ACL
• 增加一條用來與總部建立動態路由協議的 Tunnel 口,運行 GRE 協議
• 動態路由協議里與總部建立鄰居關系

其他一些強烈建議配置項：

• NTP
• DNS
• AAA
• SYSLOG
• SNMP

批量管理：

建議通過 expect 或 python 腳本維護,通過學習一些基礎編程知識,網絡工程師很容易同時對上百臺設備做變更操作.切記,跑之前先找其中一臺試試.

總部設備橫向擴展：

總部通過部署新路由器進行對接新的分支機構即可,全網通過動態路由協議打通,分支連接新的總部匯聚設備公網 IP,僅模板處需要更改.

割接：

網絡運維中永遠少不了割接,而一家分支如果有兩條或兩條以上隧道進行割接操作非常簡單,假如我們現在需要對總部網絡設備進行更換高配置的硬件型號,或者升級版本,只需切斷路由協議鄰居、或者是關閉 Tunnel 口,觀察流量、報警有無變化,判斷其余鏈路是否正常工作,是否可以繼續進行操作,恢復的話以路由協議鄰居建立、流量監控為準.

監控

監控以 syslog、snmp 協議為主,在網絡自動連通的情況下均不是問題,管理 IP 均為提前規劃,在上線前可以批量添加監控項目,這里就不做過多展開了.

由于我們是采用一條 VPN 對應一個 Tunnel 口的配置,所以在總部匯聚口這里,可以通過監控 Tunnel 口流量區分不同鏈路的流量,不同于純 IPsec 的方式,VPN 數量一多的話所有流量都堆在一個物理接口下面,分不清楚每條鏈路各自消耗了多少帶寬.

題外話

對于分支機構,小的辦公網絡往往只會接一條小帶寬的運營商公網線路,分支節點多了辦公網出口故障的情況還是比較常見的,好在現在的路由設備往往都支持 4G 模塊,你懂的.

性價比

國內一些大廠路由設備價格在一臺五千元上下的型號,IPsec 吞吐量可以達到 700Mbps 以上,根據實際情況合理規劃,總部一臺設備對接 20 – 50 條鏈路個人認為都可行.

分支機構如果流量不大可以選購一些不到 1U 大小的低端型號路由器,價格在千元左右,但是各種特性均支持,十分劃算. 綜上所述,設備選型還是與公司實際需求有關,一定要根據實際情況去做規劃,對于整套方案來說,所有協議均是公共標準,沒有私有協議,理論上各家廠商設備均可對接,低端設備與高端設備的區別往往是性能、接口數量上的區別.

尾聲

有人估計要問了,開場提了一堆需求,好像還有一些未提到,例如：

• 優化分支機構的路由,避免過多路由
• 能夠區分流量走不同的鏈路,同時某條鏈路故障了又可以自動切換
• 能夠做地址轉換,打通多個相同網段的網絡

優化分支路由這塊其實通過路由策略很容易實現,如果 AS 編號規劃合理、連續的話,可以通過 as-path-filter 工具只向分支機構傳遞機房的路由、總部路由,或者通過路由聚合、null 0 靜態路由宣告、BGP 通告缺省路由(此動作需要分支機構不再寫缺省路由,而改為總部的明細公網路由條目)等等多種方式實現,并且有一個前提,就是 IP 地址規劃要做好,如果做到一個 AS 內 1 到 2 條 匯總路由,那么你全網互通的情況下所需要的路由表數量是非常少的.

至于區分不同流量走不同鏈路而同時可以互相冗余備份的需求,也跟 IP 地址規劃有關,我們要考慮路由的來回路徑的問題,所以想實現這個需求網絡層面上一定要求不同流量指的是源與目的 IP 均不相同,否則就要借助一些四層或者七層轉發服務,例如 LVS 或者 HAProxy,通過建立多組轉發服務實現流量區分,此種條件下依然需要一些業務網段進行區分.這里我不推薦用策略路由的方式,從運維的角度不利于管理維護,也會增加設備很多額外的開銷,并且無法感知到深層次的鏈路故障.

地址轉換用到 NAT,例如公司與客戶內網對接時,需要同時做源 NAT 與目的 NAT 實現任意網絡對接,不用考慮地址沖突的問題.

以上這些需求與本次公網統一接入的話題沒那么密切,也不過多展開了.

總結

總結下來其實就是一句話：利用 IPsec 的野蠻模式實現總部模板部署、利用 IPsec 的 NAT 穿越功能實現公網、內網統一對接,用兩端私網 IP 建立 GRE 隧道,最后再利用 GRE 接口 IP 運行動態路由協議.全網都可以實現互通,除了所有設備的 Loopback 10 接口是不可路由的,只存在于靜態路由中.

既然標題我們叫做“面向總部與分支之間的公網統一安全對接方案”,那最后我們有沒有實現統一了呢?如果你通篇閱讀下來你會發現,無論面向何種分支公網對接,都可以用這一套模板,你要做的僅僅是修改修改接口 IP,運行同樣的路由協議,同樣的接口編號,性能不夠了加幾臺設備.有人也會說,有些廠商的私有協議 DMVPN、DSVPN 也可以實現類似效果,但是那些技術要額外的 License,并且是私有協議,無法跨廠商設備對接.我們今天所介紹的所有內容均是路由設備最基礎的功能,可以自由組合起來使用,希望對大家有幫助.

作者介紹

劉啟,網絡工程師,CCIE & HCIE,曾任職于神州信息互聯網事業部、去哪兒網 OPS 負責數據中心網絡運維,目前就職于本木醫療公司負責網絡規劃設計.

原文來自微信公眾號：云技術實踐