編集チームの記事その他の記事

レジストリのデータが変わると、なぜ稼働中のネットワークに届かなくなるのか?

記録の変更が経路フィルターやRPKIに及ぶ過程をたどり、接続できなくなる理由と、Lu Hengが継続性および実効性のある独立への道筋を求める理由を解説します。

目次

自社のサービスがモバイル回線では利用できるのに、別のネットワークの顧客からは接続できなくなったと想像してください。サーバーは正常です。ケーブルもつながっています。考えられる原因の一つは、記録が変更された後、別のネットワークが自社のアドレスへの経路を受け入れなくなったことです。

見落とされがちなのは、記録とルーターの間にある判断です。データベースの変更が接続性に影響するのは、システムがその変更を使ってフィルターを作成したり、経路広告を評価したりするときです。障害を理解するには、この連鎖をたどってください。「レジストリが間違っている」という指摘は、原因調査の出発点にすぎません。

二つの建物はサーバーに配線でつながったままです。一台のネットワーク機器の表示灯が消えており、技術者がカード式の記録を調べています。

記録の変更が経路の受け入れに影響しても、物理的な接続は正常なままのことがあります。証拠と、受信側のポリシーをたどってください。

まず、どの記録が変わったのかを確認する

IPプレフィックスとは、アドレスのまとまりです。自律システム番号(ASN)は、他のネットワークと経路を交換するネットワークを識別します。BGPは、それらのネットワークが到達可能な宛先を広告するために使うプロトコルです。

この経路交換には、いくつかの種類の記録が関係します。それぞれが答える問いは異なります。

  • 登録記録:アドレスブロックに対応づけて記録されている組織はどこか、誰に連絡すればよいかを示します。RIPEデータベースの文書は、同じデータベースに格納されていても、資源の登録、ルーティング情報、連絡先の記録を区別しています。
  • インターネットルーティングレジストリ(IRR)の記録:運用者が、受け入れる経路のリストを作るために利用できる情報です。記録は意図されたルーティングを記述するもので、それ自体が経路を広告するわけではありません。
  • リソース公開鍵基盤(RPKI)の記録:ROAと呼ばれる、署名付きの経路起点の認可などが含まれます。検証器はこれらを基に、経路の起点となるネットワークと、許可されるプレフィックス長を確認するためのデータを生成します。

連絡先のメールアドレスが古いからといって、それだけでBGP経路が取り消されるわけではありません。一方、プロバイダーが生成したフィルターに経路が含まれていなければ、そのプロバイダーは経路を受け入れなくなることがあります。両者をまとめて「無効なレジストリデータ」と呼ぶと、肝心の違いが見えなくなります。

記録が経路の拒否につながるまで

IRRデータから顧客向けの経路フィルターを作成するプロバイダーを考えてみましょう。次のような障害の連鎖が起こりえます。

  1. 経路の記録が削除される、または顧客の経路セットにその経路が含まれなくなる。
  2. プロバイダーが次にフィルターを生成する際、その経路が除外される。
  3. 新しいフィルターがプロバイダーのルーターに反映され、顧客の経路広告が拒否される。
  4. 利用可能な代替経路が残っていなければ、その経路に依存する人々が接続できなくなる。

この連鎖が起こるには、そのデータが実際にフィルターの生成に使われている必要があります。NTT DATAが公開しているルーティングレジストリのポリシーは、IRRに基づく顧客向けフィルターと自動更新の具体例です。RPKIでInvalidと判定された経路の拒否や、矛盾するIRR記録の使用抑止についても記載されています。これらは特定可能な運用上の仕組みであり、レジストリが万能の遮断スイッチを持っているという話ではありません。

RPKIの「Invalid」は実際に何を意味するのか

起点検証では、広告された経路を、検証済みの認可データと比較します。RFC 6811は、三つの結果を定義しています。

  • Valid:その経路を包含する認可のうち、少なくとも一つが起点ASNと一致し、広告されたプレフィックス長を許可している。
  • Invalid:その経路を包含する認可データはあるが、両方の条件を満たすものがない。
  • NotFound:その経路を包含する認可データがない。

例えば、ネットワークAが広告している経路は、それに一致する認可がなくなり、その経路を包含するネットワークB向けの認可だけが残ると、Invalidになることがあります。包含する認可が一つも残らなければ、結果はInvalidではなくNotFoundです。ここでの「Invalid」は、ルーティングの検証結果であり、所有権や組織の正当性についての判定ではありません。また、起点検証は、その経路が通ってきたと主張する経路全体を認証するものでもありません。

その次に関わるのは、運用者が設定したポリシーです。RFC 8481は、検証状態を設定することと、その状態に基づいて動作することを区別しています。ポリシーは運用者が設定しなければなりません。Invalidの経路を拒否するよう設定されたネットワークは、この経路広告を拒否することがあります。レジストリの編集と経路の拒否は、この仕組みを介してつながっていますが、同じ出来事ではありません。

