SASE環境の「出口」を守れ：BGPルーティング設計とルートリーク対策の現場論
「インターネットは信頼できない場所である」――ゼロトラストの基本原則ですが、それを支えるSASE（Secure Access Service Edge）のインフラを構築する際、我々ネットワークエンジニアが直面するのは、物理的な境界の消滅と、ダイナミックルーティングの魔物です。
特に、拠点（SD-WAN）とSASE PoPをBGPで接続する際、何も考えずに経路をアドバタイズすれば、あっという間に自社のトラフィックが意図しないASを駆け巡る「ルートリーク」の罠に落ちます。今日は、机上の空論ではない、現場の泥臭い知見を共有しましょう。
—
1. AS番号設計とBGPの「距離感」をどう制御するか
SASE環境では、各拠点のSD-WANルータは、SASE PoPに対してプライベートAS（64512-65534）を用いてBGPピアリングを張るのが一般的です。ここで重要なのは、「自分の経路がどこまで伝播するか」を制御するポリシーです。
なぜルートリークが起きるのか
多くの現場で、「とりあえず全経路を流し込む」という設定が見受けられます。しかし、SASE PoP側で受診した経路が、別の拠点へ再配布（Redistribution）されたり、さらにはインターネットのフルルートを誤って吸い込んでしまうと、ネットワークは瞬時に破綻します。
現場のベストプラクティス：Prefix-Listの厳格化
BGPの設定には、必ず prefix-list を適用し、許可するサブネットを「1ビット単位」で指定してください。
# Cisco IOS風の設定例：許可リストの定義
ip prefix-list PL_FROM_BRANCH permit 10.10.0.0/16 ge 24 le 28
!
route-map RM_SASE_IN permit 10
match ip address prefix-list PL_FROM_BRANCH
set community 65000:100 # 自社の属性タグを付与し、後続のポリシーで識別可能にする
!
# BGPピアへの適用
router bgp 65001
neighbor 192.168.1.1 route-map RM_SASE_IN in—
2. ルートリークを防ぐための「コミュニティ」活用術
BGPの威力を最大限に発揮するのは、単なる接続性ではなく、community 属性による経路制御です。私は常に、拠点ごとに特定のコミュニティ値を付与し、SASE PoP側で「この経路はどの拠点から来たのか」を明確にタグ付けするようにしています。
もし、ある拠点が誤って学習した別拠点のルートを再度広告（再配布）しようとした場合、このコミュニティ値がバリケードになります。
経路の伝播を抑止するフィルター（PoP側の設定イメージ）
# 誤った経路広告を弾くためのRoute-Map
route-map RM_SASE_OUT deny 5
match community NO_ADVERTISE_TAG # 特定のタグが付いた経路は外に出さない
!
route-map RM_SASE_OUT permit 10
match community MY_ENTERPRISE_TAG # 自社内経路のみを許可—
3. 実践：CASBとAPIを通じた可視化
SASE環境下での通信フローをデバッグする際、単に show ip bgp を眺めるだけでは不十分です。今やトラフィックの多くはSaaSに向いています。CASB（Cloud Access Security Broker）が介在する通信では、HTTPヘッダーに特定のトークンが付与されているか確認することがトラブルシューティングの鍵となります。
以下は、PythonでSASE経由の通信を確認するデバッグ用スクリプトの断片です。
import requests
def check_sase_path(url):
# SASE経由であるかを検証するため、特定のヘッダーを注入してレスポンスを確認
headers = {
'User-Agent': 'Security-Audit-Bot/1.0',
'X-SASE-Debug': 'True'
}
try:
response = requests.get(url, headers=headers, timeout=5)
# SASEのPoPで付与されるはずのヘッダーを確認
if 'X-SASE-PoP-Location' in response.headers:
print(f"成功: PoP拠点 {response.headers['X-SASE-PoP-Location']} を通過しました")
else:
print("警告: 直接通信、またはSASEを通っていない可能性があります")
except requests.exceptions.RequestException as e:
print(f"通信エラー: {e}")
check_sase_path("https://api.internal-app.example.com")—
4. エンジニアへの助言：デバッグの心構え
最後に、現場で障害に遭遇した際の「三種の神器」を伝授します。
1. debug ip bgp updates は諸刃の剣: 本番環境でこれを叩くときは、必ずログバッファのサイズを確認し、フィルタリングをかけてください。さもないと、ルータのCPU負荷が急上昇し、通信が停止する「自己攻撃」に陥ります。
2. AS-Pathの可視化: show ip bgp regexp ^$ を使い、自分自身のASから発生した経路のみを抽出する癖をつけましょう。AS-Pathが長すぎる経路は、ルートリークの兆候です。
3. ベンダーのPoP情報を信用しすぎない: SASEベンダーの管理画面で「接続中」となっていても、BGPのステータスが Idle や Active を繰り返していることは多々あります。必ずCLIでピアリングの HoldTime や Keepalive タイマーが適切か（推奨は30秒/90秒）を確認してください。
ゼロトラストは、境界をネットワーク機器から「アイデンティティとポリシー」へ移す作業ですが、その土台となるBGPルーティングが腐っていては、どれほど高度なCASBポリシーも無意味です。
まずは自身のルータの show ip bgp neighbors を叩くところから、今日の業務を始めてみてください。その一行が、ネットワークの平和を守る第一歩です。
コメント