はじめに
強制トンネリングとは、すべてのネットワークトラフィックを特定の経路（たとえば 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/#強制トンネリング環境（オンプレミス等を経由し直接通信となっていない）