今回のテーマではより具体的な例を挙げて、トラフィックの中身をPRTGのフロー系センサーを使用して調査する方法をご紹介いたします。
前編ではフローデータに関連するセンサーとその機能をご紹介しました。後編ではより実践的な使い方をご紹介いたします。
今回の内容は次の通りです。
- PRTGのxFlowセンサー、設定のポイント
- xFlowセンサーのチャンネル定義
- xFlow カスタムセンサーの活用
- その他の機能
- 後編のまとめ
- 補足：注意事項など
PRTGのxFlowセンサー、設定のポイント
フローデータ送信側の設定（ネットワーク機器）
マニュアルにしたがって、xFlowエージェントの設定でPRTGのIPアドレスと宛先UDPポートを指定します。…またみなさまに怒られそうなことを書きましたが、世の中には多くの機器がありますので、私どもも全てについて把握できておりません。申し訳ございませんが個別の機器の設定についてはマニュアルで調べてください。
ただし「フロー収集」の方針についてはあらかじめ検討をしてください。設定によってはトラフィックのダブルカウントが発生して何を計測しているのかわからなくなってしまうからです。
インターフェースで計測できるフロー情報には2つの向きがあります。
- 機器に入ってくる通信を計測したもの<ingress>
- 機器から出ていく通信を計測したもの<egress>
目的によりますが、以下の図のようにどちらかの方法で統一して設定するとわかりやすくなります。
≪方針A：全てのインターフェースのフローを<ingress>で測定する≫
≪方針B：特定のインターフェースのフローを<ingress, egress両方>で測定する≫
「方針B」は測定の対象を限定できる場合に使用します。例えば、サーバーとの通信やインターネットとの通信について、インターフェースを指定して設定します。
計測箇所が明確なので取得したデータがわかりやすいのが利点です。ただし使用する機器によってはこの選択肢は選べないことがあります。またこの図の例ではクライアントPC同士の通信は計測されません。
フローデータ受信側の設定（PRTG）
xFlowセンサーは、どの「デバイス」に追加しても動作します。機能検証時は、ポーリング系のセンサーと異なることをはっきりさせるために、プローブデバイス※にセンサーを追加してもよいでしょう。※プローブデバイスはPRTG自体を疑似的なデバイスとしてPRTGの中で表示したものです。以下、よく使われるNetFlowセンサーとsFlowセンサーを例に、設定のポイントのみ書きます。
≪NetFlowとsFlow共通の設定≫
※２：推奨設定値は『なし』です。今回のブログでは『「その他」チャンネルのみ』を利用する例を紹介しています。
≪NetFlow固有の設定≫
※注：エージェントの設定がデフォルト値1800秒(30分)のとき、通信が継続している場合は30分経過しないとフローデータが送信されません。送信されるまでの間のトラフィックはPRTGで表示されません。⇒それまでデータが見えません。
フローデータがうまく受信できない場合
フローデータがうまく受信できない場合がありますが、単純な設定ミスなのか、ネットワーク経路上のファイアウォールの影響なのか判別しにくいことがあります。メーカー提供のWindows用ツールを使用すると原因を特定しやすくなります。
NetFlow Tester: <https://www.paessler.com/tools/netflowtester>
sFlow Tester: <https://www.paessler.com/tools/sflowtester>
ここでは詳細に解説いたしませんが、基本的な使い方は、PRTGを停止し替わりにツールを動作させて、フローデータの受信確認をします。
- PRTGのPCの上でツールを動作させて、全く何も受信できない場合は、(Windows)ファイアウォールのルールを追加する必要があるかも知れません。設定したUDPポートへの通信が受信ルールで許可されているか確認してください。
- エージェントがあるネットワークセグメントと同一セグメントのWindows PCが利用できる場合は、そのPCでツールを動作させて受信できるか確認します。受信できる場合はエージェントとPRTGの間のファイアウォールの設定を確認します。※テストする間はエージェントのデータ送信先IPをツールが動作するPCのIPへ暫定的に変更します。
xFlowセンサーのチャンネル定義
うまく設定ができたでしょうか？データが受信できるようになると前編のような画面が表示されます。 |
| データテーブル |
このようなデータテーブルが表示されて値が確認できたでしょうか。
今回は受信ができていることを前提に先の説明をいたします。
センサーの設定を見ていただくと、次の「チャンネル構成」セクションがあります。
 |
