TKYTEL COMMENT 40
                                                          東京広域電話網
                                                              はくさい局
                                                              2026-09-30

                         インシデント・レポート
               〜疎通確認に使用するサーバの選定の重要性について〜

    主題の件、とても大事なため、以下に記す。

1. 事象

    複数回に渡り、はくさい局と管理人が使用する外部回線が、外部と疎通で
  きなくなった。

    短時間で復旧するものもあれば、長時間に渡り復旧しないものもあった。

2. システム構成について

    はくさい局が搭載されてるネットワーク基盤は、以下構成であった。

  - 良質な「NTT-W フレッツ光 ファミリー･スーパーハイスピードタイプ
    隼」をベースとした、コラボ光回線を使用していた。
  - ネットワークルータには一般家庭でも通常使用される、NEC UNIVERGE
    IX2215を使用していた。
  - IPv6についてはネイティブで接続していた。
  - IPv4通信については、JPNE社の「v6プラス」を使用して接続していた。
  - 外部システムと仮想閉域網で接続しており、「ネットワークモニタ」機能
    を用い、外部システム上のサーバへpingで定期的に疎通確認していた。
  - 上記に加え、MAP-Eネットワークからの通常接続も、外部サーバ（他社管
    理）へネットワークモニタ機能で疎通確認する形としていた。

3.何が起こったか

    MAP-Eネットワークからの疎通確認において、PING到達不能の形となった。
  結果として、「ネットワーク障害」と誤検知が起こった。

    また、当時「何故か投入していた」設定により、MAP-E通信へのルートが
  誤閉塞された。

4. 各種原因

    IX2215のネットワークモニタで、監視間隔などのパラメタは、初期値を用
  いていた。結果として、短期間での通信が重なり、攻撃として判断され相手
  側から通信が遮断された可能性がある。

    また、MAP-Eは、一つのIPv4アドレスを複数人で共有する形となる。その
  ため、運悪く「同一のIPv4アドレスを使用する人」が、同一のサーバへアク
  セスした結果、本事象が発生した可能性がある。

    そもそも、「ネットワークルートを閉塞させる」というコンフィグを投入
  していたのが一番の誤りである。

5. 対策

    無用なコンフィグは消し飛ばした。経路を閉塞させること自体が誤りだっ
  た。

6. 最後に

    なお、疎通確認に使用していた相手先アドレスは「1.1.1.1」であった。
  キエエエエエ！！

                                                               – 以☆上 –