ポリシーベースのルーティング

ポリシーベースのルーティングは、ソース、アプリケーション、ユーザークラス、ポート、またはトラフィッククラスを考慮する可能性のあるポリシールールに基づいてネットワークトラフィックをルーティングします。これは、選択されたルートが主に目的地への最短または最も優先されるルートに基づいている従来のネットワークルーティングとは異なります。

ポリシーベースのルーティングは、パフォーマンスと信頼性の向上やセグメンテーションの実装など、さまざまな目標を達成するために使用できます。これらの決定はアプリケーションの識別に基づく場合があり、アプリケーションごとに非常に詳細なルーティングを可能にします。

主なハイライト

• ポリシーベースのルーティングは、目的地のみのルーティングを超えたルール基準を使用してトラフィックを誘導します。
• 基準には、ソース、宛先、ポート、プロトコル、DSCP、およびアプリケーションの識別（利用可能な場合）が含まれることがよくあります。
• 一部のプラットフォームは、ポリシーの意図とパスのテレメトリを組み合わせて、SLAベースの誘導をサポートします（例：レイテンシ、損失、ジッター）。これはPBRに関連していますが、従来のPBRには必須ではありません。
• PBRは一般的にアプリケーションクラス（例：リアルタイムコラボレーション対バルク転送）を好ましい出口ポイントまたはトランスポートに誘導します。
• 不適切に設計されたポリシーは、非対称ルーティング、不安定なフェイルオーバー動作、およびサイト間でトラブルシューティングが難しい結果を生む可能性があります。
• 成功したプログラムは、ルーティングポリシーを明確なルール順序、テスト、可観測性、およびロールバックを伴う変更管理されたロジックとして扱います。

ポリシーベースのルーティング

ポリシーベースのルーティングは、組織が特定の種類のトラフィックがネットワーク上でどのように移動するかを制御できるようにします。これは、トラフィックが目的地に向かう次のホップでどこに行くべきかを指定するポリシーとネットワークルールを定義することによって達成されます。

これらのルールは、パケット内のさまざまなフィールドを使用して、パケットをポリシーに一致させます。一般的に使用される一致フィールドには、次のものが含まれます：

• ソース/宛先
• ポート
• プロトコル
• DSCP
• アプリケーションカテゴリ

これらのフィールドに基づいて、トラフィックはポリシーにマッピングされ、トラフィックが取るべき次のアクションを指定できます。一般的なアクションには次のものが含まれます：

• 次のホップを選択する
• ネットワークを離れるために使用されるインターフェースまたは出口を選択する
• トンネルまたはトランスポートプロトコルを選択する
• ルーティングテーブルまたはVRFを選択する
• 明示的なフォールバックを持つパスを優先する（サポートされている場合）

ポリシーベースのルーティングは、トラフィックをどこにルーティングするかに焦点を当て、ファイアウォールやアクセス制御リスト（ACL）が許可/拒否ルールを実装できるようにします。ポリシーは、トラフィックが複数のルールに一致する場合の競合を解決するために、最初の一致が勝つという順序付きルールリストとして実装されることがよくあります。

ポリシーベースのルーティングは、ボーダーゲートウェイプロトコル（BGP）やオープン最短経路優先（OSPF）などのルーティングプロトコルではありません。また、トラフィックが利用可能なルートと帯域幅をどのように使用すべきかを定義するだけなので、ラストマイルの問題を魔法のように修正することはできません。

なぜ組織はポリシーベースのルーティングを使用するのですか？

ポリシーベースのルーティングは、従来の宛先ベースのルーティングよりも大きな粒度と制御を提供します。組織は、次のようなさまざまな結果を達成するためにそれを使用できます：

• レイテンシーに敏感なアプリのパフォーマンス向上
• レジリエンシーの向上
• 決定論的セグメンテーション
• コスト管理

従来のネットワークルーティングは、「すべてに合う1つのサイズ」のアプローチを取り、音声/ビデオ、SaaS、大容量バックアップ、管理トラフィックを同じように扱います。これらのために特定のポリシーを定義することにより、組織はより重要で敏感なトラフィックが適切に扱われることを保証できます。

