UDR は OS には効かない
Advent Calendar
こちらの記事は Microsoft Azure Advent Calendar 2023 の 12 日目の記事です！
TL;DR
- Azure VM の OS には UDR は効きません
- なぜ ARS がないと ExpressRoute と VPN の折り返しができないのか
- なぜ 強制トンネリングは UDR では実現できないのか
Update log
- Advent Calendar へのリンク追加と参考リンクの追加 - 2023/12/18
はじめに
先日 Cloud Lab で検証を進めていたのですが、なかなかうまくいかなくて今どういうルーティング構成になっているかを改めて考え直すと意外とシンプルな話だった、というのがありました。
User Defined Route (UDR) は Azure VM の OS には効かない、というのはまぁそうだね、という話でしかないんですが、意外と分かりづらいというか、Azure の Software Defined Network (SDN) を理解するにあたって重要なことだと思うので説明してみます。
どのルーティング テーブルにどのような経路が入っているか
を意識したことはあるでしょうか。
Azure の検証を進める中で、うまくいかない、通信できない、意図どおりにつながらない、となったときに確認すべきものの 1 つが Azure VM の Effective routes (有効なルート) です。
これは、VNet のアドレス空間や UDR、ExpressRoute や VPN の BGP、ARS を経由して Network Virtual Appliance (NVA) から挿入されたものなど、さまざまなコンポーネントから受け取った経路の一覧およびその結果どの経路を優先して利用するか、という情報を確認できます。
なのですが、じゃあ UDR を書いたところで Azure VM の OS の中に入って「route print (に相当する経路の表示コマンド)」を実行したところでその内容は反映されていません。
これは非常に大事なことを示しており、逆に Azure VM の中で static route (静的な経路) の追加「route add (に相当する静的な経路の追加コマンド)」を実行する機会はほとんどない、意味がない、ということにつながります。
再度繰り返しますが、Azure VM の中のルーティング テーブルと、Azure VM の外のルーティング テーブルにあたる Effective routes を区別して確認することが Azure のネットワーク技術である SDN を理解するのに非常に重要です。
ARS がないと ExpressRoute と VPN の折り返しができないのはなぜか
上記内容がしっかりと理解できてくると、ARS がないと ExpressRoute と VPN の折り返しができない、ということが理解できます。
いったん、ARS がある時の BGP による経路広報の流れをおさらいしておきます。
- VPN 接続先にあるルータは、たとえば自分の connected な経路を BGP で経路広報します
- 接続先のルータから BGP で広報された経路を VPN Gateway が受け取り、VPN Gateway の OS (内部的に何の OS が使われているかはここでは関係ないですね) のルーティング テーブルに入ります
- 続いて、該当の経路は VPN Gateway から ARS に BGP で広報されます
- その経路は ARS が BGP で受け取り、ARS の OS のルーティング テーブルに入ります
- (ついでに、ARS が BGP で受け取った経路は mysterious technology により VNet に反映されます、どうやってるんですかね、気になります)
- 受け取った経路は次に ExpressRoute Gateway に BGP で広報されます
- その経路は ExpressRoute Gateway の OS のルーティング テーブルに入ります
- 続いてその経路は MSEE に対して BGP で広報され、MSEE の OS (ここは Cisco とか Juniper とかじゃあないでしょうか) のルーティング テーブルに入り、若干はしょりますが、そのままその対向にあたる Customer edge に対して該当の経路を広報します
- Customer Edge がいろいろあって結局 VPN の拠点側の経路を知ることによって、ExpressRoute 拠点の Client からの通信を正しく Customer Edge から MSEE 経由で VNet に流し、VPN で折り返すことができる
という流れになるわけです。
expressroute and vpn with ars achieving hairpin connection
じゃあ ARS がないとどうなるかというと、
- VPN 接続先にあるルータは、たとえば自分の connected な経路を BGP で経路広報します
- 接続先のルータから BGP で広報された経路を VPN Gateway が受け取り、VPN Gateway の OS (内部的に何の OS が使われているかはここでは関係ないですね) のルーティング テーブルに入ります
で終わってしまうわけですね、概念的には。
そうすると結果的には Customer edge まで VPN 拠点の経路が流れてこないことになってしまいます。
expressroute and vpn without ars
もちろん、Customer edge だけの話であればそこで「ip route x.x.x.x/x <MSEE の IP アドレス>」などで static route を入れればいいだけではあるんですが、MSEE はその経路を知りません。
また、MSEE に対してはその内部的なルーティング テーブルにエントリーを追加する方法は BGP しかありません。
ExpressRoute Gateway に対して任意の NVA から BGP neighbor を張れる方法があればいいのですが、それはそれでセキュリティ云々の関連からできない、ということになり、そのための中継・連携用のコンポーネントとして ARS がある、ということになります。
expressroute and vpn without ars and static route
ここまで書いておいてなんですが Microsoft の docs にもそういうようなことが書いてあります。
expressroute and vpn with route server
ExpressRoute と Azure VPN に対する Azure Route Server のサポート - それはどのように機能しますか?
ExpressRoute を使った強制トンネリングは UDR では実現できない
いやできる、という意見もあるのもわかりますが、いったんそういう込み入った面倒くさい運用どうするんだよみたいな構成は忘れてください。。
強制トンネリング、なんとなく UDR で 0.0.0.0/0 を Virtual Network Gateway に向けたのを subnet に関連付ければいいじゃん、みたいな発想が出てくると思うんですよね。
ここで上記内容をしっかり理解していると、「UDR を書いたところでそれが ExpressRoute Gateway の内部的なルーティング テーブルには入らず、つまりそれは MSEE にも広報されないし、MSEE にとって 0.0.0.0/0 が Customer edge から広報されていると認識していなければそちらに packet を投げることもない」という流れで理解できます。
forced tunneling udr
まとめ
いかがだったでしょうか、言葉でいうと簡単ですが、「UDR は OS に効かない」ということ、じっくりご理解いただけたでしょうか。
Azure の SDN を理解する上では非常に大事な概念というか、conventional な L3 ネットワークをもとに VNet を理解しようとしてなんども躓いた結果あたしもこの理解にたどり着いた、というところです。
逆にパブリック クラウドしか知らない、という方であればまぁそうだよね、とシンプルに理解できるのかもしれませんが、逆に conventional なネットワークに強いエンジニアこそ躓くポイントかと考えています。
参考
- Zenn で本書いているのでこちらもどうぞ！
- 同僚の書いた記事も併せてどうぞ！
- こちらは英語の記事です！すごい！！
Discussion