はじめに

強制トンネリングとは、すべてのネットワークトラフィックを特定の経路（たとえば VPN サーバーやファイアウォール）を通過させるよう強制する仕組みを指しています。

まず初めにオンプレミスの物理ネットワークと Azure 仮想ネットワークをサイト間 (S2S) で接続していた場合を考えてみましょう。

通常のネットワーク
相互のホスト間の通信は、S2S を通りますが、インターネットへのトラフィックは、それぞれのデフォルトゲートウェイから直接インターネットに抜けていきます。

上記のネットワークに対して、強制トンネリング は、以下のように２通りの構成が考えられます。
① 強制トンネリング（Azure → オンプレミス）← 本記事のターゲット
② 強制トンネリング（オンプレミス → Azure）

① 強制トンネリング（Azure → オンプレミス）
Azure から外のトラフィックは、強制的に S2S を通ってから、オンプレミス経由でインターネットに抜けていきます。

本記事のターゲット
本記事では、Azure → オンプレミス方向の強制トンネリングを YAMAHA RTX の BGP を使って、簡単に構成する方法を紹介を次章にて紹介しています。

Azure → オンプレミスの場合のメリット
すでにオンプレミス側で厳格なファイアウォールポリシーで運用されている場合に、Azure から外へのトラフィックにも、同様の制限で一元管理をすることができます。

Azure → オンプレミスの場合の注意点

① パブリック IP から接続できなくなる
Azure VM は、オンプレミス側としか通信できなくなるため、インターネットから、直接 Azure VM のパブリック IP に対して通信ができなくなります。
RDP などもつながりませんので、オンプレミス側から、S2S 経由で RDP する必要があります。
※セキュリティが高まるので、メリットと考えることもできます。

② 通信料が掛かる
Azure では外に出ていくトラフィックに対して課金が発生します。
そのため、Azure から、インターネットへ出ていくトラフィックがすべて課金の対象となる点に注意が必要です。
とはいえ、出ていくトラフィックなので、アップロードに対する課金です。
一般にボリュームがあるのは、ダウンロードなので、課金額はそれほどではないかもしれません。

③ Azure KMS の考慮が必要
こちらについては、最終章で説明しています。

② 強制トンネリング（オンプレミス → Azure）
オンプレミスから外のトラフィックは、強制的に S2S を通ってから、Azure 経由でインターネットに抜けていきます。

こちらの方法は、実現するために、いくつかのコンポーネントを組み合わせる必要があって、難易度が高くなります。以下の Support Blog に詳しく書かれていますが、いずれこの方法も記事にしたいと思います。

オンプレミス → Azure の場合の注意点

通信料が掛かる
オンプレミス側から、アップロードをする際にも、ダウンロードをする際にも通信料が発生します。
これは、意外と盲点ですが、どちらも課金が掛かることになります。

アップロードは、Azure Firewall からトラフィックが出ていくとき。
ダウンロードは、Azure からオンプレミスへ S2S の通信でトラフィックが出ていくとき（Azure から見ると送信になります）

ダウンロードでは、ボリュームのある通信が発生しがちで、高額となる恐れがあるので、注意しましょう。

Support Blog：オンプレミスからのインターネット宛ての通信を Azure 経由にする方法
https://jpaztech.github.io/blog/network/forcetunneling-azure-to-onpre-configuration/

注意
このように、強制トンネリングと言っても、どちらの向きを指しているのか混同しないようにしましょう。

強制トンネリング（Azure → オンプレミス）の実現方法

この構成を実現する場合は、さらに 2 通りの方法があります。
① BGP を使用して構成する　← 本記事のターゲット
② 既定のサイトを使用して構成する

上記の ① と ② の方法は、以下の公開情報で説明されています。

公開情報：サイト間構成用の強制トンネリングについて
https://learn.microsoft.com/ja-jp/azure/vpn-gateway/about-site-to-site-tunneling?wt.mc_id=mvp_407731

本記事のターゲット
本記事では、① の BGP を使って、簡単に強制トンネリングを構成する方法を紹介しています。

参考：② 既定のサイトを使用して構成する
BGP ではなく、"既定のサイト" という仕組みでコマンドで強制トンネリングを構成する場合は、以下の公開情報が参考になります。ちょっと手間が掛かりますが、BGP を採用できない場合には、こちらの方法を検討しましょう。

公開情報：サイト間接続に既定のサイトを使用して強制トンネリングを構成する
https://learn.microsoft.com/ja-jp/azure/vpn-gateway/site-to-site-tunneling?wt.mc_id=mvp_407731

（参考）Azure上のVMのDefault Gatewayをオンプレミスに向けてみる(強制トンネリング、Forced Tunneling)
https://qiita.com/hidekko/items/c6da30484e3dda87e7b1

