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

Kieeee.txt

@@ -0,0 +1,64 @@
+TKYTEL COMMENT XX
+                                                          東京広域電話網
+                                                              はくさい局
+                                                              2026-08-XX
+
+                         インシデント・レポート
+               〜疎通確認に使用するサーバの選定の重要性について〜
+
+    主題の件、とても大事なため、以下に記す。
+
+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」であった。
+  キエエエエエ！！
+
+                                                               – 以☆上 –