テックブログ

社内インフラの管理者必見!Windowsでネットワークマップを自動作成できるフリーソフトのご紹介

これからSEになりたいビギナーから、無料で社内インフラ管理を楽にしたい情シス管理者まで必見!?

はじめに

こんにちは。HMです。

TWSNMP FCというフリーツールを利用したネットワークマップを用いた監視手法のご紹介をします。「ネットワーク監視」で検索しますと、「ネットワーク監視とは?導入メリットから選び方・おすすめツールまで」など等いろいろ出てきますが、どれも監視対象の機器についての監視に留まり、監視対象までのネットワーク経路にはあまり言及していないように見受けます。

この経路の監視をネットワークマップで表示させると、監視対象の障害なのか、監視対象に至るまでのクラウド基盤、インターネットバックボーン、社内などローカルネットワークの障害なのか一目で切り分けられるようになります。

これらの発生頻度は少ないものの、一度発生すると大規模な障害となって巻き込まれ、障害原因の切り分けに手間と時間もかかり、お客様サービスのダウンタイムに直接関わってくる部分なので、当社としては運用品質に関わる重要な位置づけともなります。

また昨今どの会社でもグループウェアなどSaaS利用は一般化しており、可用性はサービス提供会社の責任範囲として踏み込まないことが多いかと思いますが、ネットワークマップがあるとサービス自体の障害か、経路上の問題なのかもわかりますし、利用しているサービスの障害が実際どれくらいの頻度でおきているか確認できます。

社内インフラ機器の管理にも利用できるので、ITILベースの簡易構成管理をやってみたいという用途にも対応可能なので前置きが長くなりましたが、すぐに設定できるよう要点を絞って設定例をご紹介します。

【手順①】下準備

  1. TWSNMPのインストール:公式ページがとても読みやすいのでこちらを参照ください。
    1. Windows ストア版の要約をするとストアで「Microsoft Store アプリを取得」(ダウンロード)→「開く」→「TWSNMO FC」のデータストアのパスはTWSNMPの設定ファイルの保存先となるので、お好きなパスに変更してください。「起動」ボタンをクリック→ブラウザのURL欄に「http://127.0.0.1:8080」を貼り付けにアクセス→「マップ」をクリック、となります。初回以降の初期ログインアカウントはユーザIDとパスワードのどらも「twsnmp」です。
  2. 監視対象のホスト名、IP Addressをご用意ください。
  3. 調査するローカルネットワーク内にLinux環境TeraTermなどターミナルツールを準備します。
    1. ネットワーク経路の詳細情報は不要で、SaaSや社内インフラのみとりあえず設定だけしたいという方はLinux環境とターミナルツールのインストールもスキップして読み進めてもらって構いません。Windows OSのみでも手間はかかりますが調査は可能です。余裕がある方はOracle VM VirtualBoxなどをインストール(参考:カゴヤのサーバー研究所)し、UbuntuなどLinux OSをインストールしてください。
    2. Teratermの ダウンロード(窓の社)リンクです。

【手順②】ローカルネットワークの調査とライン接続

インストールしただけではまだまだ使えませんね。

TWSNMPをインストールしたPCから接続可能なネットワークの範囲に限りますが、アプリ側で社内インフラなどローカルネットワーク環境は監視対象を自動収集してくれます。

  1. 【重要】監視対象として自前のインフラやサイト等を多く登録する場合、デフォルトのポーリング間隔はお好きな値に変更で問題ありません。ISP や SaaS を多く登録する場合はブラウザの管理画面にログインしたら「システム」→「マップ」とたどり「ポーリング間隔」は60→360に変更しておきます。
    1. 【TIPS】自動登録を進めてしまうと、後から全部設定し直すのはとても手間になるので先に変更しておきます。
  2. タイトル部分「TWSNMP」の文字の横にある「三」→左メニューの「自動発見」を選択
    1. 開始IPと終了IPを入力し、「開始」をクリックするとローカルネットワークの情報を自動で収集してくれます。
  3. 実行状況の完了までしばらく待ち、左メニュー「マップ」を選択すると以下のようになります。
    1. 出てくるノード(PCのアイコン)の数は環境によって変わります!インターネット接続が可能な環境であれば、Gatewayとなるルーターが1つは見つかるはずです。
  4. ライン接続元(ノード1)を左クリック選択→接続先(ノード2)を「Shitf」キーを押しながら左クリックすると「ライン編集」画面が表示されます。ここでノード1とノード2のそれぞれ「ポーリング」から「PING監視」を選択して「OK」をクリックするとライン接続できます。
    1. 【重要】1つ以上「ポーリング(監視)」が設定されていないとライン接続はできません。自動発見されたノードは「PING監視」が設定済みにつき問題ありません。手動でノード登録していたら接続元・接続先それぞれのノードを右クリック→「ポーリング」を設定してからライン接続します。

