Azure上のVMのDefault Gatewayをオンプレミスに向けてみる(強制トンネリング、Forced Tunneling)

こんにちわ。
世間はIgniteで盛り上がっていますが、まだ内容を確認できていないので平常運転でいきます。
Qiita内で「強制トンネリング」と検索してもヒットしなかったので書いてみます。

#Azure上のVMのDefault Gatewayをオンプレミスに向けたい場合
Azure上のVMのDefault Gatewayをオンプレミスに向ける、これを日本語では強制トンネリング、英語ではForced Tunnelingと言います。
本記事では以降用語を強制トンネリングで統一します。
設定方法や概念は公式ドキュメントだとここに記載があります。
過去にも何度かお客様環境に実装したことのある構成ですので、今回弊社環境でデモ環境を作ってみます。

#強制トンネリングはどういう環境になるのか？
強制トンネリングとはAzure上のネットワーク構成、特にDefault Gatewayに関するルーティング構成です。
強制トンネリングでない通常の構成では、Azure上のVMはAzureから直接インターネットに接続しています。
先ほどの公式ドキュメントにも構成図があるのですが、本記事でも簡単に作成してみました。

##通常構成
まずは比較の為強制トンネリングでない、通常の構成を記載します。

はい。
「Azure上のVMはAzureからインターネットに直接接続しています。」
という言葉を構成図にするとこうなります。
この構成を本記事では便宜上「通常構成」と呼びます。

##強制トンネリング構成
それでは本題の強制トンネリングの構成です。

はい。
このようにAzure上のVMからのインターネット通信が一度オンプレミスのルーターに転送され、オンプレミスのルーターからインターネット接続する経路になります。
本記事の強制トンネリングはどういう環境になるのか？で述べた「Default Gatewayに関するルーティング構成」ということになります。

#強制トンネリングのメリットとデメリット
まずはメリットから
##強制トンネリングのメリット
・Azure上のVMもオンプレミスのマシンも、共通のルーター、Firewall、UTMからインターネット接続を行うため、ポリシーの一元管理が容易にできる。
これは小規模だとあまり感じないかもしれませんが、大規模になると結構響いてきます。
例えば10拠点あるネットワーク環境を想定し、それぞれの拠点からインターネット接続を行っている場合を考えてみてください。
同じネットワークポリシー、例えばQiitaには接続してもいいがFacebookは接続NG、のような接続先を絞るネットワークポリシーが存在する場合、10拠点バラバラでインターネット接続を行っていれば、ネットワークポリシー変更時に10台のネットワーク機器で同じ設定を行わなければなりません。(最近一元管理のサービスも出てきていますので一概には言えませんが・・・)
これが1拠点のネットワーク機器から集約してインターネット接続を行っている環境であれば、1台のネットワーク機器の設定変更で済みます。
設定変更漏れの危険性が低くなるというメリットが考えられます。
この10拠点のうち、1拠点がAzureであると考えればメリットを感じてもらえると思います。

##強制トンネリングのデメリット
・Azure上のVMがインターネット接続を行う度にダウンロード課金がかかる。
これは結構致命的です。
Azure上にServerマシンしかない場合はWindows Updateやapt-update、apt-upgrade(yumも含む)のみの通信となりますので、かかる課金はある程度絞れると思いますが、それでも課金はかかります。
Windows Serverの場合はAzure上にWSUSを、Linuxの場合はローカルリポジトリを構築すればよりUpdateによる課金は絞れると思います。
しかしAzure上にAVDを構築する場合はダウンロード課金がえらいことになってしまいます。
・Azure上のVMがインターネット接続を行う度に、VPN接続帯域が圧迫される。
これもダウンロード課金と同じ原理で、VPN接続部分に負荷がかかるからです。
Azure上のVMにファイルサーバーがある場合、オンプレミスからVPN接続を介したAzureへの「上り」の通信と、Azure上のVMからインターネット接続を行う際の「下り」の通信がVPN接続部分に同時に発生します。
通信が輻輳しますね。

#強制トンネリングを選択するか否か
メリットとデメリットを比べてみるとデメリットの方が大きく見えるのですが、Azure上のVMがServerマシンしかなく、推奨されませんがAzure上のUpdateを停止した状態であればデメリットはなく、メリットの方が大きくなります。
ですので強制トンネリングの需要は一定ある、ということになります。

#検証
では検証していきましょう。
前出の公式ドキュメントではPowerShellで仮想ネットワークやVPN構築からゴリゴリ行っていますが、VPN構築までは構築済みと考えて、そこからGUIでできる部分はGUIで、PowerShellでないとできない部分はPowerShellでと、作業を分けて構築しましょう。

