要約

  • 対象がプロキシに直結した別ノードのインターフェースなら、PROBEが返すのはプロキシ側のARP表またはIPv6近隣キャッシュの状態であり、対象自身が生成した返答ではない。
  • Code 0、短いRTT、pingに似た表示は、いずれも正しくても、エンドツーエンド到達性やアプリケーション復旧までは証明しない。

障害対応中の端末に、成功した ping を思わせる一行が現れた。バイト数、シーケンス番号、TTL、短い往復時間。その末尾に active=1 ipv4=0 ipv6=0 が付いている。担当者は行全体の形を見て「戻った」と判断した。

しかし返答したのは対象インターフェースではない。プロキシである。しかもIPv4とIPv6のビットは両方とも立っていなかった。

これは特定の実障害を報告する話ではない。PROBE: A Utility for Probing Interfaces 改訂06が記録する実装・運用経験から再構成した判断場面である。初期クライアントはPROBEの結果をpingによく似せて表示した。人は全文を精読する前に既知の形を認識するため、末尾の重要な状態より「成功行らしさ」が勝った。そこで草案は、ビットの組合せを明示的な自然言語へ変換するよう勧めている。

表示だけの問題ではない。PROBEは、証言者を対象からプロキシへ移すことで、通常のpingでは届かない診断範囲を作る。したがって、証言の出所を消す設計は、道具の価値そのものを誤解する。

Lビットが分ける二つの観測

PINGでは、探査側が対象インターフェースへEcho Requestを送り、対象側からEcho Replyが返る。この往復は両者間の双方向接続を確かめる。PROBEでは、ICMP Extended Echo Requestの宛先はプロキシインターフェースである。必要なのは探査側とプロキシの双方向接続であり、探査側と対象の双方向接続ではない。

要求にはInterface Identification ObjectとLビットが入る。L=1なら対象はプロキシノード上にある。プロキシはRFC 8343のoper-statusを読み、upだけをactiveとして返す。upは「パケットを通す準備ができている」というローカルな運用状態である。down、testing、unknown、dormant、not-present、lower-layer-downは、この短い表現ではinactiveになる。

L=0なら対象はプロキシに直結した別ノード上にある。この場合、プロキシは対象にPROBE応答を求めない。自分のIPv4 ARP表またはIPv6 Neighbor Cacheを調べる。項目がなければNo Such Table Entry、あればState欄にその状態を載せる。

同じ「インターフェース状態」というUIラベルでも、証拠面は別である。一方はプロキシ自身のインターフェース状態、もう一方はプロキシが保持する近隣情報だ。収集基盤が両者を一個の真偽値へ変換すると、観測者、時刻、失敗モードが失われる。

STALEは障害宣言でも健康宣言でもない

RFC 4861の状態機械は、キャッシュ項目を静的な名簿として扱っていない。REACHABLEは、近隣への順方向が機能したという肯定的確認を最近得た状態である。STALEは、その確認から所定時間が過ぎ、現在の到達性が不明になった状態だ。DELAYは上位層の進展確認を待つ猶予、PROBEはNeighbor Solicitationによる確認中、INCOMPLETEはアドレス解決中を表す。

したがって、表に住所があることと、今この瞬間にサービスが使えることは同義ではない。反対にSTALEだけで断線とも言えない。正確な文章は「この時点で、このプロキシの近隣到達不能検出はこの状態を保持していた」である。

リンクローカルアドレスの再利用は、さらに帰属を難しくする。該当なし、一件だけだがどの近隣か識別不能、複数一致という三つの結果があり得る。Code 4のMultiple Interfaces Satisfy Queryは曖昧さを正しく報告するが、対象を決定してはくれない。

No Errorが成功を意味する範囲

応答Codeは、Malformed Query、No Such Interface、No Such Table Entry、Multiple Interfaces Satisfy Queryを区別する。Code 0のNo Errorは、それらの処理上の問題がなかったという意味だ。アプリケーションが正常であること、逆方向が存在すること、復旧が完了したことまで含まない。

RTTも同様である。付録のアプリケーションは複数回問い合わせ、往復時間を表示できる。しかし管理性の節は、その時間が探査ノードとプロキシノード間の経路を反映し、対象インターフェースの性質ではないと明記する。健全なプロキシは、壊れた近隣について素早く回答できる。

ここでHeng LuのRunning-Code Primacyが効く。標準に沿った応答は現実の一部であるが、物理リンク、転送、アプリケーション結果を創造しない。プロトコル層、プロキシ到達層、近隣状態層、サービス層を別々に保つことで、実行コードの証拠を過大評価せずに活用できる。

無応答にも複数の理由がある

Extended Echoは既定で無効である。運用者は機能を有効にし、許可するLビット、問い合わせ方式、送信元プレフィックスを設定する。許可されない要求や未対応の要求は黙って捨てられる。タイムアウトだけから対象インターフェースの故障を導くことはできない。

厳しい制御には理由がある。PROBEはインターフェース名、アドレス、数、帯域やベンダー、OSを推測する手掛かりを漏らし得る。改訂06はVPN、network instance、logical network elementをまたぐ漏えいを禁じ、境界を越える場合はNo Such Interfaceを返すよう求める。

またICMP checksumは暗号学的な証明ではない。経路上の攻撃者は要求や応答を改変でき、checksumは意図的改変ではなく偶発エラー検出のためのものだ。完全性が必要なら草案はIPsecを推奨する。高リスクの自動化では、正しくパースできたことと、意図したプロキシからの信頼できる証言を分けなければならない。

互換性より大きい、言葉の修正

改訂06はINTAREA作業部会の活発なInternet-Draftで、Standards Trackと記されている。RFC 8335をobsoleteにする提案だが、まだRFCではない。既知のRFC 8335実装とは互換で、変更はオンワイヤ動作ではなく書式と処理の明確化だと説明する。

重要なのは過去の教訓を仕様へ戻した点だ。pingに似ているという説明が、実装者にRFC 4884と食い違う近道を連想させ、pingに似た表示が運用者の早合点を誘った。Minimum Initial Specificationは小さくできるが、意味まで省略してよいわけではない。

成熟度にも留保がある。公共インターネットの一部を越えた個別実験はあるが、広範な実験結果はない。広い普及、性能、特定事業者の復旧を示す資料ではない。

保存すべき受領証

自動化するなら、探査ノードとインターフェース、プロキシノードとインターフェース、時刻、対象識別子と方式、Lビット、Code、State、A/4/6、許可元、network instance、実装版を保存する。その上で、独立したリンク観測、実転送、アプリケーション結果を結び、判断者、閾値、ロールバック条件を残す。

PROBEは次の診断を選ぶための強い証拠になり得る。しかし単独でエンドツーエンド到達性や復旧を認定してはならない。プロキシは有能な証人であって、対象インターフェースでも、経路全体でも、サービスでもない。

出典