Virtual WAN のルーティングと向き合う(ExpressRoute のトランジット接続)

azure
Published: 2024-03-09

はじめに

Virtual WAN にはトランジット接続の機能があり、次の通信を実現できます

  • Virtual WAN に接続する VNET 間の通信
  • Virtual WAN に接続する VNET と ExpressRoute 回線間の通信
  • Virtual WAN に接続する VNET と S2S VPN 間の通信
  • Virtual WAN に接続する VNET と P2S VPN 間の通信
  • Virtual WAN に接続する S2S VPN 間の通信
  • Virtual WAN に接続する S2S VPN と P2S VPN 間の通信

グローバル トランジット ネットワーク アーキテクチャと Virtual WAN

一方で素直な実装で実現できないのが ExpressRoute 回線間の通信です。単に2つの ExpressRoute 回線を1つの Virtual WAN に接続しても、2つの ExpressRoute 回線は Virtual WAN で折り返す形で通信できません。

ExpressRoute 回線のトランジット接続を実現するためには、次のいずれかで対応する必要があります。

  • ExpressRoute Global Reach
  • Virtual WAN ルーティングインテントのプライベートポリシー

ルーティング インテントを使用した ExpressRoute 回線間のトランジット接続

前者は Virtual WAN とは関係のない ExpressRoute の機能です。参考:Express Route Global Reach を試した

後者のルーティングインテントを利用した ExpressRoute 回線のトランジット接続を試す機会があったので、検証してまとめました。

検証環境

1つの Virtual WAN に Azure VMware Solution と自前の ExpressRoute 回線を接続します。自前の ExpressRoute 回線には OCI の FastConnect と VNET を接続します。

検証環境のイメージ

各地点のアドレス帯は次の通りです。

  • AVS:10.10.0.0/24 と 10.11.0.0/24
  • オンプレ:172.16.100.0/24
  • Virtual WAN:172.16.0.0/24
  • 仮想ネットワーク:172.16.50.0/24

挙動

ExpressRoute Global Reach は、2つの ExpressRoute 回線が経路を直接交換し合うことでトランジット接続を実現します。そのため、通信は ExpressRoute で折り返す形となり Virtual WAN には届きません。

Global Reach によるトランジット接続のイメージ

ですが、ルーティングインテントによるトランジット接続は ExpressRoute 回線同士が経路を直接交換しません。Virtual WAN から 2つの ExpressRoute 回線に対して次の経路を広報してトラフィックを Virtual WAN 内の Azure Firewall に引き付けることで、Virtual WAN 内の Azure Firewall 経由での通信を実現します。多少強引な感じはしますね…

  • 10.0.0.0/8
  • 172.16.0.0/12
  • 192.168.0.0/16

ルーティングインテントによるトランジット接続のイメージ

設定

Virtual WAN 内に Azure Firewall を用意した上で、ルーティングインテントのプライベートポリシーを有効化します。

ルーティングインテントの設定画面

また、Azure Firewall 経由でのトランジット接続になるので、必要な通信を許可する必要があります。今回はネットワークルールで全通信を許可します。

Azure Firewall の設定

さらに、Microsoft のサポートに連絡をして、トランジット機能を有効化してもらう必要があります。機能を有効化してもらうまで、3つのプライベートアドレス帯の経路は広報されません。

プライベート ルーティング ポリシーを使用してハブ内のファイアウォール アプライアンス経由で ExpressRoute から ExpressRoute へのトランジット接続を有効にするには、Microsoft サポートでサポート ケースを開いてください。 このオプションは Global Reach と互換性がないため、Virtual WAN に接続されているすべての ExpressRoute 回線間の適切なトランジット ルーティングを確保するには、Global Reach を無効にする必要があります。

ルーティング インテントを使用した ExpressRoute 回線間のトランジット接続

せっかくなので、ルーティングインテントのインターネットポリシーも有効化して、Virtual WAN 上の Azure Firewall 経由でインターネットにアクセスできるようにします。Virtual WAN から ExpressRoute 回線に対してデフォルトルートを広報するかどうかは ExpressRoute 回線ごとに選択できるので、今回は D-MSEE 側にはデフォルトルートを広報しつつ、MSEE 側にはデフォルトルートを広報しないことにします。

デフォルトルートを広報する設定

動作

それでは各地点のルーティングを確認します。ルーティングインテントの方式の最大のポイントは、前述した通り ExpressRoute 回線同士が経路交換しない点です。従って、自前の ExpressRoute 回線が D-MSEE 側に存在する経路を学習することはありません。逆もまたしかりです。

