IP重複時代のSASE設計: Return Routingを前提にした運用パターン

CloudflareのAutomatic Return RoutingやDynamic PMTUD関連の更新は、SASE運用の実務課題をよく表しています。いま企業ネットワークでは、RFC1918アドレス重複（10.x / 172.16/12 / 192.168.x）が例外ではなく常態です。M&A、子会社統合、外部パートナー接続でほぼ確実に発生します。

この状況で従来型の単純なsplit tunnel設計を続けると、戻り経路の非対称が増え、断続的タイムアウトや再現困難な遅延が起きます。

何が壊れるのか

従来VPN前提:

• 単一の私設網
• 戻り経路はほぼ固定
• ルートテーブル変更は低頻度

現在の現実:

• 事業単位ごとにCIDRが重複
• SaaS/私設アプリ混在で最適経路が変動
• ユーザーがWi-Fi/モバイル/社内LANを頻繁に移動

結果として、順方向は通るのに戻りで落ちる現象が増えます。

解決の軸: ポリシー連動Return Routing

全体最適の固定ルーティングではなく、アプリ種別とセッション文脈に紐づけた戻り経路制御が必要です。

• セッション単位の経路アンカー
• アプリセグメントのメタデータ連携
• 状態保持型アプリに対する決定的エグレス
• 回線劣化時の高速再選択

これにより、静的ルート依存の脆さを減らせます。

QUIC/PMTUDを運用指標に入れる

Dynamic PMTUDの話題が示す通り、トランスポート層はSASE体験の核心です。

• 端末の適応型MTU探索を有効化
• ISP/地域単位で断片化失敗率を計測
• アプリSLOとトランスポート指標を分離可視化
• ユーザー影響前に経路切替を実行

PMTUは初期設定ではなく、ランタイム制御対象として扱うべきです。

プラットフォーム運用手順（推奨）

1. 事業ドメインごとに重複CIDRを棚卸し
2. 私設アプリを「状態保持性」「遅延感度」で分類
3. クラス別に戻り経路ポリシーを設計
4. セッション単位の経路/転送メトリクスを収集
5. 自宅回線・テザリング・社内LANで切替テスト
6. 重複CIDRに敏感な経路に合成監視を導入

セキュリティ上の副作用

経路曖昧性は監査盲点を生みます。

• ポリシー適用先の誤認
• ingress/egressログ不一致
• 過剰なフェイルオープン設定による迂回

対策として、経路判定にID・セッション・ポリシーTrace IDを必ず紐づけます。

まとめ

IP重複は特殊ケースではなく、エンタープライズ標準トポロジです。Return Routingを明示的に扱うSASE設計は、可用性だけでなくゼロトラスト監査の正確性にも直結します。

参考トレンド

• Cloudflare Blog: Automatic Return Routing
• Cloudflare Blog: Dynamic PMTUD / QUICクライアント改善