はじめに
瀧澤です。
前回、EgressViewという、自宅・SOHOネットワークの外向き通信を可視化するOSSを作った記事を書きました。もともとYamaha RTX専用でしたが、前回の記事の公開後、実際の利用者から「自分でコードに手を入れてCiscoルーターで動かした」という報告をいただきました。ユーザーがフォークして自力対応するほどの需要があるなら、こちらで安全に使える形を提供すべきだと思い、Cisco IOSに正式対応しました。
さらに、Ciscoを利用するSOHOで想定される冗長化や複数回線にも備えるため、Yamaha RTXとCisco IOSを任意に組み合わせて最大10台まで登録できるようにしました。
- GitHub: https://github.com/yo1t/egressview
- Project Page: https://yo1t.github.io/egressview/
- Release v1.3.5: https://github.com/yo1t/egressview/releases/tag/v1.3.5
この記事は「Yamaha 対応のツールを Cisco に広げるとき、何が流用でき、何に留意が必要だったか」の記録です。結論から書くと、新たに必要な Cisco 固有コードは全体の5%弱でした。
できるようになったこと
同じグラフマップ・統計・通信ログを、Cisco の NAT テーブル由来の通信に対しても使えます。宛先ホスト名・組織名・国・脅威フィード照合（Feodo Tracker / ThreatFox / URLhaus / Spamhaus DROP）、MCP 経由の AI エージェント連携も従来どおりです。
| 構成 | 動作 |
|---|---|
| Yamaha RTX のみ | 従来どおり |
| Cisco IOS のみ | NAT変換テーブルから同等の可視化 |
| Yamaha + Cisco 併用 | 同じ通信を重複計上せず、観測した全ルーターを保持 |
| Cisco複数台 / Yamaha複数台 | 同一メーカーを含め、任意の組み合わせで最大10台 |
設定画面もこの通りです。
流用できたもの・書いたもの
| 分類 | 規模（概算） | Cisco対応での扱い |
|---|---|---|
| 保存層（SQLite、履歴、集計） | 大 | そのまま流用 |
| エンリッチ（逆引きDNS、RDAP組織名、Geo） | 大 | そのまま流用 |
| 脅威フィード照合 | 中 | そのまま流用 |
| Web UI（グラフマップ、統計、通信ログ、端末一覧） | 大 | そのまま流用 |
| MCP サーバー / Slack 通知・検出ログ | 中 | そのまま流用 |
| Cisco 固有コード（SSH対話、パーサー、アダプタ） | 841行 | 新規 |
Cisco 専用モジュールは841行で、JavaScript 全体（テスト除く18,105行）の**約4.6%**です。この比率は専用モジュールの規模であり、既存ファイルへの変更量を含む流用率ではありません。それでも、保存・分析・可視化を作り直さずに済みました。
もともと、「ルーター」を抽象化してあったのが良かったと考えています。EgressView の内部では、ルーターは「定期的に接続レコードの配列を返すもの」でしかありません。
// ルーターアダプタが返す共通の接続レコード（概念図）
{ src: '192.168.1.42', dst: '203.0.113.10', dport: 443, proto: 'tcp', srcMac: 'aa:bb:cc:11:02:00' }
この形に変換するアダプタさえ書けば、その先は機種を知らないまま動きます。「対応機種を増やすかもしれないなら、1機種目のうちにデータの正規形と境界を決めておく」——今回いちばん効いた設計判断は、Cisco 対応前に済んでいました。
ただし機種の抽象化だけでは台数を増やせません。kind: cisco という種類と routerId: cisco1 という個体を分離し、scheduler が個体ごとに独立ポーリングすることで、cisco1 / cisco2 / yamaha1 のような構成を特別扱いなしで表現しています。複数ルーターが同じ通信を観測した場合は、通信は自然キー (src, dst, dport, proto) で1件のまま、観測元だけを connection_observations テーブルに routerId 単位で保持します。
留意点 — CLI の出力の仕方
設計レベルの困難ではなく「出力の仕方」への対処でした。対処自体は数行ですが、どれも失敗が沈黙する（エラーにならず、止まる・0件になる）ため、注意深い対応が必要です。
| # | Yamaha との違い | 症状 | 対処 |
|---|---|---|---|
| 1 |
--More-- ページャー |
出力が途中で止まりタイムアウト | 冒頭で terminal length 0 + --More-- 検出時にスペース送信 |
| 2 |
enable の Password: 応答 |
プロンプト待ち正規表現に永遠にマッチしない | 「何を待つか」を差し替え可能にし、Password: とプロンプト両方を待つ |
| 3 | enable 失敗時も一部コマンドは通る | 接続は「成功」なのにデータが永遠に0件 |
# への遷移を検証し、% Invalid input をエラー扱い |
| 4 | MAC 表記が aabb.cc11.0200 形式 |
同じ端末が二重登録される | パーサー入口でコロン区切りへ正規化 |
| 5 | ポーリングループが複数になる | 差分配信の漏れ・二重カウント | 個体ごとに状態を分離し、観測元を junction table に保存 |
なお、2と3は privilege 15 のユーザーでテストしていると気づけません。ログイン直後から特権モードに着地し、enable の分岐が一度も実行されないためです。「手元では動くのにユーザーの環境では動かない」の典型でした。
留意点 — NATテーブルの細かな差
同じ「NAT テーブル」でも、載っている情報が違います。
| 情報 | Yamaha RTX | Cisco IOS |
|---|---|---|
| コマンド | show nat descriptor address N detail |
show ip nat translations |
| プロトコル | TCP / UDP / ICMP / GRE | TCP / UDP / ICMP |
| LAN側IP・ポート | あり | Inside local としてあり |
| 通信先IP・ポート | あり | Outside global としてあり |
| セッションの残存時間 | 実測TTLを取得 |
verbose の left から取得（未対応機は既定値） |
| セッション生成時刻 | なし | verbose の create から取得 |
Cisco は inside/outside × local/global の「NAT の前後」を軸にした語彙、Yamaha は「LAN 側とその通信先」という素直な形で代わりに実測 TTL を持つ——情報の多寡ではなく軸が違うのです。アダプタの仕事は形式変換だけでなく「共通の正規形に何を残すか」の判断で、EgressView では「どの端末がどこへ出ているか」を核にし、片方にしかない情報はオプション扱いにしました。共通レコードを両機種の和集合にすると、3機種目でまた壊れるからです。
この違いは機種固有の強みにもなります。show ip nat translations verbose の create / left を取り込み、Cisco 版ではセッション開始時刻を NAT エントリ生成の推定時刻まで遡れるようになり、TTL も既定値から実測値になりました。verbose 未対応機は自動フォールバックし、Yamaha 側のコードには一切手を入れていません。
3機種目を見据えたリファクタリング
対応作業と同時に、次の機種を簡単に追加できるように4つの改善を行いました。
① アダプタ契約のコード化 — 実装すべき22メソッドを契約として定義し、起動時に検証。3機種目の実装漏れは起動した瞬間にエラーメッセージ付きでわかります。
// router-interface.js（抜粋）
const REQUIRED_METHODS = ['configure', 'connect', 'fetchSessions', /* ...計22 */];
function validateRouterPoller(adapter) {
for (const name of REQUIRED_METHODS) {
if (typeof adapter[name] !== 'function') {
throw new TypeError(`adapter "${adapter.kind}" is missing method: ${name}`);
}
}
}
② SSH 対話ロジックの状態機械（ステートマシン）化 — enable 遷移は SSH コールバックに埋まった「実機がないとテストできない」コードでした。I/O を注入できる純粋な状態遷移関数に切り出し、「enable パスワードが間違っていた場合」のような再現しにくいケースもユニットテストで固定しています。
③ ポーリング状態のポーラー単位分離 — 留意点5（差分配信の漏れ・二重カウント）の恒久対策。「前回配信時刻」などをポーラーごとに持ち、観測点が増えてもループ同士が干渉しません。
④ 負荷と障害分離をゲート化 — fake router を Yamaha 5台 + Cisco 5台・各1,000セッションで動かす自動試験を追加。同時実行は最大3、共通100通信の重複排除でユニーク9,100件、1台を意図的に落としても残り9台の9,000セッションを収集できることを CI で確認します。あわせて履歴を「SQLite に全件・メモリに新しい100,000件」の二層にし、実データ216,582件で常駐メモリを約995MB→約604MB（約39%減）にしました。
結果はテストの数字に出ています: ユニットテスト1,132件（うち Cisco 関連64件） + Playwright E2E。特に②により「実機がないと確かめられない」領域を対話の外周だけに追い込めたことが、品質面のいちばんの成果です。
それでも自動化できないもの
実機での接続確認（SSH の実挙動、実機の NAT 出力形式、ホスト鍵の初回受け入れ）だけは手動で残ります。用意できた実機は Cisco 1台と Yamaha 1台。補足試験として各実機を異なる routerId で2重登録して4個体として並列収集し、同じ Cisco 通信17件・Yamaha 通信178件が両 routerId から観測され、観測元を失わず重複排除できることを確認しました。ただしこれは SSH 並列処理・個体別状態・重複排除の確認であり、異なる物理機器2台の構成や HSRP/VRRP、実フェイルオーバーを検証したものではありません。
ここは対応機種を増やすほど重くなるので、「この機種・この IOS で動いた／動かなかった」という動作報告をもらえれば、と思います。
試し方
| 項目 | 内容 |
|---|---|
| EgressView | v1.3.5（GitHub Release） |
| Node.js | 22 以上 |
| ルーター側 | SSH ログイン + show ip nat translations が実行できること |
| 権限 | privilege 15 のユーザー、または enable パスワード（設定画面に入力欄あり） |
| 動作確認済み環境 | Cisco C841M-4X-JSEC/K9 / IOS 15.5(3)M9 |
詳細手順は Cisco IOS — SSH 設定ガイドにあります。
git clone https://github.com/yo1t/egressview.git
cd egressview
npm install
npm start
ルーターが手元になくてもデモモードで UI を確認できます。
DEMO_MODE=true DEMO_ADMIN_TOKEN=my-token npm start
「この機種・この IOS バージョンで動いた／動かなかった」の報告だけでも大変ありがたいです。Issue・PR も歓迎です。
参考
- ssh2（Node.js の SSH クライアント）: https://github.com/mscdex/ssh2
- Netmiko（Python のネットワーク機器自動化。CLI の違いの対処の実装が参考になります）: https://github.com/ktbyers/netmiko
- 前回記事: Yamaha RTX配下の通信をWebで可視化し、MCPでAIエージェントからアクセスできるようにした話
おわりに
2機種目の対応は、1機種目で対応した抽象化の答え合わせのようなものでした。データの正規形と境界を先に決めてあったおかげで、Cisco 対応の中心は「CLI の出力差異を吸収するアダプタを書く」ことに収まり、専用コードは全体の5%弱となりました。
さらに、将来の対応機種追加と冗長構成を見据え、最大10台のルーターを共通のschedulerとregistryで扱えるようにしました。機種固有の差はアダプタの内側へ閉じ込め、保存・分析・可視化は共通化する。この境界を保てるかぎり、3機種目以降も同じ設計で追加していけると考えています。
免責
こちらの内容にもとづく環境の構築は、自己の責任でお願いします。各種サービス、AIクライアント、APIを利用する場合は、それぞれの利用条件に従ってください。また、ここに記載の全ての内容については個人の意見であり、所属する企業や団体とは関係ありません。
商標について
Cisco、Cisco IOS、Yamaha などの製品名は、各社の商標または登録商標です。EgressView はこれらの企業と提携・承認・後援関係にありません。