要約
- APNIC は AS132722 を Intellium Technology Limited に関連付け、自治システムオブジェクトの管理状態を active と記録している。これは番号資源の登録上の識別情報であり、現在の経路広告、交換セッション、顧客サービスの稼働を証明するものではない。
- PeeringDB には同 ASN の交換接続が二件申告され、Intellium のサイトには IT と通信のサービス説明がある。公開情報から識別と申告上の相互接続は確認できるが、トラフィック、実効容量、物理的な経路分離、提供範囲、性能は判断できない。
調査を始める前に証拠の役割を分ける
自律システムとは、外部のインターネットに対して共通のルーティング方針を示すネットワーク、またはネットワーク群である。ASN はその識別番号であり、ネットワーク同士が BGP、すなわち Border Gateway Protocol を使って到達性情報を交換するときの基準になる。
この仕組みがあるため、AS132722 は「どのルーティングドメインについて話しているのか」を明確にできる。障害対応でも、似た社名や製品名ではなく番号を使うことで、確認すべき登録情報や担当者を絞り込みやすい。
一方、識別番号そのものは稼働試験ではない。番号資源レジストリは登録主体を記録する。相互接続ディレクトリは参加者の申告を整理する。会社サイトは事業者自身のサービス説明を掲載する。現在の経路、BGP セッション、インターフェース、アプリケーションの状態は、稼働中のシステムと観測データから得なければならない。
この区別を保てば、active という管理用語を「すべて正常」と読み替えることも、運用データがないことを「障害」と決め付けることも避けられる。
APNIC が確定するのは登録上の境界
APNIC の RDAP オブジェクトは AS132722 だけを対象にしている。handle は AS132722、オブジェクト名は ITL-AS-AP、国フィールドはニュージーランドで、登録者として Intellium Technology Limited が記載される。登録イベントは 2013 年 4 月 2 日、最終変更イベントは 2020 年 11 月 25 日で、管理状態は active である。
ここから強く言えるのは、地域インターネットレジストリが現在この番号をどの組織に結び付けているかである。公開オブジェクトと連絡先は、経路や abuse に関する連携先を探すときにも役立つ。番号の一意性と登録者の追跡可能性が保たれていれば、誤ったネットワークへ問い合わせる危険を減らせる。
ただし active はルーターのヘルス表示ではない。RDAP はプレフィックスが現在広告されているか、特定の観測地点から見えるか、顧客のサービスが応答するかを測定しない。最終変更日も、2020 年以降のすべての設備、上流、設定変更がなかったことを意味しない。これは当該オブジェクトに保存された管理イベントの日付である。
レジストリは正確な台帳であり得るが、稼働状態の裁定者ではない。台帳が答える識別の問いと、実際のルーティングが答える運用の問いを分けることで、両方の証拠を正しく使える。
PeeringDB の二件は確認すべき申告事項
PeeringDB のネットワーク応答には AS132722 の行が一件あり、名称は Intellium Technology、ウェブサイトは Intellium のドメイン、ネットワーク種別は Cable/DSL/ISP、一般ピアリング方針は Open とされている。IPv4 と IPv6 のプレフィックス数フィールドはともにゼロで、IRR set、looking glass、ルートサーバー URL は空欄である。
このゼロと空欄は、現在の PeeringDB レコードに何が入力されているかだけを表す。Intellium が経路を一切生成していない、別の場所にアドレス資源を持たない、IPv6 を使えない、といった結論には広げられない。参加者が保守するディレクトリでは、任意項目が未入力だったり、実ネットワークとは異なる周期で更新されたりすることがある。
交換接続の応答には二行ある。一件目は APE への接続を 1,000 Mbps として申告し、IPv4 アドレスを掲載する一方、IPv6 アドレスとルートサーバー参加フラグはない。二件目は AKL-IX への接続を 10,000 Mbps として申告し、IPv4 と IPv6 の両アドレス、およびルートサーバー参加フラグを掲載している。
運用チームは、この二件を現行設計との照合項目にできる。AS132722 が期待する ASN か、交換所とアドレスが想定セッションに対応するか、担当者と経路方針が最新かを順に確認できる。識別ミスを先に除外できれば、その後の BGP 調査も狭くなる。
しかし、ディレクトリ上の operational はリアルタイムのセッション状態ではない。掲載速度は現在の通信量や障害時の余剰容量を示さない。二つの論理接続があっても、光ファイバー、電源、建物、上流ネットワーク、管理経路が物理的に独立しているとは限らない。顧客通信がどちらを通るかも、この応答だけでは分からない。
公式サイトは企業の提供範囲を説明する
Intellium のサイトは、同社を IT サポートと通信の提供者として紹介している。ナビゲーションにはクラウド、IT サポート、音声・インターネット、サイバーセキュリティ、生産性、ビジネスインテリジェンスなどが並ぶ。サイトのドメインは、APNIC の連絡先と PeeringDB のウェブサイト欄に現れるドメインと限定的に整合する。
この整合は、三つの資料が同じ企業文脈を参照しているという識別の補助になる。ただし、AS132722 が掲載サービスのすべてを運ぶとは言えない。企業は複数の ASN、アクセス回線、クラウド、上流事業者を使える。サービスページからは、特定顧客のプレフィックス、配送経路、交換接続、施設や外部依存関係を特定できない。
同様に、ページの説明は可用性、遅延、容量、セキュリティ効果、継続性の測定結果ではない。会社が何を提供すると説明しているかと、そのサービスが特定条件でどう動いたかは、別々に記録すべきである。
公開情報の先で必要になる観測
現在の経路可視性を知るには、観測時刻と地点を持つルートコレクターの結果が必要になる。BGP が確立しているかを知るにはセッションテレメトリーを確認する。リンクが通信を運んでいるかにはインターフェースカウンター、顧客サービスが使えるかには DNS やアプリケーションを含むエンドツーエンド試験が必要だ。
それぞれの結果にも限界がある。経路が見えてもアプリケーションの正常性は保証されない。セッションが確立しても全顧客の経路は分からない。通信量があっても障害時の十分な容量は証明されない。証拠には対象、時刻、観測地点、試験条件を残さなければならない。
今回の四つの公開情報には、こうした運用観測が含まれていない。そのため正しい結論は「現在の状態はこの資料群からは未証明」であり、「停止している」ではない。不在の証拠を障害の証拠として扱わないことが重要である。
運用者と利用者が確認できること
運用者は、AS132722 が今も想定するルーティング識別子か、APE と AKL-IX の申告が現行設計に合うか、掲載アドレスが意図したセッションに割り当てられているかを確認できる。その後で、ルートポリシー、セッション状態、実際に観測された広告を照合する。
利用者は、契約サービスを提供する ASN と配送経路、Intellium が管理する依存関係、第三者が管理する依存関係を質問できる。可用性や復旧を評価するなら、定義されたサービスと障害条件を用いた日付付きの試験結果を求めるべきであり、ASN の管理状態や交換接続の速度欄を代用してはならない。
インシデント対応では、登録識別、相互接続申告、経路観測、セッション状態、サービス試験を別欄に記録するとよい。原因がルーティング、アクセス、DNS、アプリケーション、外部依存のどこにあるかを、公開ディレクトリだけで早期に決め付けずに絞り込める。
再確認を促す変化
- APNIC における AS132722 の登録者、状態、連絡先、イベント履歴の変更。
- PeeringDB のネットワーク名称、方針、入力済みフィールドの重要な更新。
- APE または AKL-IX の接続行、アドレス、プロトコル情報の追加・削除・変更。
- Intellium のドメインや公開サービス説明の実質的な変更。
- 現在の経路、セッション、通信、具体的なサービス結果を示す日付付き観測。
監視では、何が変わったかだけでなく、どの証拠層でいつ観測したかを保存する。登録、申告、稼働観測の時計を分けておけば、古いディレクトリ情報が現在のネットワーク状態を無意識に代弁することを防げる。