ただし、追加のポリシーを定義および実装することは、追加の複雑さとオーバーヘッドをもたらします。ガバナンスとテストは、ポリシーが設計通りに機能し、ポリシーの数が制御不能に増加しないようにするために不可欠です。

ポリシーベースのルーティングはどのように機能しますか？

ポリシーベースのルーティングは、複数段階のプロセスを通じて機能します。主なステップは次のとおりです：

• トラフィックの識別と分類
• 一致フィールドの抽出
• 一致するポリシーを見つけ、最初のものを適用する
• 指定されたポリシーアクション（次のホップ、出口、トンネルなど）を適用する
• 必要に応じてフォールバックアクションを適用する
• ログまたはテレメトリを使用して成功を確認する

ポリシーベースのルーティングを実装するには、トラフィックをポリシーに一致させるために使用される条件を選択し、一致に応じて取られるアクションを定義し、ネットワーク全体でポリシーを強制する必要があります。

一致条件を定義する

ポリシーベースのルーティングは、トラフィックの宛先だけでなく、適切なポリシーを選択するためにさまざまな一致フィールドを使用します。これを実装する際の最初のステップは、適切なポリシーを選択するために使用される一致条件を定義することです。

ポリシーは、ソース/宛先、ポート、プロトコル、DSCPなど、さまざまな異なるフィールドを使用して一致させることができます。現代のシステムは、同じポートとプロトコル（443/HTTPS）を通過するトラフィックの大部分であっても、アプリケーショントラフィックに特定のポリシーを適用するためにアプリケーションクラシフィケーションにますます依存しています。基準を定義する際には、一貫したアイデンティティソース（アプリ、デバイス、ユーザー）が、企業WAN全体で一貫した強制を確保するために不可欠です。

ポリシーの一致基準を定義する際には、特定のパケットの一致数を制限するために、できるだけ相互排他的に保つことが賢明です。複数のポリシーが一致する場合、競合はルールの順序によって解決されるため、適切なポリシーがトラフィックに適用されることを確保するために、これらの優先順位を慎重に考慮することが不可欠です。

アクションを選択する（次のホップ、出口、トンネル、輸送）

ポリシーは、マッチングトラフィックに対してさまざまなアクションを取るように定義できます。一般的に、これらは2つの主要なカテゴリに分類されます：

• 決定論的アクション:トラフィックは、固定の次ホップ、出口、またはトンネルにルーティングされる場合があります。
• ポリシーと測定されたパス選択:SLAベースまたはアプリケーション認識型のステアリングをサポートするために、ポリシーベースのルーティングと測定されたパス選択を組み合わせます。

しばしば、ポリシーは、何かがうまくいかない場合に備えて、優先パスとフォールバックを定義します。ポリシーには、意思決定プロセスにおいて遅延、損失、ジッターに関するSLA閾値も含まれる場合があります。

ポリシーを定義する際には、ワークフローを壊す可能性のあるポリシーループを避けることが重要です。さらに、クラウドアプリのポリシーにおけるIPピンニングの使用は、脆弱性を引き起こし、IPアドレスが変更されるとポリシーを壊す可能性があります。

グローバルに強制し、結果を検証する

ポリシーベースのルーティングは、企業全体で一貫して強制されるべきであり、すべての環境で同じ意図、予測可能な動作、および測定可能な結果を確保します。スケールでポリシーベースのルーティングを実装する際のベストプラクティスには、以下が含まれます：

• 可能な場合は、デプロイ前にポリシーをテストするためにテストツールとシミュレーションを使用する
• 新しいポリシーの作成を管理するために変更管理ポリシーを実装する
• ステートフルトラフィック検査とトラブルシューティングに対する非対称ルーティングの影響を考慮する
• ポリシーの成功を評価する際に、パス選択率、SLA違反、およびフェイルオーバーイベントを監視する
• ポリシーベースのルーティングを段階的プロセスとして実装し、小規模から始めて慎重に拡大する

トラフィックステアリングのためにポリシーが使用すべき基準は何ですか？

ポリシーは、トラフィックをステアリングする際にいくつかの異なるタイプの基準を使用するべきです。直面する課題

• アイデンティティ（ユーザーとデバイス）
• アプリケーションまたはワークロード
• ネットワークデータ（ソース、宛先、およびポート）
• 品質（レイテンシ、損失、ジッター）
• DSCP（さまざまなタイプのトラフィックを識別するQoSマーク）