| チャンネル構成 |
「グループ」には"Intrastructure"など、やや大まかな内容を示す語が使用されており「内容」はもう少し詳細な"DHCP"などの語が使用されています。
「チャンネル構成」では"DHCP","DNS"など詳細に分けたものをチャンネルとするか、"Intrastructure"のようにそれらを合計したグループをチャンネルとするかを、選択することができます。
このグループや内容（チャンネル）には、次のような分類ルールの定義がされています。
≪xFlowセンサーで表示されるチャンネルの定義≫
受信したフローデータの評価は上の定義から順番にされます。
最後の"Various"グループにはOtherUDPとOtherTCPがあります。それより上の定義でマッチしなかったUDPやTCPはここで集計されます。
さらに、この定義のすべてに当てはまらなかったフローデータは「その他」チャンネルで集計されます。「その他」はセンサーが上の定義とは別に提供するチャンネルです。
「Various」と「その他」という似たような意味のチャンネルが、それぞれある理由がおわかりいただけましたでしょうか。
チャンネル定義についての詳しい説明は以下のURLを参照してください。
xFlow カスタムセンサーの活用
上記のチャンネル定義は一般的なものになっておりますので、環境によっては期待しているデータが計測できないことがあります。計測できないフローデータの内訳を確認する方法についてこれからみていきます。前述の標準xFlowセンサーの定義はXMLファイルで設定されています。カスタマイズしてチャンネル定義を変更できますが※、次の場合は「xFlow （カスタム）」センサーを使うと便利です。
- トラフィックの調査のために頻繁にチャンネル定義を変更したい
- センサー毎にチャンネルの定義を変更したい
「xFlow （カスタム）」センサーの設定には「チャンネル定義」のセクションがあります。そのほかの設定は、名前にカスタムが付かない標準xFlowセンサーと同じです。
≪標準のセンサーの定義をカスタム付きセンサー用の定義に変換したもの≫
#1001:HTTP
Protocol[TCP] and ( SourcePort[80] or DestinationPort[80] or SourcePort[8080] or DestinationPort[8080])
#1023:HTTPS
Protocol[TCP] and (SourcePort[443] or DestinationPort[443])
#1024:FTP (Control)
Protocol[TCP] and (DestinationPort[20-21] OR SourcePort[20-21])
#1006:IMAP
(Protocol[TCP] or Protocol[UDP]) and ( DestinationPort[143] or SourcePort[143] or DestinationPort[220] or SourcePort[220] or DestinationPort[993] or SourcePort[993])
#1008:POP3
Protocol[TCP] and (SourcePort[110] or DestinationPort[110] or SourcePort[995] or DestinationPort[995])
#1011:SMTP
Protocol[TCP] and (SourcePort[25] or DestinationPort[25])
#1007:IRC
Protocol[TCP] and (SourcePort[6667] or DestinationPort[6667])
#1025:AIM
Protocol[TCP] and (SourcePort[5190] or DestinationPort[5190])
#1009:RDP
(Protocol[TCP] or Protocol[UDP]) and (SourcePort[3389] or DestinationPort[3389])
#1014:SSH
Protocol[TCP] and (SourcePort[22] or DestinationPort[22])
#1016:Telnet
Protocol[TCP] and (SourcePort[23] or DestinationPort[23])
#1017:VNC
Protocol[TCP] and (SourcePort[5800] or DestinationPort[5800] or SourcePort[5900] or DestinationPort[5900])
#1003:DHCP
Protocol[UDP] and ((SourcePort[68] and DestinationPort[67]) or (SourcePort[67] and DestinationPort[68]))
#1004:DNS
(Protocol[TCP] or Protocol[UDP]) and (SourcePort[53] or DestinationPort[53])
#1005:Ident
Protocol[TCP] and (SourcePort[113] or DestinationPort[113])
#1018:ICMP
Protocol[ICMP]
#1012:SNMP
Protocol[UDP] and (SourcePort[161-162] or DestinationPort[161-162])
#1019:NETBIOS
(Protocol[TCP] OR Protocol[UDP]) AND (DestinationPort[137-139] OR SourcePort[137-139])
#1026:Citrix
Protocol[TCP] and (Port[1494] or Port[2598] or Port[2512])
#1021:OtherUDP
Protocol[UDP]
#1022:OtherTCP
Protocol[TCP]
既に見ていただいたチャンネル定義とほとんど同じです。
- 「#」に続く数字はチャンネルIDです。
- コロンの後はチャンネル名です。
ここで今までのおさらいをしたいと思います。
- チャンネルの定義は上から順番に評価されます。
- 定義に当てはまらないフローデータは「その他」チャンネルに分類されます。
- 「その他」チャンネルはデバッグログに書き出すことができます。
#1021:OtherUDP
Protocol[UDP]
#1022:OtherTCP
Protocol[TCP]
を抜くと不明なTCPとUDPの通信は「その他チャンネル」に分類されてから、デバッグログに書き出すことができます。デバッグログはCSV形式ですのでExcelやテキストエディタで内容を確認することができます。
デバッグログには次のような情報が記録されます。※この例はHTTPS通信です。
≪sFlow V５センサーの例≫
| sFlow V5 | Example |
| Now | 2018/1/12 16:18:01 |
| FromDateTime | 2018/1/12 7:18:01 |
| ToDateTime | 2018/1/12 7:18:01 |
| EthernetType | |
| Protocol | 6 |
| SourceIP | 173.194.22.231 |
| SourcePort | 443 |
| SourceMAC | 00-23-5E-80-87-0E |
| DestinationIP | 192.168.120.9 |
| DestinationPort | 64868 |
| DestinationMAC | 00-1A-EB-96-93-1D |
| Size | 1344000 |
| ChannelID | 1023 |
| ToS | 0 |
| SenderIP | 192.168.120.254 |
| InboundInterface | 5002 |
| OutboundInterface | 0 |
≪NetFlow V9センサーの例≫
| NetFlow | Example |
| Now | 2018/1/12 16:18:10 |
| FromDateTime | 2018/1/12 7:17:47 |
| ToDateTime | 2018/1/12 7:17:54 |
| EthernetType | |
| Protocol | 6 |
| SourceIP | 216.58.197.238 |
| SourcePort | 443 |
| SourceMAC | 00-00-00-00-00-00 |
| DestinationIP | 192.168.81.199 |
| DestinationPort | 52563 |
| DestinationMAC | 00-00-00-00-00-00 |
| Size | 1988 |
| ChannelID | 1023 |
| ToS | 64 |
| SenderIP | 192.168.110.199 |
| InboundInterface | 2 |
| OutboundInterface | 1 |
| SourceASI | 0 |
| DestinationASI | 0 |
| SourceMask | 0 |
| DestinationMask | 24 |
| NextHop | 192.168.110.254 |
| SourceVLAN | 0 |
| DestinationVLAN | 0 |
| FlowID | 0 |
センサーの種類によってログに記録される内容が若干異なります。また全ての項目に常に値が入るとは限りません。太字の個所はNetFlow固有の項目です。
このように、カスタム付きxFlowセンサーとデバッグログを利用すると、受信したフローデータを確認することができます。
次のようなサイクルでチャンネル定義をリファインしていくことができます。
０．xFlow（カスタム）センサーを作成する。
１．デバッグログを確認する。
２．チャンネル定義を変更してxFlow（カスタム）を再作成する。
１．と２．を必要なだけ繰り返す
３．（必要な場合）標準のxFlowセンサーの定義をカスタマイズする。
その他の機能
説明していないxFlowセンサーの機能についていくつかご紹介いたします。センサー全体設定「フィルタリング」
 |
