ゼロフットプリント
Osprey がネットワークの一部にならずにネットワークを見る方法
Michel Wijnberg
世界中のあらゆる監視製品が「エージェントレス」を名乗ります。その大半が意味している
のは、SSH でログインして show の出力を画面スクレイピングする、ということです。空き
巣が来客であるのと同じ意味で、それは確かにエージェントレスです。
Osprey は別の道を選んでいます。マーケティングの文句が完全には正しくない部分も含めて、 正確に説明したいと思います。
Osprey がデータを得る方法は 3 つあります。3 つとも、見ようとする運用者には見えます （これはステルス製品ではありません）。しかし、そのうち Osprey をルーティングプロトコ ル自身のデータベースの中に置くものは 1 つだけであり、精査する価値があるのはそれです。
1. GRE レコーダー：トラフィックを決して運べない本物の隣接
いちばん面白いものです。Osprey は GRE トンネル上で本物の IGP 隣接を形成できます。 本物の Hello、本物の DBD 交換、本物のフラッディングを伴う、実際の OSPFv2、OSPFv3、 IS-IS のネイバー関係です。ルーターが LSDB を学ぶのと同じやり方、つまり教えてもらうこ とで、LSDB を学びます。
これは MIB をウォークするより厳密に優れています。プロトコルが実際に配布するとおりの データベースが、シーケンス番号もエージもチェックサムも欠けずに手に入り、変更は次の ポーリング間隔ではなくフラッディングされた瞬間に見えるからです。
同時にこれは、ルーター側にネイバーが見えているということでもあります。はっきり言 います。**Osprey は LSDB に現れます。**現れざるをえません。RFC 2328 §12.4.1 は、エリ ア内のすべてのルーターが Type 1 の Router-LSA を生成することを要求しており、隣接を張 りながら Router-LSA を生成しないルーターは壊れたルーターです。
ですから問うべきは「見えなくできるか」ではなく（できません）、「転送に影響を与えられ ない状態にできるか」です。こちらには本物の答えがあります。
// originateRouterLSA creates and installs our Router-LSA in the LSDB.
// RFC 2328 Section 12.4.1 requires every router to originate a Type 1 LSA.
// We use cost 65535 (maximum) so no router will ever route traffic through
// Osprey. Only the P2P link is advertised. NO stub network for the tunnel
// inner subnet. Advertising the tunnel subnet (even at max cost) causes SPF
// on other routers to install a route for the tunnel prefix, which can
// disrupt the GRE outer path and kill the adjacency.ここには意図的な判断が 2 つ入っており、2 つ目はラボを 1 回落として初めてきちんと学び ました。
最大メトリック。レコーダーは唯一のポイントツーポイントリンクをコスト 65535 で広 告します。ただし、これは 2 つの保証のうち弱いほうです。メトリックは経路を魅力的でな くするだけであり、魅力的でない経路も、それしかなければ結局選ばれます。本当の保証は形 にあります。レコーダーは隣接をちょうど 1 本しか持たないのでグラフ上の葉であり、葉を 通り抜ける経路など、どの SPF にも見つけようがありません。加えて自分のプレフィッ クスを一切広告しないので、そこへ向かってルーティングする対象もありません。最大メ トリックは、そもそもトランジットを運べない構造の上に重ねた、念のための保険です。
スタブネットワークを出さない。レコーダーが広告するのは P2P リンクだけで、ほかには 何もありません。とくに、トンネルの内側サブネットをスタブネットワークとして広告する ことはしません。ここが微妙なところです。もし広告すれば、エリア内のすべてのルータ ーがトンネルのプレフィックス宛の経路をインストールします。その経路は、GRE トンネル自 身が乗っているアンダーレイ経路を上書きしかねません。すると外側のトランスポートが壊 れ、隣接が落ち、レコーダーが落ちます。見事なまでの自業自得のフラップです。到達可能な ものを何も広告しなければ、この種の問題はまるごと回避でき、しかも RFC 2328 は満たした ままです。
IS-IS 版はもっと厳格です
IS-IS にはまさにこのための専用の仕組みがあるので、IS-IS レコーダーはそれを使います。 自身が生成する LSP は、いくつもの厳格な不変条件を背負っています。
| 不変条件 | 理由 |
|---|---|
| OL ビット = 1 | オーバーロードビット。ISO 10589 は、オーバーロード状態のルーターを他のすべてのルーターが非トランジットとして扱うことを義務づけています。これはメトリック上の小細工ではなく、第一の保証です。 |
| ATT ビット = 0000 | L1 のデフォルト経路を決して引き寄せません。L1 のみのルーターが Osprey にデフォルトを向けてはいけません。 |
| P ビット = 0 | パーティション修復を行いません。 |
| TLV 22 のメトリック = 0xFFFFFF | 最大のワイドメトリック。OL ビットと合わせた二重の備えです。 |
| TLV 128 / 130 / 135 / 236 なし | これらは IP 到達性 TLV です。どれか 1 つでも出せば経路を注入することになります。 |
| TLV 134 なし | TE Router ID なし。出せば Osprey がトラフィックエンジニアリングのデータベースに入り込んでしまいます。 |
| TLV 222 / 242 なし | マルチトポロジーなし、ルーターケーパビリティおよびセグメントルーティングなし。 |
この表は設定項目の一覧ではなく、コードにできないことの一覧として読んでください。オー バーロードビットを外す設定オプションは存在せず、IP 到達性 TLV を組み立てるコードパス も存在しません。プレフィックスを決して広告しないと保証するいちばん安全な方法は、広告 する機能を実装しないことだからです。
つまり、見えていて、参加していて、それでいて構造上パケットを 1 つも引き寄せられない。 これは「見えない」よりずっと強い主張であり、「見えない」と違って本当のことです。
2. SNMP：退屈なやり方で得る LSDB と、LSDB が運ばないすべて
すべての機器が隣接を張らせてくれるわけではありませんし、そもそもリンクステートデータ ベースに載っていない情報もあります。そこで Osprey はポーリングも行います。
このラボでは 192 のターゲットがすべて緑、300 秒周期でポーリングされ、最終ポーリングは 秒単位です。
認証情報の列には *** と表示されています。このマスクがどこで行われているかは正確に述
べる価値があります。**ブラウザではなく、API ハンドラーの中です。**認証情報は
AES-256-GCM で暗号化して保管され、あらゆる読み取り経路がシリアライズ前にレスポンスを
マスクに通します。フロントエンドはそもそもコミュニティ文字列も v3 の auth/priv パスワ
ードも受け取りません。ですから「表示する」ボタンは存在せず、サーバーを書き換えない限
り存在させることもできません。
クライアント側でマスクするのは演出です。ハンドラーでマスクするのは統制です。
ここでの SNMP の仕事は 4 つあります。
- LSDB の再構成。レコーダーが張られていない場所で使います（前回の記事の 13,382 件の LSA はこれで得たもので、欠けているヘッダーフィールドは正直に明示されて います）
- インターフェースカウンター。トラフィック、エラー、使用率のためのものです
- EIGRP。参加すべきデータベースがそもそも存在せず、すべて
CISCO-EIGRP-MIBから 読み取ります - L2 ネイバー。LLDP と CDP を使います
最後のものは、聞こえよりずっと重要です。
303 の L2 隣接、66 台のユニークなリモートデバイス。AS 間の BGP セッションが実際にどの
物理ポートを通っているのかを、「この 2 台のルーターの間のどれかのリンク」とごまかさ
ずに言えるのは、この層があるからです。その AS 間リンクのひとつは表の中にそのまま見えて
います。ams1-gw1 Et1/1 から e-ams1-gw1 への CDP エントリー、これが AS 200 ↔ AS 100
の境界です。
3. BMP：ルーターに語らせる
BGP については、望ましいのは尋ねることではなく、聞くことです。
BMP（RFC 7854）は、ルーターが自分の Adj-RIB-In、つまりピアが自分に広告してきた経路を、
素の TCP セッションで監視ステーションにプッシュするプロトコルです。ポーリングルー
プはなく、show ip bgp のパースもなく、セッションそのもの以上のクエリ負荷をコントロー
ルプレーンに与えません。何をいつ送るかはルーターが決めます。
ここでは 57 ピアにまたがる 378 セッションがありますが、すべてが同じ経路で届いたわけでは なく、その区別はならされずに記録されています。
このラボでは 6 台のルーターが BMP エクスポーターであり（ams1-gw1、jfk1-gw1、
e-ams1-gw1、e-sin1-gw1、i-jfk1-gw1、i-sin1-gw1）、24 セッションを占めます。
ラボ内のすべての eBGP セッションがここに含まれます。残る 354 は、BMP をまったくエク
スポートしないルーターに対する BGP4-MIB の SNMP ウォークから来ています。
データへの経路はどちらも正当で、どちらも持っている価値があります。ただし、同じだけ良い わけではありません。BMP のフィードはピアが広告したすべての経路を、ルーターから見た Peer Up と Peer Down とともに運びます。SNMP ウォークが与えるのはポーリング時点のセッション表 だけで、ポーリングとポーリングの間には何もありません。ここでどの RIB が問題になるのか。 RFC 7854 が監視するのは Adj-RIB-In であり、このルーターが何かを選ぶ前に届いたものです。 ルーター自身が選んだ表、すなわち Loc-RIB は、後から定義された別の拡張（RFC 9069）で、 これらのエクスポーターは送りません。したがって、それらの候補に対するベストパス選択は Osprey の計算であり、そのようにラベル付けされています。
だからこそ、すべての行が source 列を持ち、どちらから来たのかを記録しています。そして
その値は、スタックの上のほうで荷重を支えます。Osprey が後で AS をまたぐパスをつなぎ合わ
せ、ドメイン間のホップを正当化する必要が出たとき、eBGP セッションは出所を添えた根拠
（bmp-peer か snmp-peer か）として数えられ、匿名の事実として扱われることは決してあ
りません。同じ表でも、格付けされています。
両方のアドレスファミリはエクスポーターごとに 1 本の BMP セッションに相乗りします。IPv4 と IPv6 の行が同じ報告ルーターを共有しているのはそのためです。
その表の中で面白いのは eBGP の行です。3 つのテナントのあいだの継ぎ目だからです。
| 送信元 | AS | 宛先 | AS |
|---|---|---|---|
e-ams1-gw1 | 100 | ams1-gw1 | 200 |
i-sin1-gw1 | 300 | e-sin1-gw1 | 100 |
i-jfk1-gw1 | 300 | jfk1-gw1 | 200 |
三角形です。アムステルダムで AS 200 ↔ AS 100、シンガポールで AS 100 ↔ AS 300、ニューヨ ークで AS 200 ↔ AS 300。6 セッション、両ファミリ合わせて 12 行。そもそもドメインをまた ぐパスのつなぎ合わせを可能にしているのがこの三角形であり、それが第 3 回の 主題です。
Osprey が構造上できないこと
制約のいくつかは、機能としてではなく制約として述べる価値があります。残りが信用に足る理 由が、まさにそれらだからです。
- **経路注入なし。**レコーダーが生成する Router-LSA はちょうど 1 つで、最大コストの P2P リンクをちょうど 1 本記述するだけです。プレフィックスを広告するコードパスを持ちませ ん。
- **パケット転送なし。**Osprey はデータプレーンにいません。転送表も FIB もなく、書き間 違える対象そのものがありません。
- **設定書き込みなし。**UI の SSH ターミナルはターミナルです。打鍵はあなたのもので、セ ッションは監査のために記録され、Osprey 自身が設定コマンドを発行することはありません。
- **一方向のデータフロー。**コレクターと BMP が取り込んで NATS に発行し、エンジンが PostgreSQL に永続化し、API がフロントエンドに配信します。上流に呼び返すサービスはあり ません。人がターミナルに打ち込む以外に、Web UI からルーターへ至る経路は存在しません。
正直なまとめ
Osprey は、肝心な意味においてパッシブです。トラフィックを引き寄せられず、経路を注入でき
ず、パケットを転送できません。しかし不可視ではありません。想定より 1 行多い
show ip ospf neighbor で気づかれるくらいなら、私は先に申し上げておきたいのです。
もしどこかのベンダーが、自社ツールはあなたの IGP に参加するが誰にも分からないと言っ てきたら、その Router-LSA がどんな形をしているのか聞いてみてください。
次回：あなたのパスツールがおそらくあなたに嘘をついている理由と、それを裏づける 4,032 ペアの測定：ホップバイホップの真実。