基準を定義する際には、広範な一致と狭い一致の間でバランスを取ることが重要です。広範な一致は実装が容易ですが、意図しないトラフィックを誤って誘導する可能性があります。狭い一致はリスクが低いですが、必要なルールの数が増加します。

ポリシーは、複数のポリシーがパケットに一致する場合に競合を解決するために優先順位を付ける必要があります。優先順位を定義する際の推奨順序は次のとおりです：

• ビジネスクリティカルなリアルタイム
• インタラクティブビジネスアプリ
• バルクおよびバックアップトラフィック
• ベストエフォート

ポリシーベースのルーティングの一般的なユースケースは何ですか？

ポリシーベースのルーティングは、意図に基づく誘導であり、トラフィックのニーズに基づいて特定のパスまたは出口を経由してルーティングすることを目的としています。一般的なユースケースには次のものが含まれます：

• リアルタイムアプリ:レイテンシ、損失、ジッターに敏感
• ビジネスクリティカルなSaaS:信頼性の高い接続が必要です
• バルクまたはバックグラウンドトラフィック:スループットを必要とするが許容範囲内
• セグメント化された制御された出口トラフィック:出口ポイントとルートは重要な考慮事項です

ポリシーベースのルーティングはトラフィックを特定のパスに誘導しますが、必ずしも特定の中間ホップを通過させるわけではありません。さらに、ポリシーは一般的にリンクの健全性も考慮し、優先リンクがSLAの閾値を下回った場合には代替パスにトラフィックをルーティングします。しかし、PBRを価値あるものにする同じユースケースがリスクも生み出します。重複する基準、一貫性のないルールの順序、非対称ルーティングは、ポリシーが慎重に設計されテストされていない場合、脆弱な結果を引き起こす可能性があります。

リアルタイムのコミュニケーションとコラボレーション

ポリシーベースのルーティングの一般的なユースケースの一つは、遅延に敏感なトラフィックのパフォーマンスと信頼性を向上させることです。例えば、音声およびビデオトラフィックは、ジッターや損失が通話品質に影響を与えるリスクを減らすために、最良の品質のパスに誘導されるべきです。しかし、トラフィックは通話中にガードレールなしで過剰に誘導されるべきではありません。そうすることでトラフィックが失われるリスクがあるためです。

ポリシーベースのルーティングは、優先順位付けを補完することもできます。この場合、このタイプのトラフィックは選択されたパス内で優先されることになります。

セグメンテーションと制御された出口

ポリシーベースのルーティングは、セグメンテーションと制御されたアクセスを実装するためにも使用でき、管理者、規制された、または敏感なワークフローが特定の検査ポイントまたは出口地点を通過することを要求します。例えば、特定のサブネットからのトラフィックは、他のサブネットに向かう途中で強制ポイントを通過する必要があるかもしれません。

セグメンテーションと制御された出口を実装する際には、戻りトラフィックが必ずしも同じパスをたどるわけではないことに注意することが重要です。さらに、このユースケースは、名前付け、タグ、テンプレートなどのツールを介して管理されない限り、ポリシーの拡散を引き起こすリスクがあります。

コスト管理とキャパシティ管理

ポリシーベースのルーティングの第三の適用は、コストとキャパシティ管理のためであり、重要なアプリケーションにはプレミアムで高価なパスを予約し、バルクトラフィックには安価なリンクを使用します。例えば、バックアップ、パッチ適用、大きなファイル転送は、コスト効果の高いパスを通じてルーティングされるべきです。なぜなら、ネットワークの遅延がわずかに増加しても、それらにはほとんど影響がないからです。

これらのユースケースは、ネットワークの混雑や、ビジネスクリティカルなアプリケーションのパフォーマンスに影響を与えるネットワークパスの遅延の上昇に関連する問題によって推進されることがよくあります。重要度の低いトラフィックを安価なリンクに再ルーティングする効果は、これらのポリシーを実施する前後の混雑イベント中のビジネスクリティカルなトラフィックのパフォーマンスを比較することで明らかになるかもしれません。

ポリシーベースのルーティングで何が問題になる可能性があるか？