| フィルタリング（フィルタールールの設定） |
- 包含フィルター：条件に一致するフローデータをセンサーのデータとします。
- 除外フィルター：条件に一致したフローデータを除外します。
条件の書式は前掲したｘFlowセンサーで使用できるフィルタールール(英文)と同じです。
カスタムトップリスト
前編で見ていただいたトップリストについての補足です。トップトーカーやトップコネクションのグラフはIP通信の両端を示すために独特な表現になっています。
 |
| トップトーカー |
しかしIPアドレスごとの通信量の上位を確認できれば良いケースでは、次のような単純な円グラフの方が見やすいかもしれません。
 |
| カスタムトップリスト |
PRTGのトップリストは追加することができます。次の4種類から選択できます。
- トップトーカー
- トップコネクション
- トッププロトコル
- カスタム
 |
| トップリストの設定 |
- xFlowセンサーの全般タブでトップリストを追加
- タイプの「カスタム」を選択。
- トップリストフィールドで「IP（統合）」のみを選択します。
デフォルト値と備考については以下の通りです。
| 設定項目 | デフォルト値 | 備考 |
| 期間（分） | 15分 | 長くすると必要なメモリが増えます |
| トップカウント | (上位)100 | 大きくするとメモリ、パフォーマンスに影響します。 |
| リバース DNS | リバース DNS を行う | 「リバース DNS を行う」ためにDNSの逆引きを実行します。「行わない」に変更するとパフォーマンスが向上します。またIPアドレスでのみ表示したい場合も「行わない」に変更してください。 |
| メモリ使用限度 | 10MB | データ受信時にメモリに関するエラーが表示される場合は増やしてください。プローブサービスのメモリ使用量が増えます。 |
後編のまとめ
前編に引き続き後編ではPRTGのxFlowセンサーの実践的な使用方法について解説をしてきました。いかがでしたでしょうか。フローデータを監視したことのない方に興味を持っていただけましたらうれしいです。PRTGはフローコレクター専用のソフトウェアではありませんので、トップリストデータのエクスポートや検索ができません。機能として少しもの足りないところがあるかもしれません。
しかしフリー版でこの機能が使用できるのは大きなメリットです。プロトコルごとのトラフィックについて今まで気になっていた方が最初に使用するフローコレクターとしてはベストかもしれません。また商用ライセンスをご利用の方が、L2レベルのトラフィックと違った視点でネットワーク状況を把握したい場合に、追加コストなしで始められるのもメリットとなるでしょう。
実感していただくためにはPRTGを実際に使っていただくのが一番です。
PRTG Network Monitorは、100センサーまで無料で使用でき、30日間は無制限に評価できます。ぜひ、PRTGのネットワークトラフィック監視機能をお試しください。
PRTG Network Monitorが提供するトラフィック監視機能は以下のリンクを参照してください。
最後まで読んでいただいてありがとうございました。
以下は補足として、本文で触れなかった注意事項を挙げておきます。
以下は補足として、本文で触れなかった注意事項を挙げておきます。
補足：注意事項など
- xFlowセンサーはIPv4のみ対応しています。
- xFlowセンサーのプローブ当たりの推奨最大使用数は５０センサーです。
- xFlowセンサーは使用状況によってPRTGシステムに大きな負荷を与えます。負荷分散が必要になった場合はリモートプローブを増設してしてください。（追加ライセンスコストはありません）
- xFlowセンサーのデバッグログは 「データファイルパス」の下のStreamLogフォルダに出力されます。最大サイズは64MBでStreams Sensor XXXX (1).csv、Streams Sensor XXXX (2).csv の2つのファイルでローテーションします。※「データファイルパス」はサーバーにインストールされているPRTG Administration Toolで確認できます。ファイル名のXXXXの個所はセンサーIDです。
- xFlowセンサーの受信性能はCPU速度よりもコア数に比例します。
- sFlow V5センサーは以下のデータにのみ対応しています。
- sFlowバージョン5のデータグラムのみ
- IPv4のTCPとUDPのみ
- フローフォーマットのみ（カウンターフォーマットは処理できません）
- RAWパケットヘッダーのみ
- 大量のフローデータを受信する場合は、PRTGのコアサーバが動作するPCに高速なハードディスク(SSD)が必要になります。またプローブが動作するPCには高性能なネットワークカードが必要になります。
PRTG Network Monitorが提供するトラフィック監視機能は以下のリンクを参照してください。
