F5のルートドメインとMPLS VRF:テナントの受け渡しを整理する
2つのテナント、1つのアドレス、2つのルートドメイン。各オブジェクトを%IDで固定し、プロバイダーのVRFとルートターゲットを使い、テナントごとに個別に検証します。
二つのテナントが同じアプリケーションを10.50.0.10で実行しています。プロバイダーはそれらを別々のMPLS VPNに分け、BIG-IPはそれぞれのローカルトラフィックを別々のルートドメインに保ちます。この構成は受け渡しの地点まで機能しますが、そこでは接尾辞の欠落やルートターゲットのコピーによって、一方のテナントのパケットが静かに他方のコンテキストに入ります。本手順書は二つのモデルを結び付け、テナントごとのテストで終わります。
ワークシート:テナントごとに一行
何かを変更する前にこれを埋めてください。以降の各手順はこのシートのセルを参照し、空のセルはまだ誰も決めていない判断を意味します。
| Tenant | BIG-IP side | Provider side |
|---|---|---|
| A | VLAN or tunnel, route domain, self address, virtual server | VRF, attachment, route targets for import and export |
| B | Separate VLAN or tunnel, separate route domain, separate self address | Separate VRF, separate route targets |
手順1:各オブジェクトをルートドメインに固定する
F5のルートドメインのドキュメントは、分離されたトラフィックコンテキスト、重複アドレス、設定オブジェクトのaddress%ID表記について説明しています。10.50.0.10%2として書かれたアドレスはローカルのルートドメインコンテキストを指し、その接尾辞は顧客のIPパケットで運ばれるMPLSラベルではありません。
ドキュメント上のモデルでは、VLANまたは対応トンネルは一つのルートドメインに属するため、インターフェースとアドレスは一致する必要があります。管理パーティションのデフォルトルートドメインも確認してください。接尾辞を省略してもコンテキストがないわけではなく、パーティションがデフォルトで使うコンテキストを意味するからです。この単一のデフォルトが、新しいオブジェクトが静かに誤ったテナントで応答したほとんどの事例を説明します。自分のアドレスを追加する前に確認してください。
tmsh list net route-domain
tmsh list net vlan | grep -i domain
tmsh list ltm virtual one_vs
手順2:プロバイダーのVRFとルートターゲットを使う
MPLSのエッジでは、テナントはプロバイダーのVRFと合意済みの顧客ルーティングサービスによって識別されます。ルートターゲットはプロバイダーがVRF間でどのルートをインポートおよびエクスポートするかを制御し、似たようなBIG-IPのルートドメイン番号を選んでもその関係は何も生まれません。
二つの識別子は異なるシステムに存在し、異なる意味を持ちます。ルートドメインIDはアプライアンス上のローカルなコンテキストです。ルートターゲットはルート配布を決めるプロバイダー側のポリシー属性であり、ルート識別子はさらに三つ目のもので、それ以外は同一のプレフィックスを区別して保つために使われます。
手順3:コンテキスト間で到達性を共有するかを決める
親ドメインの参照と厳密な分離の設定を意図的に見直してください。これらはコンテキストが到達できる範囲を変えるからです。F5のガイドはこれらの関係を通じた制御された転送を認めており、まさにそのためルートドメインを単独で完全なテナントセキュリティポリシーとして扱うべきではありません。
両方のテナントが共有サービスを必要とする場合は、一方のテナントを何気なく他方のルーティングコンテキストに向けるのではなく、承認された経路と権限を指定してください。アプリケーションの識別情報と、意図的な送信元変換があればそれをネットワーク宛先とともに保持してください。そうしないと共有サービスは一方のテナントを他方として見てしまいます。
通常のルーティングによる受け渡しは、BIG-IPをMPLS PEにすることなく、BIG-IPをプロバイダーのエッジルーターに接続します。MPLSまたはVPNルートファミリーの直接統合が本当に必要な場合は、正確なプラットフォームとリリースについて明示的なサポートを得てください。ローカルのルートドメイン分離はその機能を確立しないからです。
手順4:一度に一つのテナントを検証する
テナントAを、Aのコンテキスト内のエンドポイントからAのアプリケーションアドレスまでテストし、次にBについて繰り返します。診断では%ID形式を使い、どのコンテキストが応答したかを証明できるようにし、誤ったコンテキストからの要求がもっともらしい場所に着地するのではなく失敗することを確認します。
同じ工程でプロバイダー側も確認します。プレフィックスが正しいVRFにあり、ルートターゲットがワークシートと一致し、戻り経路が意図した接続を使っていることです。アプライアンス自体から通るpingはアプライアンスのコンテキストを証明するもので、テナントのものではありません。
最終的なマッピングをワークシートに記録します。各パーティションのデフォルトルートドメインと、有効にした親ドメインの関係を含めます。この環境に対する次の変更は、この記事を読む人ではなく、その表を読む人が行います。