こんにちは、Clefable-Tです。
今日は強制トンネリング下環境でのKMS認証とその対処策についてお話したいと思います。
本記事の全体構成図
本記事の構成は以下の通りです。
- 強制トンネリングを実装しているExpress Routeと接続しているHUB VNETとSPOKE VNETをゲートウェイ転送で、ピアリングしている。
- 強制トンネリングの影響ですべての通信はオンプレミスを経由する
- HUB VNETではKMS認証用の通信用にユーザー定義ルートにて、直接外部環境（MSのKMS認証サーバーに出れるようにしている。）
↓が構成図
確認したいこと
SPOKE VNETがHUB VNET（ピアリング先のVNET）のUDRを使用して、SPOKE VNET側で発生したKMS認証に係る通信がなされうかどうかです。
図解するとこういう感じになります。
↓図解で説明
因みに・・・
強制トンネリング下でKMS認証の通信が、オンプレミスを経由するとKMS認証が失敗します。
※公式Docs有
リンク↓
結果どうだった？
SUB_Bでも別個UDRを作成して、定義しないとダメでした。
強制トンネリングが有効になっているHUB VNETとゲートウェイ転送が有効となっていたとしても、ピアリング先のSPOKE VNET側のKMS認証の通信はオンプレミスを経由するとのことです。
先述のオンプレミスを経由するとKMS認証が失敗するので、それを回避するためには、SPOKE VNET側でもUDRを設定しないとならない。というのが結論です。
↓図解
最後に
最後までお読みいただき、ありがとうございました。
今日は強制トンネリング下でのKMSの通信、通信経路、それに係る対処策について記載しました。
情報発信というよりかは、自分が忘れないためのアウトプット要素が強いですね。
以上です。