ポリシーベースのルーティングを実施する際の一般的な失敗モードや落とし穴には、以下が含まれます：

• 非対称ルーティング:組織は、アウトバウンドトラフィックを送信する出口ポイントまたはパスを選択できますが、セッション内のインバウンドトラフィックは異なるパスを取る可能性があります。これにより、セキュリティツールや施行ポイントが会話の半分しか見えない場合に問題が発生する可能性があります。
• ポリシーの競合：パケットをポリシーにマッチさせる際に、複数のポリシーが一致する可能性があります。ルールの順序付けは、これらの競合を解決するために使用されますが、正しいポリシーが選択されない可能性があります。
• ルールのシャドウイング:ルールのシャドウイングは、一般的なポリシーがより具体的なポリシーよりも高い順序にあるポリシーの競合の一種です。これは、具体的なポリシーが決して適用されないことを意味します。
• 脆弱なマッチング:脆弱なマッチングは、ポリシーのマッチがあまりにも厳密に定義されている場合に問題になる可能性があります。この場合、マッチフィールドの小さな偏差がポリシーがもはや一致せず、適用されなくなる原因となる可能性があります。

これらの課題は、ネットワークトラフィックのパケットキャプチャを分析することによってのみ解決されるかもしれません。これにより、さまざまな状況で正しいポリシーが適用されたかどうかを判断するのに役立ちます。一般的に、良い緩和戦略は、ルールを簡素化し、ログを実装し、ポリシーをテストし、変更を段階的に行い、サイトごとに検証することです。

技術的な失敗モードを超えて、組織はガバナンスに苦労することがあります。一般的な落とし穴には、管理されていない例外、文書の欠如、テスト計画の不在、ロールバックの不在が含まれます。

よくあるご質問

ポリシーベースのルーティングと動的ルーティングの違いは何ですか？

ポリシーベースのルーティングは、トラフィックがどのようにルーティングされるべきかを定義するために、事前定義されたポリシーと基準を使用します。対照的に、動的ルーティングは主に宛先IPアドレスとさまざまなネットワークリンクの健全性に基づいています。

ポリシーベースのルーティングはアプリケーション認識ルーティングと同じですか？

ポリシーベースのルーティングとアプリケーション認識ルーティングは、ルーティングの決定を行う際にさまざまな要因を考慮します。ただし、ポリシーは一般的に静的マッチフィールド（ポート、プロトコルなど）を使用して定義されるのに対し、アプリケーション認識ルーティングは、ルーティングの決定を行う際に遅延、ジッター、パケット損失などのSLA要因を考慮します。

クラウドアプリケーションに最も信頼性の高いマッチ基準は何ですか？

アプリケーションの識別は、クラウドインフラストラクチャが一時的であるため、クラウドアプリケーションにとって最も信頼性の高いマッチ基準です。IPピンニングは、重要なIPアドレスが変更される可能性があるため、これらの文脈では信頼性がありません。

チームはどのようにしてルーティングポリシーを安全にテストしますか？

可能な場合、テストはテスト環境で行うか、シミュレーションを通じて実施するべきです。本番環境に展開する際には、変更を段階的に実施し、広範な検証とテストを行うべきです。

PBRデザインが複雑すぎることを示す最大のサインは何ですか？

PBRデザインが複雑すぎることを示す兆候には、多数のポリシー例外、一貫性のない結果、頻繁な緊急変更が含まれます。この場合は、簡素化し、変更を検証し、ポリシー作成のための変更管理ルールを実施してください。

Cato Networksを使用したポリシーベースのルーティングの実装

Cato SASE クラウドプラットフォームは、専用のプライベートバックボーンによって支えられた、SASE PoPのグローバルネットワークとして実装されています。管理者は、特定のトラフィックタイプがネットワークを通じてどのようにルーティングされるべきかを指定するネットワークルールを定義できます。さらに、Catoのプライベートバックボーンは、公共のインターネットよりも本質的に高い信頼性、パフォーマンス、および制御を提供します。

Cato SASEクラウドプラットフォームは、セキュリティ統合とネットワークのルーティングおよびパフォーマンスに対する詳細な制御の両方を提供します。ビジネスにおける潜在的な利点について詳しく知るには、デモをスケジュールする。