【中休み】ネットワークマップの補足など

アイコンの色について

  • グレー:ポーリング監視が設定されていないノード。またはノードに設定できるすべての監視のレベルが「停止」となっていることを示します。
  • グリーン:登録されているすべてのポーリング監視が正常であることを示しています。なお、自動発見でノードが登録された際「Ping」監視が自動で設定され、その監視結果としてグリーンでアイコンが表示されています。
  • ピンク:監視レベルが「軽度」のポーリング監視が障害を検知した場合に示される色です。
  • レッド:監視レベルが「重度」のポーリング監視が障害を検知した場合に示される色です。
  • ブルー:設定されている監視レベルに関わらず、障害から復旧したことを示します。

ハブなどIPアドレスを持たない機器について

監視もできず、ライン接続もできませんが、マップの何もないところで右クリック→「新規ノード」→「ネットワーク」アイコンに変更して「保存」。以下のようにライン上に置くだけですが、一応表現はできます。

ノードアイコンのきれいな整列方法

L2スイッチ、L3ルーター、Firewallなどの機器がある場合、同じレイヤー機器は同じ列に並べるときれいにマップを作ることが出来ます。

また、マップ上の何もないところを右クリック→「グリッド整列」できれいに並べることができますが、ちょっと慣れが必要です。ノードアイコンを置きたいところの少し左上に置き、グリッド整列を繰り返すとうまく整列できます。

VM環境はESXiの先に仮想OSのノードを並べておくとVM基盤障害をすぐに理解できるようになります。

【手順③】監視対象までの経路の確認

ローカルネットワークのマップが作れたところで、次はSaaSやクラウド基盤のマップに取り掛かるための調査をしましょう。

Linux OSでのネットワーク経路の方法

Linux環境にTeraTermなどターミナルツールを利用してログインし、「Traceroute -A <監視対象ドメイン名>」と入力してEnterキーを押します。以下は当社が利用しているメールサービスのドメインに対する実行結果の例です。

[xxxxx@xxxxx ~]$ ~]$ traceroute -A mdnicky.maildealer.jp
traceroute to mdnicky.maildealer.jp (211.14.7.188), 30 hops max, 60 byte packets
1 gateway (192.168.0.1) [*] 0.240 ms 0.195 ms 0.133 ms 
 ↑ ←ココまでが社内ネットワーク
 ↓ ←ココからココからインターネット
2 113x33x37x97.ap113.ftth.ucom.ne.jp (113.33.37.XXX) [AS17506] 1.878 ms 2.042 ms 2.213 ms
3 221x240x59x161.ap221.ftth.ucom.ne.jp (221.240.59.XX) [AS17506] 3.200 ms 3.449 ms 3.632 ms
4 210.79.2.169 (210.79.2.XXX) [AS17506] 2.000 ms 2.216 ms 2.429 ms
5 122x220x164x208.ap122.ftth.ucom.ne.jp (122.220.164.XX) [AS17506] 0.774 ms 0.760 ms 122x220x164x228.ap122.ftth.ucom.ne.jp (122.220.164.XXX) [AS17506] 0.756 ms
 ↑
(IX)ISP間接続
 ↓ 
6 163.139.77.93 (163.139.77.XX) [AS2519] 1.339 ms 1.564 ms 2.061 ms
7 163.139.37.246 (163.139.37.XXX) [AS2519] 132.680 ms 1.475 ms 1.404 ms
 ↑
(IX)ISP間接続
 ↓
8 210.173.176.34 (210.173.176.XXX) [AS7521] 1.348 ms 1.245 ms 1.601 ms
9 * * *
 ↑
(IX)ISP間接続
 ↓
10 AS65000.xe-0-1-7.tedge0503.newote.bbtower.ad.jp (211.14.17.XXX) [AS9607] 1.883 ms 1.466 ms 1.440 ms
11 203x141x62x73.bbtower.ad.jp (203.141.62.XXX) [AS9607] 8.635 ms 8.613 ms 9.403 ms

黄色いマーカーの付いたASから始まるAS番号に注目してください。

  • TIPS】AS番号とは「インターネットの管理セグメントにアサインされる番号」。
    • 参考1:IT用語辞典 e-words様→リンク
    • 参考2:AS番号が持っているIPアドレス調査→リンク
    • 参考3:AS番号自体についての調査→リンク
  • 【TIPS】IX(インターネットエクスチェンジ)とは、インターネットトラフィックの交換を可能とする相互接続ポイント。

