はじめに
NTTデータ セキュリティ＆ネットワーク事業部 テクニカル・グレードの田中智志です。
本Blogではクラウド上にデプロイしたFortiGateVMを活用するためのテクニックを紹介しています。
これまでの記事でAmazon Web Services(AWS)上にデプロイしたFortiGateVMを扱ってきましたが、今回はAzure～オンプレミス環境とFortiGateVM on AWS上のSD-WAN/ADVPN2.0ネットワークの統合をAzure Route Serverにより実現する方法を試してみました。
FortiGateVMをSD-WAN/ADVPN2.0のスポークルータとして構成することで、オンプレミスだけでなく各パブリッククラウドリソースを一つのブランチのように扱うことが可能となり、より拡張性の高いネットワークが実現できます。
構成
Azureとオンプレミスをサイト間(S2S)VPNにより接続されている環境に、FortiGateVMをADVPNのSpokeルータとしてデプロイします。これによりBranchのFortiGateとAzureのFortiGateVM間でADVPN Shortcutが確立し、AzureのFortiGateVMが所属するサブネット～Branch間はAWSのHUBルータを介さず直接通信を行うことが可能になります。
ただし、S2S VPNでAzureと接続されているオンプレミスのルータとBranchのFortiGateはお互いのルート情報を知らないと通信ができません。また、FortiGateVMの所属する仮想ネットワーク（VNet）に、異なるVNetがピアリングされている場合も同様です。この課題はAzure Route Server(ARS)を利用することで完全に動的なルーティング設計を実現することで解決できます。
なお、FortiGate on AWSによるSD-WAN/ADVPN2.0ネットワークの構築方法については以下の記事で紹介しているため、今回は省略します。
参考：FortiGateのSD-WAN/ADVPN2.0ネットワークに関する記事一覧
設定１：Azure～オンプレミス間S2S VPN
まずはAzureとオンプレミスルータ間のS2S VPNを確立し、相互にルート情報を交換するように構成します。
S2S VPNを構成するためには以下のコンポーネントが必要です。
- 仮想ネットワークゲートウェイ(VPN Gateway)
- ローカルネットワークゲートウェイ
- 接続(Connection)
リソースグループやVNetの作成手順は省略します。
仮想ネットワークゲートウェイ(VPN Gateway)
VPN GatewayやExpressRouteを構成するには専用のサブネット「ゲートウェイサブネット」が必要です。サブネットを作成する際に「サブネットの目的」で「Virtual Network Gateway」を選択します。
ゲートウェイサブネットを作成する際は以下の点に注意が必要です。
- ゲートウェイサブネットは1つのVNetに1つだけ作成できます。
- ゲートウェイサブネットには仮想マシンをデプロイすることはできません。
- VPN GatewayのBGPで学習したルート情報は自動的にVNet内のルートテーブルに伝達されます。
- ゲートウェイサブネット上にはゲートウェイVMとゲートウェイサービスが暗黙的に存在し、それぞれにIPアドレスがアサインされるため、ゲートウェイサブネットのアドレス空間は注意して設計することが重要です。例えばVPN GatewayとExpressRouteを併用する場合、最小でも/27の範囲が必要になります。
次にVPN Gatewayを作成します。ARSと統合する場合は以下の設定にしておく必要があります。
- AS番号は65515（既定）
- アクティブ/アクティブモード有効
（後述しますが、ここでは意図的に「アクティブ/アクティブモードの有効化」を無効にしています。）
ローカルネットワークゲートウェイ
ローカルネットワークゲートウェイを作成します。VPNピアとなるオンプレミスルータのパラメータを設定します。
接続(Connection)
接続にはIPsec VPNの各パラメータを設定します。VPNトンネル一本につき、接続を一つずつ作成する必要があります。
On-Prem(FortiGate 40F)
オンプレミスのFortiGate 40FでAzureとのIPsecVPNを構成します。
IPsecVPNインターフェース（Phase1,Phase2）
Azureで設定したパラメータに合わせて設定します。※あくまで検証環境用のIPsec/IKEポリシーであり、商用利用時は要件に沿ったものをご使用ください。
config vpn ipsec phase1-interface
edit "azure"
set interface "wan"
set ike-version 2
set peertype any
set net-device disable
set proposal aes128-sha256 aes256-sha256 aes128-sha1 aes256-sha1
set dpd on-idle
set dhgrp 2
set remote-gw *.*.*.*（VPN GatewayのパブリックIPアドレス）
set psksecret *****
set dpd-retryinterval 5
next
end
config vpn ipsec phase2-interface
edit "azure"
set phase1name "azure"
set proposal aes128-sha1 aes256-sha1 aes128-sha256 aes256-sha256 aes128gcm aes256gcm chacha20poly1305
set auto-negotiate enable
next
end
トンネルインターフェース
Phase1、Phase2インターフェースを設定後、自動的にトンネルインターフェースが作成されます。ローカルとリモートのIPアドレスを追加で設定します。
config system interface
edit "azure"
set vdom "root"
set ip 169.254.21.1 255.255.255.255
set type tunnel
set remote-ip 169.254.21.2 255.255.255.255
set interface "wan"
next
end
ファイアウォールポリシー
LAN側とVPN側の間でトラフィックを転送できるように設定します。
config firewall policy
edit 12
set name "LAN to Azure"
set srcintf "lan"
set dstintf "azure"
set action accept
set srcaddr "all"
set dstaddr "all"
set schedule "always"
set service "ALL"
next
edit 13
set name "Azure to LAN"
set srcintf "azure"
set dstintf "lan"
set action accept
set srcaddr "all"
set dstaddr "all"
set schedule "always"
set service "ALL"
next
end
BGP
Azure側のBGPピアに対する設定を行います。
config router bgp
set as 65001
set keepalive-timer 1
set holdtime-timer 3
config neighbor
edit "169.254.21.2"
set advertisement-interval 1
set capability-graceful-restart enable
set soft-reconfiguration enable
set remote-as 65515
set update-source "azure"
next
end
end
動作確認
Azure
Azureの各コンポーネントでS2S VPNの状態を確認していきます。
- 接続
状態が「接続済み」となっており、データ入力とデータ出力にトラフィックが流れていることが確認できています。
- BGP
VPNトンネル上でBGPネイバーが確立しておりBGPメッセージの送受信ができていること、eBGPでオンプレミスからルート情報を学習していることが確認できます。
- 各サブネットのルートテーブル
VPN Gatewayで学習したルート情報が自動的に各サブネットのルートテーブルに反映されています。なお、各サブネットのルートテーブルは、各サブネットにVMがある場合はVMのヘルプ⇒有効なルートをクリックすると確認できます。
On-Prem(FortiGate 40F)
オンプレミスルータでも確認します。BGPネイバーの確立と、Azureの各サブネットのルート情報をBGPで学習できていることが分かります。
# get router info bgp sum
-SNIP-
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
169.254.21.2 4 65515 397 355 3 0 0 00:02:02 4
# get router info bgp network
-SNIP-
Network Next Hop Metric LocPrf Weight RouteTag Path
*> 192.168.1.0 169.254.21.2 0 0 0 65515 i <-/1>
*> 192.168.2.0 0.0.0.0 100 32768 0 i <-/1>
*> 192.168.10.0 169.254.21.2 0 0 0 65515 i <-/1>
*> 192.168.11.0 169.254.21.2 0 0 0 65515 i <-/1>
*> 192.168.22.0 169.254.21.2 0 0 0 65515 i <-/1>
# get router info routing-table all
-SNIP-
Routing table for VRF=0
S* 0.0.0.0/0 [1/0] via 192.168.1.1, wan, [1/0]
C 10.200.1.250/32 is directly connected, Lo
C 169.254.21.1/32 is directly connected, azure
S 169.254.21.2/32 [5/0] via azure tunnel *.*.*.*（VPN GatewayのパブリックIPアドレス）, [1/0]
C 192.168.1.0/24 is directly connected, wan
C 192.168.2.0/24 is directly connected, lan
B 192.168.10.0/24 [20/0] via 169.254.21.2 (recursive via azure tunnel *.*.*.*（VPN GatewayのパブリックIPアドレス）), 00:22:00, [1/0]
B 192.168.11.0/24 [20/0] via 169.254.21.2 (recursive via azure tunnel *.*.*.*（VPN GatewayのパブリックIPアドレス）), 00:22:00, [1/0]
B 192.168.22.0/24 [20/0] via 169.254.21.2 (recursive via azure tunnel *.*.*.*（VPN GatewayのパブリックIPアドレス）), 00:22:00, [1/0]
Tips：既定のBGP用IPアドレスからBGPパケットが送信される
VPN Gatewayをデプロイした際、設定したつもりのないBGP用のIPアドレス（192.168.11.4など）が設定されます。実際に当該IPアドレスからのBGPパケットもオンプレミスルータに送信されます。
これはVPN Gatewayの仕様であり、APIPAアドレスを明示的に設定したとしても対向側のオンプレミスルータに対してVPN Gatewayが保有する既定のBGPアドレスからBGPパケットが送信されます。このパケット送信を明示的に停止する設定は用意されていません。なお、APIPAアドレスが使用されている場合はオンプレミスルータからBGP接続を開始する必要があります。
# diagnose sniffer packet any "host 169.254.21.1"
interfaces=[any]
filters=[host 169.254.21.1]
1.686031 192.168.11.4.60779 -> 169.254.21.1.179: syn 2240821021
-SNIP-
60.986717 192.168.11.4.60861 -> 169.254.21.1.179: syn 1970627236
62.289271 192.168.11.4.60864 -> 169.254.21.1.179: syn 322961242
66.749888 192.168.11.4.60874 -> 169.254.21.1.179: syn 915080138
67.750090 192.168.11.4.60874 -> 169.254.21.1.179: syn 915080138
69.752504 192.168.11.4.60874 -> 169.254.21.1.179: syn 915080138
70.903522 192.168.11.4.60876 -> 169.254.21.1.179: syn 2685219155
75.342843 169.254.21.1.7372 -> 169.254.21.2.179: syn 1534538556
75.346864 169.254.21.2.179 -> 169.254.21.1.7372: syn 2820733398 ack 1534538557
75.346941 169.254.21.1.7372 -> 169.254.21.2.179: ack 2820733399
75.347020 169.254.21.1.7372 -> 169.254.21.2.179: psh 1534538557 ack 2820733399
75.355025 169.254.21.2.179 -> 169.254.21.1.7372: psh 2820733399 ack 1534538652
75.355059 169.254.21.1.7372 -> 169.254.21.2.179: ack 2820733462
75.355075 169.254.21.2.179 -> 169.254.21.1.7372: psh 2820733462 ack 1534538652
75.355097 169.254.21.1.7372 -> 169.254.21.2.179: ack 2820733481
設定２：FortiGateVM on Azure
AzureにFortiGateVMをデプロイし、SD-WAN/ADVPN2.0のスポークルータとして構成します。
仮想マシン（VM）を作成します。イメージは「Fortinet FortiGate-VM」を選択します。
ネットワークの設定でWAN側インターフェース（port1）が所属するサブネットを選択します。
デプロイ完了後、FortiGateVMをルータとして動作させるため、各NICを選択し「IP転送を有効にする」にチェックを入れます。
各NICのIPアドレスを静的に設定します。エラーとなる場合は一旦FortiGateVMを停止してから操作します。
AzureでNICのIPアドレスを静的に設定した後、FortiGateVMにコンソール接続しCLIでもIPアドレスを設定します。
config system interface
edit port1
set ip 192.168.1.251 255.255.255.0
end
これらの設定はport1、port2それぞれに対して行います。それからADVPNの設定を行いますが、過去の記事で解説しているため今回は省略します。FortiGateVM on AWS でSD-WAN/ADVPN2.0を試す（第二回：ADVPN設定編）をご参照ください。
動作確認
AWSのHUBルータ(FortiGateVM)とADVPNが確立され、BGPでルート情報を学習できていることを確認しましょう。
Spoke(Azure：FortiGateVM)
# get router info bgp sum
-SNIP-
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.202.1.11 4 65201 2662 2664 3 0 0 00:44:16 1
# get router info bgp network
-SNIP-
Network Next Hop Metric LocPrf Weight RouteTag Path
*>i192.168.0.0/16 10.202.1.11 0 100 0 0 i <-/1>
*> 0.0.0.0 100 32768 0 i <-/1>
# get router info routing-table all
-SNIP-
Routing table for VRF=0
S* 0.0.0.0/0 [1/0] via 192.168.1.1, port1, [1/0]
[1/0] via advpn tunnel *.*.*.*(AWSのElastic IP), [1/0]
S 10.202.1.11/32 [15/0] via advpn tunnel *.*.*.*(AWSのElastic IP), [1/0]
C 10.202.1.250/32 is directly connected, Lo
B 192.168.0.0/16 [200/0] via 10.202.1.11 (recursive via advpn tunnel *.*.*.*(AWSのElastic IP)), 00:44:25, [1/0]
C 192.168.1.0/24 is directly connected, port1
C 192.168.10.0/24 is directly connected, port2
S 192.168.22.0/24 [10/0] via 192.168.10.1, port2, [1/0]
設定３：ARS～FortiGateVM間eBGPピアリング
今回のメインコンテンツであるARSを作成し、FortiGateVMとeBGPネイバーを確立させるよう構成します。
Azure Route Server(ARS)
ARSをデプロイするためには専用のサブネットが必要です。サブネットの目的で「Route Server」を選択してサブネットを作成します。
MarketplaceでARSを検索しデプロイします。
必要なパラメータは少なく、VNetとRoute Serverサブネットを選択し、パブリックIPアドレスを設定します。パブリックIPアドレスはユーザトラフィックに利用されるのではなく、Azureの基になるSDNと管理プラットフォームがARSと通信するために必要です。
さて、この状態でARSをデプロイすると以下のようなエラーが出力されます。
これは、ARSをデプロイするためにはARSと同じVNetに存在するVPN Gatewayがアクティブ/アクティブモードで動作している必要があるのですが、設定２でデプロイしたVPN Gatewayがアクティブ/パッシブモードで動作しているためです。VPN Gatewayはアクティブ/パッシブモードでデプロイした後からでもアクティブ/アクティブモードに変更することが可能ですので変更してみましょう。なおVPN Gatewayをアクティブ/アクティブモードにするためにはVpnGw1AZ以上のSKUが必要なため、そちらも変更します。また、アクティブ/アクティブモードに変更するとVPN Gatewayが使用するパブリックIPアドレスも2つ必要になる点にご注意ください。
ARSの要件どおりにVPN Gatewayを再構成し、再度ARSをデプロイしてみます。無事デプロイに成功しました。
作成したARSの「構成」で「ブランチ間」を有効にセットします。この設定によりVPN Gateway経由で学習したルート情報を他のBGPピアにアドバタイズするようになります。
BGPピアを追加します。FortiGateVMのBGP AS番号とIPアドレスを設定するだけでOKです。
なお、VPN GatewayとのiBGPピア設定は特に必要ありません。
Spoke(Azure：FortiGateVM)
FortiGateVMでARSとのeBGPネイバーを張るための設定を追加します。異なるサブネットとのBGPピアリングのため、ARSサブネット宛のスタティックルートとeBGPマルチホップは必須の設定です。
config router static
edit 2
set dst 192.168.22.0 255.255.255.0
set gateway 192.168.10.1
set device "port2"
next
end
config router bgp
config neighbor
edit "192.168.22.5"
set advertisement-interval 1
set capability-graceful-restart enable
set ebgp-enforce-multihop enable
set soft-reconfiguration enable
set remote-as 65515
next
end
end
動作確認
ここまでで以下の図のようなBGPルーティング構成ができました。各コンポーネントでBGPによるルート情報を学習できているか確認し、オンプレミスとBranch間の疎通確認を行います。
Azure
- ARS
ARSがFortiGateVMから学習したBGPのルート情報を表示するにはCloud Shellで以下のコマンドが必要です。ARSがFortiGateVMから学習したルート情報が確認できます。
PS /home/******> Get-AzRouteServerPeerLearnedRoute -ResourceGroupName 'RouteServerTest' -RouteServerName 'ARS' -PeerName 'FGTVM'
LocalAddress Network NextHop SourcePeer Origin AsPath Weight
------------ ------- ------- ---------- ------ ------ ------
192.168.22.4 192.168.0.0/16 192.168.10.250 192.168.10.250 EBgp 65201 32769
192.168.22.4 192.168.7.0/24 192.168.10.250 192.168.10.250 EBgp 65201 32769
192.168.22.4 192.168.10.0/24 192.168.10.250 192.168.10.250 EBgp 65201 32769
ARSは自動的にVPN Gatewayがオンプレミスルータから学習したルート情報を保持しており、他のBGPネイバーにアドバタイズします。
PS /home/******> Get-AzRouteServerPeerAdvertisedRoute -ResourceGroupName 'RouteServerTest' -RouteServerName 'ARS' -PeerName 'FGTVM'
LocalAddress Network NextHop SourcePeer Origin AsPath Weight
------------ ------- ------- ---------- ------ ------ ------
192.168.22.4 192.168.1.0/24 192.168.22.4 Igp 65515 0
192.168.22.4 192.168.10.0/24 192.168.22.4 Igp 65515 0
192.168.22.4 192.168.11.0/24 192.168.22.4 Igp 65515 0
192.168.22.4 192.168.22.0/24 192.168.22.4 Igp 65515 0
192.168.22.4 192.168.2.0/24 192.168.22.4 Igp 65515 0
192.168.22.4 10.0.0.0/16 192.168.22.4 Igp 65515 0
- VPN Gateway
VPN Gatewayが学習したルート情報と、ARSやサブネットのルートテーブルにアドバタイズするルート情報もCloud Shellで確認できます。今回はARSの要件のためにアクティブ/アクティブモードで構成しましたが、オンプレミスルータとのIPsecVPNはシングル構成にしているため、192.168.11.4側のみオンプレミスのルートを学習していることが分かります。（下図参照）
PS /home/******> Get-AzVirtualNetworkGatewayLearnedRoute -VirtualNetworkGatewayName VGW -ResourceGroupName RouteServerTest
LocalAddress Network NextHop SourcePeer Origin AsPath Weight
------------ ------- ------- ---------- ------ ------ ------
192.168.11.5 192.168.1.0/24 192.168.11.5 Network 32768
192.168.11.5 192.168.10.0/24 192.168.11.5 Network 32768
192.168.11.5 192.168.11.0/24 192.168.11.5 Network 32768
192.168.11.5 192.168.22.0/24 192.168.11.5 Network 32768
192.168.11.5 169.254.21.1/32 192.168.11.4 192.168.11.4 IBgp 32768
192.168.11.5 192.168.2.0/24 192.168.11.4 192.168.11.4 IBgp 32768
192.168.11.5 192.168.2.0/24 192.168.11.4 192.168.22.4 IBgp 32768
192.168.11.5 192.168.2.0/24 192.168.11.4 192.168.22.5 IBgp 32768
192.168.11.5 192.168.7.0/24 192.168.10.250 192.168.22.4 IBgp 65201 32768
192.168.11.5 192.168.0.0/16 192.168.10.250 192.168.22.4 IBgp 65201 32768
192.168.11.4 192.168.1.0/24 192.168.11.4 Network 32768
192.168.11.4 192.168.10.0/24 192.168.11.4 Network 32768
192.168.11.4 192.168.11.0/24 192.168.11.4 Network 32768
192.168.11.4 192.168.22.0/24 192.168.11.4 Network 32768
192.168.11.4 169.254.21.1/32 192.168.11.4 Network 32768
192.168.11.4 192.168.2.0/24 192.168.11.4 Network 32768
192.168.11.4 192.168.7.0/24 192.168.10.250 192.168.22.4 IBgp 65201 32768
192.168.11.4 192.168.0.0/16 192.168.10.250 192.168.22.4 IBgp 65201 32768
192.168.11.4 192.168.2.0/24 169.254.21.1 169.254.21.1 EBgp 65001 32768
PS /home/******> Get-AzVirtualNetworkGatewayAdvertisedRoute -VirtualNetworkGatewayName VGW -ResourceGroupName RouteServerTest -Peer 169.254.21.1
LocalAddress Network NextHop SourcePeer Origin AsPath Weight
------------ ------- ------- ---------- ------ ------ ------
192.168.11.4 192.168.1.0/24 169.254.21.2 Igp 65515 0
192.168.11.4 192.168.10.0/24 169.254.21.2 Igp 65515 0
192.168.11.4 192.168.11.0/24 169.254.21.2 Igp 65515 0
192.168.11.4 192.168.22.0/24 169.254.21.2 Igp 65515 0
192.168.11.4 192.168.7.0/24 169.254.21.2 Igp 65515-65201 0
192.168.11.4 192.168.0.0/16 169.254.21.2 Igp 65515-65201 0
- サブネットのルートテーブル
VNetの各サブネットのルートテーブルにARSがFortiGateVMから学習したルート情報が反映されています。
Spoke(Azure：FortiGateVM)
FortiGateVMでの確認です。ARSとのBGPネイバーが確立されており、オンプレミスやAzureサブネットのルート情報をBGPで学習できていることが確認できます。
# get router info bgp sum
-SNIP-
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.202.1.11 4 65201 2662 2664 3 0 0 00:44:16 1
192.168.22.5 4 65515 743 727 2 0 0 00:07:58 4
# get router info bgp network
-SNIP-
Network Next Hop Metric LocPrf Weight RouteTag Path
*>i192.168.0.0/16 10.202.1.11 0 100 0 0 i <-/1>
*> 192.168.1.0 192.168.22.4 0 0 0 65515 i <-/1>
*> 192.168.2.0 192.168.22.4 0 0 0 65515 i <-/1>
*>i192.168.7.0 10.202.7.250 0 100 0 0 i <-/1>
* 192.168.10.0 192.168.22.4 0 0 0 65515 i <-/->
*> 0.0.0.0 100 32768 0 i <-/1>
*> 192.168.11.0 192.168.22.4 0 0 0 65515 i <-/1>
*> 192.168.22.0 192.168.22.4 0 0 0 65515 i <-/1>
# get router info routing-table all
-SNIP-
Routing table for VRF=0
S* 0.0.0.0/0 [1/0] via 192.168.1.1, port1, [1/0]
[1/0] via advpn tunnel *.*.*.*(AWSのElastic IP), [1/0]
S 10.202.1.11/32 [15/0] via advpn tunnel *.*.*.*(AWSのElastic IP), [1/0]
C 10.202.1.250/32 is directly connected, Lo
S 10.202.7.250/32 [15/0] via advpn_0 tunnel 10.202.7.250, [1/0]
B 192.168.0.0/16 [200/0] via 10.202.1.11 (recursive via advpn tunnel *.*.*.*(AWSのElastic IP)), 01:20:35, [1/0]
C 192.168.1.0/24 is directly connected, port1
B 192.168.2.0/24 [20/0] via 192.168.22.4 (recursive via 192.168.10.1, port2), 01:21:18, [1/0]
C 192.168.10.0/24 is directly connected, port2
B 192.168.11.0/24 [20/0] via 192.168.22.4 (recursive via 192.168.10.1, port2), 01:21:18, [1/0]
S 192.168.22.0/24 [10/0] via 192.168.10.1, port2, [1/0]
On-Prem(FortiGate 40F)
オンプレミスルータのFortiGate40Fでも確認してみます。ADVPNのHUBをオリジンとする192.168.0.0/16のサマリルートを学習できています。
# get router info bgp network
-SNIP-
Network Next Hop Metric LocPrf Weight RouteTag Path
*> 192.168.0.0/16 169.254.21.2 0 0 0 65515 65201 i <-/1>
# get router info routing-table all
-SNIP-
Routing table for VRF=0
B 192.168.0.0/16 [20/0] via 169.254.21.2 (recursive via azure tunnel *.*.*.*（VPN GatewayのパブリックIPアドレス）), 00:21:29, [1/0]
疎通確認
オンプレミスのPCからBranchのPCへPingによる疎通確認を行います。なお、ARSはBGPでルート情報を交換するだけの役割を持ち、実際のトラフィックを転送しません。 そのためBGPのルートをアドバタイズする際にNextHopを変更しません。従って実際のパケットの転送経路は下図のようにオンプレミスルータ⇒VPN Gateway⇒FortiGateVMとなります。
4発目のPingの遅延が小さくなっていることから、ADVPN Shortcutが張られたことが推察できます。（ADVPNのHUBルータであるAWS上のFortiGateVMは、遅延の大小で検証結果を分かりやすくするためUSのリージョンにデプロイしています）
C:\Users\user01>ping 192.168.7.100
192.168.7.100 に ping を送信しています 32 バイトのデータ:
192.168.7.100 からの応答: バイト数 =32 時間 =331ms TTL=124
192.168.7.100 からの応答: バイト数 =32 時間 =326ms TTL=124
192.168.7.100 からの応答: バイト数 =32 時間 =327ms TTL=124
192.168.7.100 からの応答: バイト数 =32 時間 =10ms TTL=125
192.168.7.100 の ping 統計:
パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
最小 = 10ms、最大 = 331ms、平均 = 248ms
Tracerouteで確認してみます。やはりFortiGateVMとBranchのFortiGate40F間でADVPN Shortcutが張られており、AWSのHUBルータを経由せず直接通信できていることが分かります。
C:\Users\user01>tracert -d 192.168.7.100
192.168.7.100 へのルートをトレースしています。経由するホップ数は最大 30 です
1 1 ms <1 ms <1 ms 192.168.2.250
2 6 ms 6 ms 6 ms 192.168.10.250
3 10 ms 11 ms 9 ms 192.168.1.252
4 11 ms 10 ms 10 ms 192.168.7.100
トレースを完了しました。
Spoke(Azure：FortiGateVM)
FortiGateVMでもADVPN Shortcutが張れていることが確認できます。
# diagnoget router info routing-table all
-SNIP-
S 10.202.7.250/32 [15/0] via advpn_0 tunnel *.*.*.*(BranchのISPグローバルIPアドレス), [1/0]
B 192.168.7.0/24 [200/0] via 10.202.7.250 (recursive via advpn_0 tunnel *.*.*.*(BranchのISPグローバルIPアドレス)), 00:07:09, [1/0]
Tips：シングル構成でのARSとNVA間のBGPピアリングは非サポート
今回の検証の中でつまずいた点を紹介します。以下の図のようにFortiGateVMにおけるARS向けのBGPアドレスを、ARSサブネットの二番目のIPアドレス（今回は192.168.22.5）に設定し、かつ、VPN Gateway～オンプレミスルータ間のIPsecVPNで一番目のIPアドレスを使用した場合、疎通がNGになりました。
サポートに確認したところシングル構成は非サポートであり、なぜこのような動作になるのかは回答が難しいとのことでした。当然ながら、商用環境ではVPN Gateway～オンプレミスルータ間およびFortiGateVM～ARS間ともにBGPによる冗長経路構成をとりましょう。
設定４：ARSとのVNetピアリング
ARSは異なるVNetのルートもVNetピアリングにより自動的に学習することが可能です。こちらも試してみたいと思います。
上図のうち、左側にあるサーバ用VNetとサーバVMの作成手順は省略します。
VNetピアリング
サーバ用VNetの左ペインから「ピアリング」をクリックし、追加ボタンでVNetピアリングを作成します。ピアとなるのはARSのため、下図のようにリモート（ARS）とローカル（サーバ用VNet）のチェックボックスをONにし、デプロイします。
デプロイされたら各VNetにピアリングが1つずつ作成されます。
- サーバ用VNet側
- ARS側
動作確認
これまでと同様に各コンポーネントでBGPによるルート情報を学習できているか確認し、サーバVMとBranch間の疎通確認を行います。
Azure
- ARS
FortiGateVMへのアドバタイズルートでサーバ用VNetのルート情報が記載されています。
PS /home/******> Get-AzRouteServerPeerAdvertisedRoute -ResourceGroupName 'RouteServerTest' -RouteServerName 'ARS' -PeerName 'FGTVM'
LocalAddress Network NextHop SourcePeer Origin AsPath Weight
------------ ------- ------- ---------- ------ ------ ------
192.168.22.4 192.168.1.0/24 192.168.22.4 Igp 65515 0
192.168.22.4 192.168.10.0/24 192.168.22.4 Igp 65515 0
192.168.22.4 192.168.11.0/24 192.168.22.4 Igp 65515 0
192.168.22.4 192.168.22.0/24 192.168.22.4 Igp 65515 0
192.168.22.4 192.168.2.0/24 192.168.22.4 Igp 65515 0
192.168.22.4 10.0.0.0/16 192.168.22.4 Igp 65515 0
- VPN Gateway
オンプレミスルータへのアドバタイズルートでサーバ用VNetのルート情報が記載されています。
PS /home/******> Get-AzVirtualNetworkGatewayAdvertisedRoute -VirtualNetworkGatewayName VGW -ResourceGroupName RouteServerTest -Peer 169.254.21.1
LocalAddress Network NextHop SourcePeer Origin AsPath Weight
------------ ------- ------- ---------- ------ ------ ------
192.168.11.4 192.168.1.0/24 169.254.21.2 Igp 65515 0
192.168.11.4 192.168.10.0/24 169.254.21.2 Igp 65515 0
192.168.11.4 192.168.11.0/24 169.254.21.2 Igp 65515 0
192.168.11.4 192.168.22.0/24 169.254.21.2 Igp 65515 0
192.168.11.4 192.168.7.0/24 169.254.21.2 Igp 65515-65201 0
192.168.11.4 192.168.0.0/16 169.254.21.2 Igp 65515-65201 0
192.168.11.4 10.0.0.0/16 169.254.21.2 Igp 65515 0
Spoke(Azure：FortiGateVM)
FortiGateVMでもサーバ用VNetのルート情報を学習できています。
# get router info bgp network
-SNIP-
Network Next Hop Metric LocPrf Weight RouteTag Path
*> 10.0.0.0/16 192.168.22.4 0 0 0 65515 i <-/1>
*>i192.168.0.0/16 10.202.1.11 0 100 0 0 i <-/1>
*> 192.168.1.0 192.168.22.4 0 0 0 65515 i <-/1>
*> 192.168.2.0 192.168.22.4 0 0 0 65515 i <-/1>
*>i192.168.7.0 10.202.7.250 0 100 0 0 i <-/1>
* 192.168.10.0 192.168.22.4 0 0 0 65515 i <-/->
*> 0.0.0.0 100 32768 0 i <-/1>
*> 192.168.11.0 192.168.22.4 0 0 0 65515 i <-/1>
*> 192.168.22.0 192.168.22.4 0 0 0 65515 i <-/1>
# get router info routing-table all
-SNIP-
Routing table for VRF=0
S* 0.0.0.0/0 [1/0] via 192.168.1.1, port1, [1/0]
[1/0] via advpn tunnel *.*.*.*(AWSのElastic IP), [1/0]
B 10.0.0.0/16 [20/0] via 192.168.22.4 (recursive via 192.168.10.1, port2), 00:21:05, [1/0]
S 10.202.1.11/32 [15/0] via advpn tunnel *.*.*.*(AWSのElastic IP), [1/0]
C 10.202.1.250/32 is directly connected, Lo
S 10.202.7.250/32 [15/0] via advpn_0 tunnel 10.202.7.250, [1/0]
B 192.168.0.0/16 [200/0] via 10.202.1.11 (recursive via advpn tunnel *.*.*.*(AWSのElastic IP)), 01:20:35, [1/0]
C 192.168.1.0/24 is directly connected, port1
B 192.168.2.0/24 [20/0] via 192.168.22.4 (recursive via 192.168.10.1, port2), 01:21:18, [1/0]
B 192.168.7.0/24 [200/0] via 10.202.7.250 (recursive via advpn_0 tunnel 10.202.7.250), 00:53:25, [1/0]
C 192.168.10.0/24 is directly connected, port2
B 192.168.11.0/24 [20/0] via 192.168.22.4 (recursive via 192.168.10.1, port2), 01:21:18, [1/0]
S 192.168.22.0/24 [10/0] via 192.168.10.1, port2, [1/0]
疎通確認
BranchのPCからサーバVMへPingによる疎通確認を行います。
4発目のPingの遅延が小さくなっていることから、ADVPN Shortcutが張られたことが推察できます。
PS C:\Users\user01> ping 10.0.0.100
10.0.0.100 に ping を送信しています 32 バイトのデータ:
10.0.0.100 からの応答: バイト数 =32 時間 =332ms TTL=61
10.0.0.100 からの応答: バイト数 =32 時間 =329ms TTL=61
10.0.0.100 からの応答: バイト数 =32 時間 =329ms TTL=61
10.0.0.100 からの応答: バイト数 =32 時間 =6ms TTL=62
10.0.0.100 の ping 統計:
パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
最小 = 6ms、最大 = 332ms、平均 = 249ms
Tracerouteで確認してみます。やはりFortiGateVMとBranchのFortiGate40F間でADVPN Shortcutが張られており、AWSのHUBルータを経由せず直接通信できていることが分かります。
PS C:\Users\user01> tracert -d 10.0.0.100
10.0.0.100 へのルートをトレースしています。経由するホップ数は最大 30 です
1 <1 ms <1 ms <1 ms 192.168.7.250
2 4 ms 4 ms 4 ms 192.168.1.251
3 6 ms 5 ms 6 ms 10.0.0.100
トレースを完了しました。
Branch(FortiGate 40F)
BranchのFortiGateでもAzureのFortiGateVMからのルートを学習できていることを確認します。オンプレミスのルート（192.168.2.0/24）、サーバVM用VNetのルート（10.0.0.0/16）他AzureのサブネットルートがADVPN Shortcut経由で学習できていることが分かります。
# get router info bgp network
-SNIP-
Network Next Hop Metric LocPrf Weight RouteTag Path
*>i10.0.0.0/16 10.202.1.250 0 100 0 0 65515 i <-/1>
*>i192.168.0.0/16 10.202.1.11 0 100 0 0 i <-/1>
*>i192.168.1.0 10.202.1.250 0 100 0 0 65515 i <-/1>
*>i192.168.2.0 10.202.1.250 0 100 0 0 65515 i <-/1>
*> 192.168.7.0 0.0.0.0 100 32768 0 i <-/1>
*>i192.168.10.0 10.202.1.250 0 100 0 0 i <-/1>
*>i192.168.11.0 10.202.1.250 0 100 0 0 65515 i <-/1>
*>i192.168.22.0 10.202.1.250 0 100 0 0 65515 i <-/1>
# get router info routing-table all
-SNIP-
S* 0.0.0.0/0 [1/0] via 192.168.1.1, wan, [1/0]
[1/0] via advpn tunnel *.*.*.*(AWSのElastic IP, [1/0]
B 10.0.0.0/16 [200/0] via 10.202.1.250 (recursive via advpn_0 tunnel *.*.*.*(AzureのPublic IP)), 00:00:25, [1/0]
S 10.202.1.11/32 [15/0] via advpn tunnel *.*.*.*(AWSのElastic IP, [1/0]
S 10.202.1.250/32 [15/0] via advpn_0 tunnel *.*.*.*(AzureのPublic IP), [1/0]
C 10.202.7.250/32 is directly connected, Lo
B 192.168.0.0/16 [200/0] via 10.202.1.11 (recursive via advpn tunnel *.*.*.*(AWSのElastic IP), 00:51:15, [1/0]
C 192.168.1.0/24 is directly connected, wan
B 192.168.2.0/24 [200/0] via 10.202.1.250 (recursive via advpn_0 tunnel *.*.*.*(AzureのPublic IP)), 00:00:25, [1/0]
C 192.168.7.0/24 is directly connected, lan
B 192.168.10.0/24 [200/0] via 10.202.1.250 (recursive via advpn_0 tunnel *.*.*.*(AzureのPublic IP)), 00:00:25, [1/0]
B 192.168.11.0/24 [200/0] via 10.202.1.250 (recursive via advpn_0 tunnel *.*.*.*(AzureのPublic IP)), 00:00:25, [1/0]
B 192.168.22.0/24 [200/0] via 10.202.1.250 (recursive via advpn_0 tunnel *.*.*.*(AzureのPublic IP)), 00:00:25, [1/0]
省略しますが、オンプレミスのPCとサーバVM間の疎通も問題ありませんでした。
まとめ
今回はFortiGateVM on AzureをADVPNのSpokeとしてデプロイし、ARSを用いてAzureネットワークをFortiGateVM on AWS上のSD-WAN/ADVPN2.0ネットワークに統合する方法を紹介しました。パブリッククラウド上にデプロイしたFortiGateVMの役割をHUB＆Spoke構成のSpokeとするアプローチは企業ネットワークのニーズにマッチすることも多いと思います。また、ARSを活用すれば完全な動的ルーティングネットワークが形成できるため、構成変更が生じた際もメンテナンスフリーでマイグレーションが可能になるメリットは大きいです。
次回はAWS側のマネージドネットワークサービスとの統合に関する記事を考えています。ご期待ください！
一緒に働く仲間を募集しています！
NTTデータ セキュリティ＆ネットワーク事業部では以下の職種を募集しています。
参考文献
NTT DATA公式アカウントです。 技術を愛するNTT DATAの技術者が、気軽に楽しく発信していきます。 当社のサービスなどについてのお問い合わせは、 お問い合わせフォーム nttdata.com/jp/ja/contact-us/ へお願いします。