Azure案件にアサインされました。
その中で、どうやらルーティングによってリソースへのアクセスを制御する必要がありそうです。
そこで今回は、VPN (P2S)でつないだオンプレからのアクセスをVnet間で転送する検証をしたいと思います。
概要
手書きの絵で大変恐縮ですがネットワーク構成はこちらです。
Vnet間はピアリングで通信できるようにします。
問題はVPNゲートウェイの向こうのオンプレからの通信です。オンプレとVnet-Aは問題なく通信できるでしょうが、Vnet-Bと通信するにはどういった設定が必要でしょう。ここについて検証していきます。
作業
VPNゲートウェイはデプロイに時間がかかるので、先に作ります。
Vnet-Aにゲートウェイ用のサブネットを作り、VPNGW1で十分なので作成。
待ってる間に仮想マシンをVnet-AとBにUbuntuの一番小さいサイズで作成。ともにパブリックIPは付与せずにやります。
VPNの構成については、オンプレ側のアドレスプールは構成図通り10.2.0.0/16にして、やることやります。
(いつも思うんだがやり方あってるんだろうか・・・）
経路の確認
VPNでオンプレとVnet-Aをつなげた時点での経路情報を見ておきます。
VM-Aに接続されたネットワークインターフェイスから、有効なルートを確認します。
VPNゲートウェイがデプロイされたことで、10.2.0.0/16のアドレス空間には、ゲートウェイに送るような経路情報がテーブルに載りました。
VM-Bを確認します。
こちらにはゲートウェイの情報がありません。これは10.2.0.0/16にはいけなさそうです。
また、A、Bのどちらにも互いに通信するための経路情報はないようです。デフォルトでVnet間の通信はできないようになっています。
なお、オンプレ側では10.2.0.2 が与えられています。
疎通確認
オンプレからVM-A（10.0.0.4)とB（10.1.0.4)にpingを打ってみたところ・・・
この通り、Aには通ってBには通りません。
VM-AからBにpingしても通じません。
Vnet間の通信もできていないので当然です。いまのところVnet-Bはオンプレとは無関係です。
ピアリング
手始めに最小限の設定でピアリングしてみます。
経路情報の確認・疎通確認
経路情報にピアリングが登場しました。
VM-AにSSHして、VM-Bに通じてるか確認しましょう（ピアリング前にやるのを忘れた）。
はい、疎通確認できました。Vnet間の通信ができるようになりました。
それではオンプレとVM-Bとは？？
通じません。経路情報には10.2.0.0/16がないのでそうでしょう。
ゲートウェイ転送
ピアリングの設定にゲートウェイ転送というのがあるのでそれをするとよいそうです。https://learn.microsoft.com/ja-jp/azure/vpn-gateway/vpn-gateway-peering-gateway-transit
注意点としては、ピアリングするVnetの双方で設定をすることです。今回VPNゲートウェイがあるのはVnet-Aの方であることに注意して設定します。
Vnet-Bのほうでも設定が必要です。
ちなみにピアリングの設定には少しばかり時間がかかるようです。１分くらい
さて、経路情報はどうなっているでしょうか。VM-Bの方で確認します。
仮想ネットワークゲートウェイの経路情報が登場しました。※※※
それではオンプレからVM-Bに疎通確認
できません。どうしてだろう
経路情報の追加
オンプレでroute printしたところ、こうなってました。
10.1.0.0/16 (Vnet-Bのこと）への経路情報がありません。
なので一番上のデフォルトルートに飛んでます。これはVPNの入り口ではありません。したがってVM-Bには到達できません。
powershellを管理者権限で開いて、
route add 10.1.0.0/16 10.2.0.2
を実行し、経路情報を追加します。
疎通確認すると、
右が経路情報を追加した後のping結果です。疎通がとれました。
これで、vnetをまたいでオンプレが通信できました。
検証は終了です。お疲れさまでした。
あとがき
※※※のところで、VM-Bから10.2.0.2にping打っても返らなかった。VM-Bからゲートウェイは見えているのでオンプレには届いていると思うが、pingの往きで経路を覚えないということか？？