次に1つずつAS番号を「whoisコマンド」で調べていきます。

[xxxxx@xxxxx ~]$ whois AS17506
[ JPNIC database provides information regarding IP address and ASN. Its use   ]
[ is restricted to network administration purposes. For further information,  ]
[ use 'whois -h whois.nic.ad.jp help'. To only display English output,        ]
[ add '/e' at the end of command, e.g. 'whois -h whois.nic.ad.jp xxx/e'.      ]

Autonomous System Information: [AS情報]
a. [AS番号]                     17506
b. [AS名]                       UCOM
f. [組織名]                     アルテリア・ネットワークス株式会社
g. [Organization]               ARTERIA Networks Corporation
m. [管理者連絡窓口]             JP00179911
n. [技術連絡担当者]             JP00179911
q. [Abuse]
o. [IMPORT]
p. [EXPORT]
[割当年月日]                    2001/01/19
[最終更新]                      2019/08/09 15:40:20(JST)

whoisコマンドで確認できた社名の略称などで1ISPにつき1つ新規ノードとして登録し、ライン接続をしていきます。なお、同じAS番号は1ノードとしてまとめ、トレース元から近い方=ISPの玄関側のIPアドレスにて登録しています。

Windowsの場合

Linuxのtracerouteに似たtracert コマンドにて調査可能ですが、AS番号は確認できません。またwhoisコマンドも使えないので手間が掛かることはご承知おきください。

  1. 「スタート」キー→「cmd」と入力→コマンドプロンプトを開きます
  2. tracert <調査対象のドメイン名>」を入力してEnterキーを押し、結果を確認します。
  3. 出てきたIPアドレスをひたすらwhoisサイトで調べ、ISPごとにまとめて新規ノードとして登録し、ライン接続をします。なお、LinuxのtracerouteはUDP、tracertはTCPを利用したりといった違いから、コマンド結果も若干違いは出ます。
C:\Users\xxxxx>tracert mdnicky.maildealer.jp
mdnicky.maildealer.jp [211.14.7.188] へのルートをトレースしています
経由するホップ数は最大 30 です:
  1     1 ms     1 ms     1 ms  192.168.0.1
  2     2 ms     3 ms     4 ms  113x33x37xxx.apxxx.ftth.ucom.ne.jp [113.33.37.xx]
  3     4 ms     3 ms     2 ms  221x240x59x161.ap221.ftth.ucom.ne.jp [221.240.59.161]
  4     2 ms     2 ms     3 ms  210.79.2.169
  5     2 ms     2 ms     3 ms  122x220x164x228.ap122.ftth.ucom.ne.jp [122.220.164.228]
  6     4 ms     3 ms     2 ms  163.139.77.93
  7     3 ms     6 ms     9 ms  163.139.37.242
  8    22 ms     4 ms     2 ms  210.173.176.34
  9     *        *        *     要求がタイムアウトしました。
 10     4 ms     9 ms     4 ms  AS65000.xe-0-1-7.tedge0503.newote.bbtower.ad.jp [211.14.17.17]
 11     6 ms     8 ms     4 ms  203x141x62x73.bbtower.ad.jp [203.141.62.73]
 12     *        *        *     要求がタイムアウトしました。
(略)
トレースを完了しました。

クラウド基盤の正常性確認について

サービス自体の正常性はなかなか外部から確認は難しいのですが、コントロールパネル(コンパネ)はURLがあり、ドメインからIPアドレスもわかるので、ここまでのトレース調査は可能です。ニフクラを例に調べてみます。

  1. ニフクラのログインURLを検索してアクセスする。
  2. ドメインが「sso.nifcloud.com」であることがわかったので、IPを調べます。
  3. Windowsならコマンドプロンプトで「nslookup <ドメイン>」、Linuxなら「dig <ドメイン>」でIPアドレスを取得します。
  4. トレースコマンドを打って経路を調べます。

[xxxxx@xxxxx ~]$ traceroute -A 222.158.207.68
traceroute to 222.158.207.68 (222.158.207.68), 30 hops max, 60 byte packets
1 gateway (192.168.0.1) [*] 0.231 ms 0.183 ms 0.141 ms
 ↑ ←ココまでが社内ネットワーク
 ↓ アルテリア・ネットワークス株式会社(UCOM)