##現状確認
まずは通常構成になっているかの確認です。
以前の記事、NSGでWindows Updateを許可する方法で構築した環境のWindows 11が残っているので、これで確認します。

オンプレミス環境からWindows 11にインターネット経由でRDP接続しました。
画像の赤枠にご注目ください。
RDPの接続先グローバルIPアドレスと、いつもお世話になっている確認くんというサイトで確認したグローバルIPアドレスが合致していることがわかります。
これで通常の構成、つまりAzure上のVMであるこのWindows 11は、Azure上からインターネットに接続している、ということがわかります。
またオンプレミス環境宛のICMP通信(Ping)も元気に返答がある状態なので、VPN接続ができていることも確認できます。

#設定
前出の公式ドキュメント内の以下の赤枠部分は現在はGUIで設定可能です。

それでは設定していきましょう。

##GUI設定
[ルートテーブル]というサービスを呼び出し設定を行います。

ここでの肝は[リージョン]と[ゲートウェイのルートを伝達する]を[Yes]にすることです。
[リージョン]は強制トンネリングを設定したいサブネットが存在する仮想ネットワークの構築されているリージョンを選択します。
[ゲートウェイのルートを伝達する]は情報ボタンにホバーしてみると

[関連付けられたサブネットのネットワークインターフェースへのオンプレミスのルートの伝達を回避するには[いいえ]を選択します。]と出てきます。
詳細情報のリンクもあり、ますが、このリンクの記載は正直あまり関連性がありません。
このリンク先の項目の下の項目、[ボーダーゲートウェイプロトコル(BGPというルーティングプロトコルのこと)]の方がこのパラーメーターとの関係性が近いです。
詳細情報のリンクの全体の流れと、この[ゲートウェイのルートを伝達する]のパラメーターとの関連性を私なりに解釈して説明すると、Azureの仮想ネットワークの持つBGPのルートテーブルをオンプレミスに広報するか否か、という設定値です。
今回スタティックでルートを設定するのであまり関連性が無いように見えますが、オンプレミス側のルート設定もBGPで設定するなら[Yes]が必須の設定となります。
ここまで確認が終ればもう[確認及び作成]からデプロイしましょう。

##GUIでのルーティング設定
先ほど作成したルートテーブルにルーティングを設定し、強制トンネリングを有効にしたいサブネットに関連付けます。
まずはルーティング設定から行います。
先ほど作成したルートテーブルを選択し、[ルート]を選択して[追加]をクリックします。

そしてこの設定がかなり大事です。

[アドレス プレフィックス:0.0.0.0/0]
[ネクストホップの種類:仮想ネットワークゲートウェイ]
どっちも大事なので赤字です。
それぞれの意味ですが、
・アドレスプレフィックス:0.0.0.0/0
これは宛先IPアドレスの指定です。
通常は192.168.0.1/32や172.16.0.0/24など、ホストやネットワークアドレスを指定する設定値です。
この設定値をここで行っているように0.0.0.0/0にするとどうなるか、と言うと、ルーター上に明示的に記載の無いアドレス全てという意味になります。
ネットワークエンジニアにはお馴染みの設定値なんですけどね。
これがDefault GatewayのDefault、を意味する部分になります。
・ネクストホップの種類:仮想ネットワークゲートウェイ
こちらは読んで字の如く、ネクストホップにどこを指定するのか、という設定値です。
これを仮想ネットワークゲートウェイ、とすると、先の設定値と合わせて、0.0.0.0/0に合致するIPアドレスは全て仮想ネットワークゲートウェイに転送するという意味になります。
これでDefault Gatewayを仮想ネットワークゲートウェイに向けるという今回の作業の前半戦は終了です。
『「Default Gateway」ってなんなの？』
という方に簡単にご説明すると、ルートテーブル上に明示的に記載の無いアドレスすべての転送先ということになります。
これで[OK]をクリックして正しく設定が反映されたか確認します。

続いて[サブネット]をクリックします。
[関連付け]をクリックします。

以下の画面で強制トンネリング設定を行いたい仮想ネットワーク及びサブネットを指定します。

これでGUIでの設定は完了です。

そしてこの設定を行った瞬間にグローバルIPアドレス経由のRDPは切断されます。
Azure上のDefault Gatewayの設定が変わったので当然なのですが、事前に仕組みをわかっていないと焦りますね。
ちなみにこの状態でVMのローカルIPアドレス宛にRDP接続すると接続可能で、VMがインターネットに出れなくなっています。