そのため、MSEE のルーティングテーブルに、D-MSEE が AVS から学習している 10.10.0.0/24 と 10.11.0.0/24 は存在しません。その代わりに、Virtual WAN が広報する 10.0.0.0/8 と 172.16.0.0/12、192.168.0.0/16 の集約されたルーティングが存在します。また、MSEE 側には Virtual WAN からデフォルトルートを広報していないので、デフォルトルートが存在しない点もポイントです。

MSEE のルーティングテーブル

当然、オンプレミスには MSEE が学習した経路が広報されるので、AVS の経路は存在せずプライベートアドレス3つの経路のみを学習します。

FastConnect のルーティングテーブル

MSEE に接続している普通の仮想ネットワークも同じように経路を学習します。仮想マシンの有効なルートを見ると、プライベートアドレス3つの集約された経路のみを学習していることが分かります。AVS の経路は存在しません。

FastConnect のルーティングテーブル

当然ですが、通信をトランジットする Virtual WAN のルーティングテーブルには、D-MSEE から学習した AVS の経路と MSEE から学習した OCI と普通の VNET の経路が存在します。

普通の VNET のルーティングテーブル

「ExpressRoute なのに集約されたルートが聞こえてくる」という今までにないパターンで少し戸惑いますが、ルーティングは整っているので、通常のハブ上の仮想マシンから AVS 上の仮想マシンに対して MSEE と Virtual WAN 、D-MSEE を経由して通信できます。

普通のハブ上の仮想マシンから AVS 上の仮想マシンの TCP3389 に疎通確認

注意点

「集約されたルートで通信を実現する」という実装の都合上、集約されたルートをネクストホップの異なる別のルーティングで上書きしたりや経路をフィルタリングして受け取らなくすると、トランジットな通信ができなくなります。今回の検証環境の場合、オンプレ側の WAN ルータに「10.0.0.0/8 のネクストホップは基幹 L3 スイッチ」といったルーティングを書いてしまうと、WAN ルータ上に AVS に到達するためのルーティングがなくなってしまうので、オンプレと AVS は通信できなくなります。

また、MSEE に普通の VNET を接続するような構成の場合には、オンプレミスから ExpressRoute 回線に対して広報する経路も注意が必要です。今回の場合、Virtual WAN 経由のトランジット接続のためには、ExpressRoute 回線上の 10.0.0.0/8 のネクストホップは Virtal WAN になっている必要があります。今回の構成でオンプレミスからも 10.0.0.0/8 を広報してしまうと、ExpressRoute 回線は vwan とオンプレから広報される2つの 10.0.0.0/8 のいずれかをベストパスとして採用します。結果として、ベストパスとして採用されなかった 10.0.0.0/8 とは通信できなくなります。

この動作を避けるためには、プレフィックス長が長い具体的な経路を広報する必要があります。例えば今回の構成で AVS で利用している 10.10.0.0/16 と 10.11.0.0/16 以外の 10.0.0.0/8 のアドレス帯をオンプレミスで利用している場合には、次のように AVS のアドレス帯を避けて集約した具体的な経路を、オンプレミスから ExpressRoute 回線に対して広報する必要があります。

  • 10.0.0.0/13(10.0.0.1-10.7.255.255)
  • 10.8.0.0/15(10.8.0.1-10.9.255.255)
  • 10.12.0.0/14(10.12.0.1-10.15.255.254)
  • 10.16.0.0/12(10.16.0.1-10.31.255.254)
  • 10.32.0.0/11(10.32.0.1-10.63.255.254)
  • 10.64.0.0/10(10.64.0.1-10.127.255.254)
  • 10.128.0.0/9(10.128.0.1-10.255.255.254)

こうすることで、Virtual WAN から 10.0.0.0/8 が広報されている状況下でも、「10.0.0.0/8 の中のより長いアドレス帯はオンプレミスに向かう」「10.0.0.0/8 の中で長いアドレス帯に該当しない残りの部分(今回の場合は AVS)は Virtual WAN に向かう」という制御が可能になります。

まとめ

Virtual WAN を利用して ExpressRoute 回線のトランジット接続を実現する方式の1つである Virtual WAN ルーティングインテントのプライベートポリシーを試しました。Virtual WAN が ExpressRoute 回線から学習した経路を 別の ExpressRoute 回線に再広報できないのを解決するために、集約した3つのプライベートアドレスの経路を ExpressRoute に広報するというワイルドな実装なので、オンプレミス側での考慮事項がとても多いです。素直に Global Reach を採用したほうが良いと思います。

Note

  • 当サイトは個人のブログです。このブログに示されている見解や意見は個人的なものであり、所属組織の見解や意見を表明するものではありません。
  • 公開情報を踏まえて正確な情報を掲載するよう努めますが、その内容の完全性や正確性、有用性、安全性、最新性について一切保証しません。
  • 添付文章やリンク先などを含む本サイトの内容は作成時点でのものであり、予告なく変更される場合があります。