先日とあるコミュニティイベントで執り行いました資料なしホワイトボードに殴り書きと言うライトニングトークの内容をまとめてみました。
ネタは Azure ネットワークルーティングのプラクティス、都合3回でお送りいたします。
3. ロンゲストマッチと優先順位の絡んだルーティング
第 3 回はロンゲストマッチと優先順位の絡んだルーティングについてです。
ロンゲストマッチ (最長プレフィックス一致) の原則
ネットワークルーティングにはロンゲストマッチ (Azure では最長プレフィックス一致と呼称) の原則と言うものがあります。
これは複数のルート候補がある場合 IP アドレスのビット列で最も長く一致するプレフィックスを持つルートが優先されるという原則で、Azure ネットワークでもまずはこの原則に沿ってルートが選択されます。
例えば宛先が192.168.1.10 へのルートを選択するにあたって、
| プレフィックス | ネクストホップ | 一致長 | |
|---|---|---|---|
| 1 | 192.168.0.0/16 | 192.168.0.1 | 16bit |
| 2 | 192.168.1.0/24 | 192.168.1.1 | 24bit |
| 3 | 192.168.1.8/29 | 192.168.1.9 | 29bit |
と言うルート候補が存在した場合、最長の一致長を持つ 3 がルートとして選択される動きとなります。
プレフィックスが一致した場合のルーティングの優先順位
ロンゲストマッチの原則の上でプレフィックスが一致するルート候補が複数存在した場合 Azure では、
- ユーザー定義ルート
- BGPルート (VPN の静的ルート含む)
2-1. ExpressRoute
2-2. VPN - システムルート
と言う優先順位でルートが選択されます。
ただし、
仮想ネットワーク、仮想ネットワークのピアリング、または仮想ネットワーク サービス エンドポイントに関連したトラフィックの場合はシステム ルートが優先されるルートです。BGP ルートの方が具体的な場合でも優先されます。
ネクスト ホップの種類が仮想ネットワーク サービス エンドポイントであるルートは、ルート テーブルを使用するしてもオーバーライドできません。
と言う例外がありまして、前者はユーザー定義ルートで上書き可能ですが後者はいかなる場合でもサービスエンドポイントが優先される動きとなります。
このあたりについては下記の Learn に記載がありますのでご参照ください。
具体例
では具体例として前々稿で取り上げました VPN と Azure Firewall が絡んだケースを見てみましょう、ユーザー定義ルートでは 192.168.36.185/32 へのネクストホップを Azure Firewall に指定しています。
この設定でネットワークインターフェースの有効なルートは下記のようになります。(一部を抜粋)
| ソース | アドレスのプレフィックス | ネクストホップの種類 | ネクストホップIPアドレス |
|---|---|---|---|
| 既定 | 192.168.253.0/24 | 仮想ネットワーク | - |
| 既定 | 192.168.250.0/24 | VNET ピアリング | - |
| 仮想ネットワーク ゲートウェイ | 192.168.36.0/24 | 仮想ネットワーク ゲートウェイ | 172.192.40.227 |
| 既定 | 0.0.0.0/0 | インターネット | - |
| ユーザー | 192.168.36.185/32 | 仮想アプライアンス | 192.168.250.68 |
選択されるルートはロンゲストマッチの原則によって、
- 192.168.36.185：一致長 32bit のルートがあるので Azure Firewall を経由するルート
- 上記以外の 192.168.36.0/24：仮想ネットワークゲートウェイのルート
- 所属する仮想ネットワークおよびピアリングされたネットワーク：仮想ネットワーク内のルート
- 上記すべて以外は：Azure 既定のインターネットへのルート
となります。
さてここまでは特殊な挙動を伴う構成ではありませんが、追加で 0.0.0.0/0 のネクストホップを Azure Firewall に向けるルートを入れてみましょう。
| ソース | アドレスのプレフィックス | ネクストホップの種類 | ネクストホップIPアドレス |
|---|---|---|---|
| 既定 | 192.168.253.0/24 | 仮想ネットワーク | - |
| 既定 | 192.168.250.0/24 | VNET ピアリング | - |
| 仮想ネットワーク ゲートウェイ | 192.168.36.0/24 | 仮想ネットワーク ゲートウェイ | 172.192.40.227 |
| ユーザー | 0.0.0.0/0 | 仮想アプライアンス | 192.168.250.68 |
| ユーザー | 192.168.36.185/32 | 仮想アプライアンス | 192.168.250.68 |
そうすると上記すべて以外へのルートは目論見通り Azure Firewall を経由しますが、192.168.36.0/24 についてはより一致長の長い仮想ネットワークゲートウェイのルートが選択され Azure Firewall を経由しません。
このようなケースにおいてユーザー定義ルートに関しては明示的に設定していますのでちゃんと考慮されるのですが、仮想ネットワーク ゲートウェイなど Azure にて自動的に設定されるルートは結構見落とされると言うのがポイントです。
オンプレミスとの通信も Azure Firewall で監査していたつもりが実は漏れていたということも起こりえますので注意が必要となります。
優先制御への適用
こちらは実機で検証した内容でありませんが、以前とあるプロジェクトで机上調査をしたことがありましたのでご紹介しておきます。
VPN で優先制御を行う場合通常 BGP を使うと思いますが、ロンゲストマッチを駆使した静的ルーティングで行うことも可能です、
と言っても難しいことはなく単一の VPN ゲートウェイに複数の接続をアタッチすることができますので、
| 接続 | ローカルネットワークゲートウェイ | アドレス空間 |
|---|---|---|
| Standard 回線 | StandardLGW | 192.168.0.0/24 |
| Premium 回線 | PremiumLGW | 192.168.0.0/29 |
と言う感じにすると特定のアドレス空間との通信を Premium 回線に回しつつ、Premium 回線が潰れた場合には Standard 回線に切り替えるようなことが可能になります。
おわりに
ロンゲストマッチの件はルートを書いても想定した経路を通ってくれないと言う事象で顕現することが多いと思います、より長いプレフィックスのルートがどこかに書いてある場合ですね。
あと優先制御のやつはパッと見ですごいわかりにくくく、構成管理をちゃんとしないとトラブルの元になります。
また 0.0.0.0/0 を絶対的なルートとして認識している方も多かったりしますので、知識としては持っておいて損はないかと思います。
さて App Service の VNet 統合などまだいくつかネタがありますが、連載と言う観点で一旦締めてまた次の機会でとさせていただきたいと思います
本稿を読んでいただきありがとうございました！