IaaSにおけるルーティング

Microsoft Azure のIaaS環境におけるルーティングとして、オンプレミスと比較すると実はあまり設定箇所がない。強いて挙げるなら

* UDR(User Defined Route:リソースはルートテーブル)による静的ルート設定
* VPN GatewayやVNET間のピアリングによる経路広報
* Service Endpoint設定による、特定SaaS/PaaSに対する経路広報

ぐらいなのかな。そこにIGPなんかは気持ちいいぐらい入ってこない。

こうした設定の結果、VMなどにはどういう経路が広報されているのかを知ることが出来る。「有効なルート」と言う設定で、例えば以下のようなことが確認できる。

有効なルートで見えるもの

システムルート

どんなVMやIaaSコンポーネントにも採用されるデフォルトのルーティング設定であり、具体的な内容としては

* デフォルトルートはインターネットへ向いている
* プライベートアドレスに関しては、原則ブラックホール行き
* CGN用プレフィックスも基本的にはブラックホール行き
* 同一VNET間の通信はVNETを伝わってどこにでも行ける(仮想ネットワーク)

というのが書かれている。優先度は低く、カスタムルートなどで指定されていない場合はこのルートが原則採用される。

動的ルート

VPN GatewayやVNET Gateway(Express Route Gateway)、VNET Peeringによって広報される経路が適用される。その機能名などから恐らくBGPが使用されてるんだろうなーと思われるんだけど、詳細はわからない。

なお、Service Endpointなどの定義によって定められるルーティングに関しても、この動的ルートのカテゴリに含まれる。

User Defined Route(UDRまたはカスタムルート)

ユーザが「ルートテーブル」リソースを使用して定義するカスタムルーティングテーブルを指す。UDRは「カスタム定義ルート」の列に定義したルートテーブルリソース名が付与される。

ルートの反映

ルートの反映を行うにあたり、その優先度は以下のようになる。

* ルーティングの大原則(ロンゲストマッチ等)にまずは従う
* 情報の優先度は「カスタムルート＞動的ルート＞システムルート」

VNETを少しだけ紐解いてみる

サーバ側のコマンド結果から、こうではないかと。

まず、VNET内のサブネット上のサーバにIPアドレスを動的で付与すると、かならず第4オクテット4から順にIPアドレスが払い出される。サーバ側でip rコマンドを打ってみると、上図のように第4オクテット１のアドレスがデフォルトゲートウェイとして定められている。

どうやらこれがVNET単位で配置されている、隠れたL3デバイスのようだ。そしてarpテーブルを覗いてみると、面白いMACアドレスがゲートウェイに対して割り当てられてるのが見受けられる。

12:34:56:78:9a:bc

なんだこれわ。こんなのみたことねぇ、ってか恐らくはソフトウェアが払い出してるMACアドレスなんだろうなーと言うのは容易に想像がつく。この時点でAzureのネットワークは何かしらSDN(Software Defined Network)的なものが動いてるんだろうなーと言う推測はできる。

L2フレームの渡し方が面白い

tracerouteをこの環境で実行した人はわかると思うのだけど、tracerouteを実行してみると、びっくりするほどホップ数が少なくて驚く。本当にまともにパケットは授受されてるのか？と疑わしくなる。

そこで、tcpdumpを使用してフレーム送受信の動きを見てみた。
異なるVNET間でSSHを張ったときの通信において、片方のフレームのやり取りを眺めてみたのがこれ。

VNET間の通信で面白いところを見つけた

なんと、応答パケットの一部に関してVNET間の仮想サーバ同士が「フレームを直接」やり取りしとる。これが本当の動きなのかどうかはさておき、こりゃ面白いなーと思いながらその時は眺めてた。

普通のオンプレミス的なフレームのやり取り

こんなふうに、ルーターなりL3スイッチなりが一旦フレームを受け止め、IP層の情報に従い、ARPテーブルを確認しながら相手へそのデバイスがフレームを送信する。

そんな中でダイレクトにフレームを投げつける仕組みがあるのは、通信の効率化を狙ってるからだろうか？と思った。

インタフェースは、ひとつ

例えばこんなこと

IaaSパーツ(特にLB系)の構成

普通、LoadBalancerなんかを組む際は、InterfaceがWAN/LAN双方１つ以上存在しており、異なるセグメントにまたがる形で接続するケースが多い。しかし、Azure IaaSで使用されるLoadBalancerやApplicationGatewayなどでは、上図右側の構成を基本的にはとっている。