2 113x33x37xxx.apxxx.ftth.ucom.ne.jp (113.33.37.xx) [AS17506] 4.958 ms 5.144 ms 5.334 ms
3 221x240x59x161.ap221.ftth.ucom.ne.jp (221.240.59.161) [AS17506] 2.944 ms 3.237 ms 3.509 ms
4 210.79.2.169 (210.79.2.169) [AS17506] 1.868 ms 2.142 ms 2.385 ms
5 122x220x164x228.ap122.ftth.ucom.ne.jp (122.220.164.228) [AS17506] 0.861 ms 122x220x164x208.ap122.ftth.ucom.ne.jp (122.220.164.208) [AS17506] 0.875 ms 0.885 ms
 ↑ アルテリア・ネットワークス株式会社(UCOM)
(IX)ISP間接続
 ↓ アルテリア・ネットワークス株式会社(VECTANT)
6 163.139.77.93 (163.139.77.93) [AS2519] 1.045 ms * *
7 163.139.128.74 (163.139.128.74) [AS2519] 6.914 ms 163.139.128.78 (163.139.128.78) [AS2519] 7.224 ms 7.171 ms
8 163.139.136.137 (163.139.136.137) [AS2519] 7.394 ms 7.368 ms 7.397 ms
 ↑ アルテリア・ネットワークス株式会社(VECTANT)
(IX)ISP間接続
 ↓ 株式会社インターネットイニシアティブ(IIJ)
9 210.130.133.165 (210.130.133.165) [AS2497] 7.597 ms 202.232.9.169 (202.232.9.169) [AS2497] 1.878 ms 210.130.133.165 (210.130.133.165) [AS2497] 7.482 ms
10 osk004bb00.IIJ.Net (58.138.106.185) [AS2497] 7.521 ms tky001bb00.IIJ.Net (58.138.101.25) [AS2497] 1.467 ms osk004bb01.IIJ.Net (58.138.106.157) [AS2497] 7.841 ms
11 osk004ix50.IIJ.Net (58.138.107.22) [AS2497] 7.777 ms osk004ix51.IIJ.Net (58.138.106.126) [AS2497] 7.364 ms osk004ix51.IIJ.Net (58.138.81.154) [AS2497] 7.554 ms
 ↑ 株式会社インターネットイニシアティブ(IIJ)
(IX)ISP間接続
 ↓ INTERNET MULTIFEED
12 210.173.179.9 (210.173.179.9) [AS7521] 8.452 ms 202.232.1.186 (202.232.1.186) [AS2497] 3.462 ms 210.173.179.17 (210.173.179.17) [AS7521] 8.343 ms
 ↑ INTERNET MULTIFEED
(IX)ISP間接続
 ↓ NTT Communications Corporation(OCN)
13 122.28.104.121 (122.28.104.121) [AS4713] 2.296 ms 221.184.13.1 (221.184.13.1) [AS4713] 8.846 ms 221.184.13.5 (221.184.13.5) [AS4713] 9.011 ms
14 125.170.96.33 (125.170.96.33) [AS4713] 11.590 ms 153.149.219.145 (153.149.219.145) [AS4713] 9.805 ms 125.170.96.33 (125.170.96.33) [AS4713] 11.185 ms
15 125.170.97.73 (125.170.97.73) [AS4713] 11.257 ms 122.1.245.189 (122.1.245.189) [AS4713] 9.210 ms 211.0.211.230 (211.0.211.230) [AS4713] 7.221 ms
16 122.1.245.206 (122.1.245.206) [AS4713] 8.958 ms 125.170.97.130 (125.170.97.130) [AS4713] 10.011 ms 122.1.245.206 (122.1.245.206) [AS4713] 9.536 ms
 ↑ NTT Communications Corporation(OCN)
(IX)ISP間接続
 ↓ 富士通株式会社(INFOWEB)
17 133.160.232.130 (133.160.232.130) [AS2510] 5.654 ms 122.1.245.66 (122.1.245.66) [AS4713] 8.450 ms 122.1.245.70 (122.1.245.70) [AS4713] 8.901 ms
 ↑
(IX)ISP間接続
 ↓ NTT Communications Corporation(OCN)
18 211.0.211.190 (211.0.211.190) [AS4713] 11.962 ms 211.0.211.230 (211.0.211.230) [AS4713] 14.042 ms 12.316 ms
 ↑ NTT Communications Corporation(OCN)
(IX)ISP間接続
 ↓ NeuStar, Inc.(ULTRADDOS)/ 富士通株式会社(INFOWEB)