こんな状態ですね。
なんでVPNが接続されたままでVMがインターネット接続できないかというと、単純に本記事の設定が完了していないからなのですが、次の項目のPowerShell設定を行わないと、VMの存在するサブネットのDefault Gatewayは仮想ゲートウェイを向いているが、その更にネクストホップが存在しないからなのです。

##PowerShell設定
ここからPowerShellでの設定になります。
PowerShellでの設定はとっても簡単。

DefaultGateway設定変更.sh

$rgName = "[リソースグループ名]"
$LGName = "[ローカルネットワークゲートウェイ名]"
$vgName = "[仮想ネットワークゲートウェイ名]"

$LocalGateway = Get-AzLocalNetworkGateway -Name $LGName -ResourceGroupName $rgName
$VirtualGateway = Get-AzVirtualNetworkGateway -Name $vgName -ResourceGroupName $rgName
Set-AzVirtualNetworkGatewayDefaultSite -GatewayDefaultSite $LocalGateway -VirtualNetworkGateway $VirtualGateway

これだけです。
それぞれのコマンドを説明していきますと、最初の3行は言わずもがな変数設定です。
実際の設定コマンド、4行目の$LocalGatewayですが、これはVPN接続設定時に作成する[ローカルネットワークゲートウェイ]というリソースを指定しています。
5行目、$VirtualGatewayですが、これもVPN接続設定時に作成する[仮想ネットワークゲートウェイ]というリソースを指定しています。
この[仮想ネットワークゲートウェイ]は先のGUIでの手順で指定した[ネクストホップの種類:仮想ネットワークゲートウェイ]の仮想ネットワークゲートウェイ]と同一です。

そして本記事の最大の目玉の設定値です。

6行目
Set-AzVirtualNetworkGatewayDefaultSite -GatewayDefaultSite $LocalGateway -VirtualNetworkGateway $VirtualGateway
大事な部分を赤字で表現すると
Set-AzVirtualNetworkGatewayDefaultSite -GatewayDefaultSite $LocalGateway -VirtualNetworkGateway $VirtualGateway
ここです。
これは4行目で指定したローカルゲートウェイを5行目で指定した仮想ネットワークゲートウェイに対して、Default SiteにVPN接続先のオンプレミス環境を指定する、という設定値です。
Default SiteというのはAzure独自の概念なのですが、Site、つまりVPN接続先を、Default Gateway(のネクストホップ)として指定する、という設定値です。
6行目のコマンドは設定してから返ってくるまで1分～2分ほど時間がかかりますので待ちましょう。
これでGUIで設定したサブネットのDefault Gatewayの更にネクストホップとしてオンプレミスのSite、ローカルネットワークゲートウェイが指定されました！
ここまででAzure側の設定は完了ですが、実はオンプレミス側でも設定が必要な場合があります。

##オンプレミス側の設定
これはオンプレミス側でどのような機器を使っているかによりますが、主にFirewall機能とNAT機能の設定変更が必要な場合があります。
先のPowerShell設定ができても、Azure上のWindows 11はこのような状態です。

分かりやすくするために8.8.8.8宛にもICMP通信を起こしてみました。
弊社はCiscoで検証を行ったので、Cisco側の設定変更を例として挙げます。
まずはCiscoのグローバルIPアドレスを確認します。

赤枠内ですね。
今回も図らずもグローバルIPアドレスをQiitaに晒してしまいました。

そしてCiscoに追加するConfigは以下の通りです。

Ciscoに追加するConfig.txt

access-list 1 permit 172.16.101.0 0.0.0.255

interface Tunnel[AzureとVPNを張っているトンネルインターフェース番号]
ip nat inside
ip virtual-reassembly in

enableやconfiguration terminal、write memoryは省略していますので忘れずに実行してください。
またOutBound方向のFirewall設定なども適宜設定してください。
そしてこのConfigを追加したところ、

このように無事にCiscoの持つグローバルIPアドレスとAzure上のWindows 11がブラウザに表示している確認くんのグローバルIPアドレスが一致していることからAzure上のVM、今回であればWindows 11がオンプレミスのCisco経由でインターネットに出ていることがわかります。
これで強制トンネリング環境の構築ができました。

#設定解除方法
GUI設定は作成したルートテーブルをサブネットから外し、削除してください。
PowerShellは以下のコマンドの実行が必要です。

DefaultGateway切り戻し設定変更.sh

$LGName = "cisco841m"
$vgName = "vgw-nsg-test01"

Remove-AzVirtualNetworkGatewayDefaultSite -VirtualNetworkGateway $VirtualGateway

検証が終ったら忘れずに切り戻ししておきましょう。

今日はここまで。