つまりはワンアーム構成が基本だということ。そして、外部に出るときはシステムルート設定に従い、Public IPが適用されたDNATを越して外部に出る。当然その内部セグメントにカスタムルートを組めばVPN越しにオンプレミスネットワークへ届かせることも可能だったりする。

ここで要注意なのがNSG(Network Security Group)というパケットフィルタで、NSGはあくまでVNET及びその配下のサブネットに入ってきたパケットを監視する。つまりは内部セグメントのアドレスをベースに設定を考えなければならない。

Public IPをベースにルールを書いても、DNATで変換されたあとのパケットしかVNET上には流れないので、それは意味がないということになるので要注意。

VNETの不思議

VNETには色々不思議なところがあって、こんな特性があるそうな。

* Unicast通信が前提であり、Multicast/Broadcastは不可
* アドレスは動的/静的関係なくDHCP配信が前提。固定IP設定をサーバOS側でやると疎通不達状態になる
* Public IPを定義した場合、サーバ側にインタフェースがつくのでなく、ゲートウェイ側で以下の2つが付与される。つまり、内部インタフェースには何も手を加えない。

* インターネットに対するアクセス許可の付与
* Public IP で受け付けたパケットを該当するサーバで受け止めるためのDNAT設定

このあたりは、Azure Network Fabricというネットワークインフラが支えているようで、正直詳細はよくわからないのだけど、もしかしたらAzure Stackを組んでるTwitter界隈とかだと内部の仕組みをもう少し理解していらっしゃるのだろうか・・・

ExpressRouteについて

まず個人では絶対に触れることはないのがExpressRouteと言う専用線接続サービス。専用線と言うと基本的には閉域網を構成するために利用するケースが多いと思うのだけど、その目的を果たすためだけにこれを採用するケースが有るのなら少し考え直したほうが良いのかもしれない。

というのも、Microsoftが提供しているクラウドサービスの大半が「インターネットのアクセス併用」が大前提になっているから。強いて挙げれば、Azure IaaSにおいて、そのIaaSパーツ間の通信、VMへのアクセス、VM上に構成したシステムへのアクセスは閉域化できるかもしれないが、例えばAzure Portalのような管理サイトは恐らく表示が崩れる。

原因はMicrosoftが提供するクラウドサービスの大半でCDNが動いていること。CDNとはいわゆるコンテンツキャッシュサーバの集合体で、Microsoft社独自の部分もあるとは思われるが、結構な割合をAkamaiが占めており、その経路はインターネット上にしかない(Akamaiを使いまくってるのは結構前から有名なお話)

なので、アクセス経路を完全閉域にすると、ページの画面表示が崩れたりしてまともに扱えない状態になる。それが故、ここ最近クラウドソリューションの一つとして「インターネットブレイクアウト」なる仕組みが使われるようになってきてるのかなーと思う。

ただ、CDNに関しては結構動的制御で動いてるところもあり、これを完全に把握して動かすのは難しいと思われる箇所もあって、その運用方法については色々検討が必要なんじゃないかなーって感じる今日このごろ。

なんかエミュレーション的な回線でもいいから、個人でこれを試行出来るような代物ってないのかねー・・・ぶつくさ。

我が家での構成例

最大でこんな感じの構成を組んでた。

Azureリソースの中で非常にありがたいのは、やっぱりVPN。P2SやS2SがBasicでも比較的自由に張れて、お値段が月間3,000円前後で済むのはまさにサプライズプライスだと思ってる。

さて、これに複数のサブネット、複数のVNETを構成して、VNET Peeringで経路共有をするよう構成している。経路はトランジット出来るようにしていて、試験用IDS VMが配置されているセグメントからも、VPNをたどってオンプレミスセグメントへ行けるよう構成している。

今回この記事を書くに至った要因として、2台のVM間で通信させてみたら、予想と違った通信がちらほら発生したことなんだけど、そうした事象に気づくことで、セキュリティ面であったり、ネットワーク面であったり、色々新しいことを覚える機会になると思うので、是非とも取り組んでみることをおすすめしたいなと。

別に完璧におぼえる必要はなくて、その中にある程度の推測は混じってよいのだろうと思う。もし情報があればそれに基づいて正しく訂正すれば済む話だし、Azure自体奥が深すぎて、個人で攻め込むには限界があるので。