Fortigate IPSEC Aggregate + OSPF + SDWAN 實作
參考資料
https://docs.fortinet.com/document/fortigate/6.2.16/cookbook/25967/equal-cost-multi-path
前言
延續前一篇技術分享 Fortigate IPSEC + OSPF + SDWAN 實作，在該篇中OSPF不但能自動交換路由，同時也能 Fail Over 與 Load Balance 的特性，在內部交換與上網時的彈性線路切換，這在Fortigate上稱為ECMP的機制 (Equal-Cost Multi-Path)，但在Fortigate中還有另一個方式可以做到 IPSEC Fail Over 與 Load Balance 的功能，就是所謂的 IPSEC Aggregate，此篇帶大家來看看怎麼搞，並分析其優劣。
環境說明
設計概念： 三個Site透過 IPSEC Aggregate +OSPF+SDWAN 來達成多線路OSPF動態路由，任一條線路故障時可透過其他線路接續連線，並透過SDWAN來監測線路品質狀況，同時由於資訊安全控管的原則希望能統一由同一個Gateway進出。
Firmware Ver. ： Fortigate-VM 7.0.15
| WAN IP |
LAN Subnets |
WAN IPSEC IP |
|
| SiteA |
WAN1 10.1.1.1 WAN2 10.1.2.1 Port4 (to Internet) |
192.168.11.254/24 192.168.12.254/24 192.168.13.254/24 |
AtoB 172.17.1.1 AtoC 172.17.1.6 |
| SiteB |
WAN1 10.1.1.2 WAN2 10.1.2.2 |
192.168.21.254/24 192.168.22.254/24 192.168.23.254/24 |
BtoA 172.17.1.2 BtoC 172.17.1.3 |
| SiteC |
WAN1 10.1.1.3 WAN2 10.1.2.3 |
192.168.31.254/24 192.168.32.254/24 192.168.33.254/24 |
CtoB 172.17.1.4 CtoA 172.17.1.5 |
設定過程
我們直接接續前一篇的設定繼續做，有問題的人請參照前一篇技術分享 Fortigate IPSEC + OSPF + SDWAN 實作 。
※以下設定皆以一台SiteC為範例，請對照該台設定相關對應設定至SiteB & SiteA。
移除SD-WAN IPSEC設定
Delete SD-WAN Performance SLA
Delete SD-WAN Members
移除OSPF IPSEC設定
Delete IPSEC Interface，完成後 要Apply !! (鍵人我不知道忘了多少次 ......)
建立IPSEC Aggregate
在Console輸入下列指令
config vpn ipsec phase2-interface
edit C1toA1
set auto-negotiate enable
next
edit C1toB1
set auto-negotiate enable
next
edit C2toA2
set auto-negotiate enable
next
edit C2toB2
set auto-negotiate enable
end
config vpn ipsec phase1-interface
edit C1toA1
set aggregate-member enable
next
edit C1toB1
set aggregate-member enable
next
edit C2toA2
set aggregate-member enable
next
edit C2toB2
set aggregate-member enable
end
VPN => IPSEC Turnnels => Create New => IPSEC Aggregate
建立 Aggregate，名稱取為CtoA，將C1toA1、C2toA2選起來
建立第二個 Aggregate CtoB 如法炮製
完成後如下圖
設定 IPSEC Aggregate Interface IP
完成Aggregate後發現，IPSEC Interface的IP都被移除了，把它們設回去
完成如下圖
設定OSPF Interface
完成如下圖，記得要Apply !! (鍵人我不知道忘了多少次 ...... Again ...... )
設定SD-WAN
新增 SD-WAN Member
把CtoA、CtoB 加入OSPF_SDWAN Zone
完成如下圖
重建 SD-WAN Performance SLA
Performance SLA 完成如下圖
設定至此全部完成
※ 以防有人忘記了，在此我們沒有建立Firewall Policy的原因是上一篇我們已經制定好了
路由的部分全部交由OSPF處理，SiteB、SiteC 請不要設定任何Static Route進入SD-WAN。
狀態確認
OSPF 狀態
get router info ospf neighbor
get router info routing-table ospf
get router info ospf route
get router info routing-table all
IPSEC 狀態
※比較過後，是不是看到流量分配的比之前更平均了 ?
連線測試
從SiteC PC 連續Ping 8.8.8.8，透過Sniffer可知道是走CtoA
將 CtoA 斷線，流量改走 CtoB
將 CtoA 恢復，流量又回到 CtoA
有此可證明Fail Over正常運作
Pros and Cons
所以，一路看下來，整體設定變得更簡潔、流量分配更平均，這樣設定應該是更好的選擇 ...... 吧 ?
讓我們來看看 IPSEC Aggregate的問題
問題1
回到上面的Fail Over測試，其實鍵人我不是只單純做了CtoA斷線測試，我其實是優先做C1toA1的斷線測試
看到了嗎 ? IPSEC Aggregate下，因為IPSEC斷線偵測比較慢，所以Aggregate還是很盡責地將封包分給兩條IPSEC所以會導致掉封包，等到IPSEC斷乾淨了之後才恢復順暢(如下圖)
你要說這個問題會很嚴重嗎 ? 也不見得，但是相較於沒有Aggregate以OSPF的切換機制來說是慢得多了
問題2
還記得我們最初為什麼要嘗試把OSPF去結合SD-WAN嗎 ? 就是因為要去監測OSPF線路品質是很困難的事情，所以雖然這樣設定SD-WAN完全沒有生效，但能藉由SD-WAN Performance SLA去監測OSPF線路品質還是一件很棒的事。
但一旦IPSEC Aggregate之後，SD-WAN Performace SLA監測機制就失去意義了，下圖是以SiteA的角度來看C1toA1斷線
看到了嗎 ? 上圖只知道AtoC有掉包，但卻無法直觀的得知是由於C1toA1斷線所造成的
再來請看下圖，這是實務上容易發生的，當整個SiteC WAN1斷了的時候，C1toA1 & C1toB1 會同時斷線。
但在IPSEC還沒切乾淨網路還沒恢復通順的期間，SD-WAN Performance SLA有可能會變成這樣
對，就像上圖，顯示上SiteA、SiteB都斷了，但其實沒斷還能夠連線，偵測要等恢復通順才會回來，那這樣就大大的降低了利用SD-WAN Performance SLA監測的意義與正確性。
優勢
說完了問題，IPSEC Aggregate還是有優勢的地方
記得一開始前言的地方，我有提到沒有Aggregate的時候，Fortigate是透過OSPF ECMP的方式來達成Fail Over & Load Balance的，預設的ECMP Policy是基於 Source-IP-Base 去作分流，也就是如下圖
也因為ECMP是Source-IP-Base的關係，單一Source IP的流量無法超過單一線路頻寬，假設你WAN1、WAN2皆為100M/100M，在ECMP 單一Source IP 最大流量就是100M。
但再看一次上面那張圖，反而佐證了透過IPSEC Aggregate Fortigate會去拆分封包分別丟入兩個IPSEC Turnnel
所以我們可以確定，在IPSEC Aggregate下，單一Source IP的流量可以超過單一條線路頻寬，也就是WAN1、WAN2皆為100M/100M，在IPSEC Aggregate下單一Source IP 最大流量可達 200M。
優劣比較
綜合以上優劣，僅以下表呈現鍵人我的推薦程度，✅較為推薦，❌較不推薦
| IPSEC | IPSEC Aggregate | |
| 動態路由 | ✅ | ✅ |
| Fail Over | ✅ | ✅ |
| Load Balance | ✅ | ✅ |
| 線路監控 | ✅ | ❌ |
| 即時切換 | ✅ | ❌ |
| 整合頻寬 | ❌ | ✅ |
如果是鍵人我，我會選擇 IPSEC 不作 Aggregate，這樣才能充分發揮OSPF的優勢
但在某些不是這麼Critical的Site，線路頻寬小且無法升速的區域 (比方說偏鄉地區)，IPSEC Aggregate依然是個不錯的選擇