GatewaySubnetに0.0.0.0/0のUDRを無理やりアタッチしてAzure上での強制トンネリングを実現する

※多分非サポート

背景

• 前回からのおまけの検証
  • プロキシがあればHTTP系の通信はオンプレから出せるよねって検証をした
  • 結局プライベート空間の話で強制トンネリングの構成は実質影響していなかった
  • 本来の強制トンネリングの検証をしたいって話

https://zenn.dev/microsoft/articles/5ae86e212203ae

• オンプレを模したVNET側のVPN Gatewayのデフォルトルートに対するネクストホップをAzure Firewallに向けることで、プロキシ云々を抜きにしてオンプレのアプライアンスですべての外向き通信をコントロールする環境を作れるのか気になった
• そもそもの制限として、GatewaySubnetにはデフォルトルートのUDRの含まれるルートテーブルを付与できない

構成

• 追加検証用に新たにプロキシ設定をしていないWindows VMをデプロイ
• オンプレ側にもアプライアンスを想定したAzure Firewallをデプロイ
  • アプリケーションルールでhttp/sを許可
• オンプレ側VPN Gatewayの次ホップをそこに向けるためのルートテーブルをどうするか、っていうのが本記事の話
• 下記画像で赤線の通信をしたい

チャレンジ①：0.0.0.0/1と128.0.0.0/1に分割

• これであれば無理やり感があるがサービスとしての制約は回避できる
  • 確かにGatewaySubnetにアタッチができた

問題

• なんか様子がおかしい
• 本来NIC側で見えているはずの次ホップ:仮想ネットワークゲートウェイのルートが消えている

結果

• そもそもVPNの接続が切れていた
• どうやら、デフォルトルートをすべてオンプレ側のAzure Firewallに向けてしまったことでオンプレ側VPN Gatewayが対向のVPN Gatewayとピアを張れなくなり、接続が切れた

チャレンジ②：①にVPNピアIP->Internetを追加

• これなら、VPNの接続を失わずに経路制御できそうだ
• ということでルートを追加した

結果

• うまくいった(左: Azure FirewallのPIP、右: クラウド側Windows VMから確認君にアクセスしたアドレス)
  

おわり

• これでAzure Route Serverを使わずに(無理やりに)強制トンネリングをAzure上で実現することができたと言える(?)
• HTTP系以外の通信も含めてオンプレ側FWで制御する必要がある場合の検証環境の構成として覚えておきたい所存