接続できなくなる人と、まだ接続できる人がいる理由

すべてのネットワークが、同じ時点で同じフィルター、プロバイダー、データを使っているわけではありません。RFC 7115は、RPKIキャッシュが異なる状態のデータを保持することがあり、更新がルーターに届くまでの時間には一律の保証がないと説明しています。

冒頭の例では、一方のネットワークはすでに変更後のデータに基づいて動作しているのに、もう一方には受け入れられた経路がまだ残っている可能性があります。そのため、一部だけで接続障害が起こりえます。ただし、それだけで特定の障害の原因がレジストリだと証明できるわけではありません。技術者は、影響を受けた経路、使用中のデータ、拒否に至った判断を調べる必要があります。

さらに変更する前に、どこで連鎖が途切れたのかを特定する

復旧に役立つ問いは具体的です。どのシステムが、どの経路広告を、なぜ受け入れなくなったのでしょうか?運用者は、プロバイダーと協力して次の手順で確認できます。

  1. 経路広告を特定する。影響を受けたプレフィックスと起点ASNを記録し、想定する経路が今も広告されているかを確認します。
  2. 拒否された箇所を突き止める。プロバイダーに適用されているフィルターと検証結果を、経路と照合します。どのデータ源の、どの更新がその判断につながったのかを確認します。
  3. 証拠を保存する。誤った更新と、認可されていない経路広告を区別できるよう、関連する記録、観測結果、時刻情報を残します。
  4. 修正し、検証する。必要な記録や設定の修正内容を正確に調整し、それらを利用するシステムに修正が反映されたことを確認したうえで、障害が起きたネットワークから接続を試験します。

あらゆる場所で検証を無効にすれば、不適切な経路広告に対する保護も失われます。運用上の課題は、正しい証拠と意図したルーティングを回復し、その結果を検証することです。データベースの編集に成功しただけでは、顧客が再び接続できるようになったとは確認できません。

より深い問題:有用な証拠が、集中した権力に変わりうる

ここで、技術的な連鎖とLu Hengの議論が交わります。管理者は、誰かのパケットを転送していなくても、その到達可能性に影響を及ぼせます。他のシステムが管理者の支配する記録に依存していれば、その判断は組織の外にいる運用者や顧客にも広く負担を課しえます。

論考65「『動くコード』の優位」で、Lu Hengは、調整の範囲は稼働中のネットワークの必要性によって制限されなければならないと論じています。記録を維持する役割が、それ自体を恒久的な政治的権限へと拡大してよいわけではありません。記録に署名があるという事実は、その表明に関する技術的な問いには答えます。しかし、それによって影響を受けるすべての人を統治する権利が成立するわけではありません。

彼の提案は、苦情処理を改善することにとどまりません。共通のルールは、一意性、検証可能な管理権、相互運用性を保護すべきです。その一方で、参加者はそれぞれの環境で状態を検証し、互換性のある変更のうちどれを採用するかを決めます。無制限の拒否権を持つ新たな委員会を設けても、別の名前で同じ問題を再現するだけです。

継続性には、他のネットワークも利用できる離脱の道筋が必要

実用になる代替手段は、信頼できる記録、セキュリティに関する表明、実際に機能している関係を引き継がなければなりません。他のネットワークが、その記録を検証して利用できる必要があります。データベースをコピーしただけでは、他のネットワークが代替の仕組みを受け入れることにはなりません。また、独立を宣言しても、拒否された経路が回復するわけではありません。

論考72は、目指す成果を明示しています。正確な記録、運用の継続性、そして機能不全に陥った調整者から実際に離れられることです。実務上の課題は、独立したネットワーク同士の通信を可能にしている共通の一意性と互換性を失わずに、その能力を築くことにあります。

レジストリ状態のエクスポートに関する解説は、この作業のうち、記録を持ち出して引き継ぐ部分を掘り下げています。これは、検証、運用者による採用、継続性の試験と並ぶ、移行の一要素です。

サービスが動いているうちに備える

重要なアドレスブロックを一つ選び、その記録から、それに依存するプロバイダーや顧客までをチームでたどってみてください。それぞれの記録を変更できるのは誰でしょうか。誰が参照しているのでしょうか。現在の管理者が利用不能になったり、その立場が争われたりした場合、誤りをどう修正するのでしょうか。

組織をまたいでこれらの答えを確かめるには時間がかかります。障害の前に把握しておけば、行動する余地が生まれます。障害の最中に初めて知るのでは、その負担を顧客が引き受けることになります。継続性をまだ守れるうちに、実務上の独立性を築くことが急がれます。

続いて論考65「『動くコード』の優位」をお読みください。稼働中のネットワーク、各参加者による検証、自発的な採用に根ざした調整を求めるLu Hengの議論を、詳しくたどれます。