前提事項

以下の記事の構成で、YAMAHA RTX を使って、オンプレミスと Azure が S2S で接続されていること。この構成が前提となっています。

この時点で、BGP が有効になっていることがポイントです。

実現方法の検討

構成方法については、公開情報では、以下のことしか書かれていません。

公開情報：BGP を使用して構成する
https://learn.microsoft.com/ja-jp/azure/vpn-gateway/about-site-to-site-tunneling?wt.mc_id=mvp_407731#configure-using-bgp

（上記より抜粋）
BGP 経由で VPN Gateway の強制トンネリングを構成できます。すべての Azure トラフィックが VPN Gateway S2S トンネル経由で送信されるように、オンプレミスの場所から Azure に BGP 経由で既定の 0.0.0.0/0 の出力をアドバタイズする必要があります。

疑問？
さて、上記の 0.0.0.0/0 をアドバタイズする・・というのは、何をすれば良いのでしょうか？
その方法について、次章で説明していきます。

構築手順（YAMAHA RTX で強制トンネリングを構成する）

前提事項の構成ができていれば、実はとっても簡単です。
以下の BGP に関する設定の箇所に、赤字の部分を追加で設定するだけです。

BGP 設定の箇所を抜粋
bgp use on
bgp autonomous-system 65530
bgp neighbor 1 65521 10.10.50.254 hold-time=30 local-address=192.168.254.1 igno
re-capability=on
bgp router id 192.168.100.1
bgp import filter 1 equal 192.168.100.0/24
bgp import filter 2 include 0.0.0.0/0
bgp import 65521 static filter 1 2

BGP 設定の反映方法

bgp import filter 2 include 0.0.0.0/0 のコマンドを実行すると、以下のメッセージが表示されます。
その場合は、その指示に従って bgp configure refresh を実行してください。このコマンドを実行するまでは、設定が反映されません。

（メッセージの内容）
BGPの設定が変更されました。
すべての設定が完了したら、設定を有効にするために'bgp configure refresh'コマンドを実行してください。

設定変更後のステータス

Azure リソース

VPN Gateway の BGP ピア

YAMAHA RTX がアドバタイズ（広報）したデフォルトルート（0.0.0.0/0）が表示されています（緑色）
さらに、YAMAHA RTX の WAN 側のアドレス（水色）も広報されています。このアドレスは、環境によって異なります。

VM の有効なルート

BGP ピアに加わったのと同じルートが、各 VM の NIC まで浸透しています。
これによって、VM にとってのデフォルトゲートウェイが仮想ネットワークゲートウェイに設定されます。

VM がインターネットを参照した時のグローバル IP アドレスの変化

確認方法
強制トンネリングを構成する前後で、以下の URL へアクセスしてグローバル IP アドレスをチェックします。
https://www.cman.jp/network/support/go_access.cgi

Before
Azure のパブリック IP が表示されています。

After
オンプレミス側でプロバイダーから割り当てられたグローバル IP アドレスが表示されています。
これによって、強制トンネリングが動作していることが確認できます。

強制トンネリングの解除方法

１．bgp import 65521 static filter 1 を実行します（filter 2 を切り離しています）
２．no bgp import filter 2 というコマンドを実行します（0.0.0.0/0 の広報を無効化しています）
３．bgp configure refresh を実行して反映させます。

これで 0.0.0.0/0 が広報されなくなり、強制トンネリングが解除されます。

注意点：Azure KMS について

前章までの構成で、オンプレミスからトラフィックが出るようになっていて、強制トンネリングが構成できています。見た目上は、これで完成のように見えます。

しかし、そのせいで思わぬ副作用が発生しています。
なんと、Azure VM の OS のライセンス認証ができない状態になっており、評価モードになってしまいます。

さらなる注意点
一度、ライセンス認証されていた VM は、180 日が経過してから、評価モードになるので、気づかない恐れがあるので、気を付けましょう。

Support Blog：自動的なライセンス認証および有効期限について
https://jpaztech.github.io/blog/vm/kms-troubleshooting/#自動的なライセンス認証および有効期限について

このための回避策として、Azure KMS へのルーティングを個別に構成する必要があります。
手順については、以下の公開情報および Support Blog に分かりやすく書かれています。

公開情報：強制トンネリングを使用したライセンス認証の問題
https://learn.microsoft.com/ja-jp/troubleshoot/azure/virtual-machines/windows/custom-routes-enable-kms-activation?wt.mc_id=mvp_407731

Support Blog：強制トンネリング環境（オンプレミス等を経由し直接通信となっていない）
https://jpaztech.github.io/blog/vm/kms-troubleshooting/#強制トンネリング環境（オンプレミス等を経由し直接通信となっていない）