19 61.121.125.11 (61.121.125.11) [AS19905/AS2510] 4.737 ms 133.160.233.54 (133.160.233.54) [AS2510] 11.250 ms 133.160.233.38 (133.160.233.38) [AS2510] 12.919 ms
20 133.160.232.130 (133.160.232.130) [AS2510] 12.331 ms 133.160.232.134 (133.160.232.134) [AS2510] 13.245 ms 133.160.232.130 (133.160.232.130) [AS2510] 13.560 ms
21 133.160.138.14 (133.160.138.14) [AS2510] 13.687 ms 13.197 ms *
22 61.121.125.11 (61.121.125.11) [AS19905/AS2510] 13.889 ms * *
23 222.158.207.68 (222.158.207.68) [AS2510] 10.993 ms 13.757 ms 11.073 ms

【ポイント】上記のような結果であれば、18番目のAS4713は13番目で既出なので、障害ポイントとしては分けるのが適当かもしれませんが、障害状況を確認する先としては同一となるので無視して構いません。同様に19番目の「AS19905/AS2510」について、「AS2510」は既出で無視しますが「AS19905」は初出なのでこちらで新規ノードを登録し、あとは最後の23番目まで既出となるので、最終監視対象のコンソールのIPにたどり着いたものとしてマップのラインを接続していきます。

【TIPS】アルテリアネットワークスはグローバルアクセス(当時はGALと呼ばれてました)から始まりVectant、UCOM、つなぐコミュニケーションズなど合併していますが、ネットワーク上は別として分かれており、障害情報の確認先も分かれているので別ノードとして扱いましょう

【完成】いろいろ頑張った結果

    • 同じネットワークレイヤーのノードが横列で揃えています。冗長構成はループに見えてしまうので、主回線のラインを太くして見やすくします。前述の同種レイヤー機器の並べ方や、VM環境の作り方などご参考になれば。

障害を検知したときのサンプル

上図は意図的に障害ステータスにしたものです。監視対象で障害を検知しているのはIIJ回線で障害が起きたことが原因であると一目でわかります。仮にローカルネットワークの機器で検知した場合は機器の復旧措置が必要となりますが、勝手に持ち去られたり、機器を外されてしまったり等という事も考えられますので社内機器の管理にも役立ちます。

最後に

ノードの登録情報には「説明」欄があり、物理機の場合は自社管理の資産番号や購入日、ラック番号/U数など設置情報、OSバージョンなど登録しておくことが可能です。

なお、ISPから見ると大量のPingはただのDoS攻撃と同じとなってしまいますし、AWSなどはPingを投げてくれるなと明言していることもあり、ISPへのポーリング間隔は5分以下にはしないようご配慮ください

今回はざっくり紹介しました。

ただ、詳細な経路の確認はICMPを返さない通信機器も多くありますし、SaaS側でCDNやWAFなどを利用しているとそちらのサービスへ経路として誘導されていたり、Webでリダイレクトされていたり、DNSラウンドロビンで毎回経路が違っていたり、往路と復路が違う経路の場合は表現できないことなど、実際プロトコルレベルの経路調査とその表現には限界もありますが、社内ネットワークに関しては概ね問題なく管理できますし、ここ10年近くこのような形で運用していますが特に大きな問題にはでくわしていないので恐らく大丈夫でしょう。

私自身TWSNMPのリニューアル版機能を使いこなせておりませんが、AIやレポートなど分析結果の役立て方などわかりましたら、また改めてご紹介させていただきます。

TWSNMPでISP、またはクラウドベンダーの障害を検知した後は、当該ベンダーからの情報を参照し復旧見込みなど対応状況を確認する必要があるので、以下にまとめておきます。経年によるリンク切れなどはご容赦ください。

ISP、クラウドベンダーの障害情報源 まとめ

謝辞

15年ほどでしょうか。TWSNMPには大変お世話になっております。ローカル内の運用で、バージョンアップの確認もおろそかだったこともあり、2021年に最新技術でリニューアルされたのに気付いたのは2022年の後半に入ってからでした。ただ旧アプリ版で使えた「グリッド整列」の機能がなかったため、GitHubからお願いさせていただいたところ、たまたまアップデートのリリースと被ったとは仰っていましたが1日と経たず実装していただけました。(※ホントにたまたまだったので、いつも即実装などとは考えないようご配慮ください)

その節は本当にありがとうございました。これからも陰ながら応援させていただきます。

最後までお読みいただきましてありがとうございました。
今後ともネットアシストをよろしくお願いいたします。

この記事をシェアする

  • facebook
  • twitter
  • hatena
  • line
URLとタイトルをコピーする

実績数30,000件!
サーバーやネットワークなど
ITインフラのことならネットアシストへ、
お気軽にご相談ください