IPトラフィックアカウンティングの整理の原則

遅かれ早かれ、管理者は管理者から「ネットワークにアクセスするユーザーとダウンロード数を計算する」という指示を受け取ります。 プロバイダーの場合は、「誰でも参加させ、支払いを受け取り、アクセスを制限する」タスクで補足されます。 考慮すべきこと どうやって？ どこ？ 断片的な情報がたくさんあり、構造化されていません。 初心者の管理者を退屈な検索から救い、一般的な知識と材料への有用なリンクを提供します。
この記事では、ネットワークトラフィックの収集、アカウンティング、および制御を整理する原則について説明します。 問題を検討し、ネットワークデバイスから情報を取得する可能な方法をリストします。

これは、トラフィックおよびITリソースの収集、会計、管理、および請求に関する一連の記事の最初の理論的な記事です。

インターネットアクセス構造

一般に、ネットワークアクセス構造は次のとおりです。

• 外部リソース-すべてのサイト、サーバー、アドレスなど、制御するネットワークに属さないものを含むインターネット。
• アクセスデバイスは、ルーター（ハードウェア、またはPCベース）、スイッチ、VPNサーバー、またはハブです。
• 内部リソース-ネットワーク、ネットワークでの操作を考慮または制御する必要があるコンピューター、サブネット、サブスクライバーのセット。
• 管理サーバーまたは会計サーバー-専用のソフトウェアを実行するデバイス。 機能的にソフトウェアルーターと組み合わせることができます。

この構造では、ネットワークトラフィックは外部リソースから内部デバイスへ、またはその逆にアクセスデバイスを介して流れます。 トラフィック情報を管理サーバーに送信します。 管理サーバーはこの情報を処理し、データベースに保存し、表示し、ロックコマンドを発行します。 ただし、アクセスデバイス、方法、収集および管理方法のすべての組み合わせに互換性があるわけではありません。 さまざまなオプションについて以下で説明します。

ネットワークトラフィック

まず、「ネットワークトラフィック」の意味と、ユーザーデータのストリームから抽出できる有用な統計情報を判断する必要があります。
支配的なインターネットワーキングプロトコルは、依然としてIPバージョン4です。 IPプロトコルは、OSIモデルの第3レベル（L3）に対応しています。 送信者と受信者間の情報（データ）はパケットにパッケージ化されます-ヘッダーと「ペイロード」を持ちます。 ヘッダーは、パケットの送信元と送信元（送信者と受信者のIPアドレス）、パケットサイズ、ペイロードの種類を決定します。 ネットワークトラフィックの主要部分は、UDPおよびTCPのペイロードを持つパケットで構成されます-これらは、第4レベル（L4）のプロトコルです。 アドレスに加えて、これら2つのプロトコルのヘッダーには、データを転送するサービスの種類（アプリケーション）を決定するポート番号が含まれています。



ワイヤー（または無線）を介してIPパケットを送信するために、ネットワークデバイスは、それを第2レベル（L2）のプロトコルパケットで「ラップ」（カプセル化）する必要があります。 このタイプの最も一般的なプロトコルはイーサネットです。 「ワイヤへの」実際の送信は、第1レベルです。 通常、アクセスデバイス（ルーター）は、4番目より高いレベルのパケットヘッダーを分析しません（例外はスマートファイアウォールです）。
データパケットのL3およびL4ヘッダーからのアドレス、ポート、プロトコル、および長さカウンターのフィールドからの情報は、アカウンティングおよびトラフィック管理で使用される「ソースマテリアル」を構成します。 送信される情報の実際の量は、IPヘッダーの長さフィールドにあります（ヘッダー自体の長さを含む）。 ところで、 MTUメカニズムによるパケットの断片化により、送信されるデータの総量は常にペイロードサイズよりも大きくなります。

このコンテキストで対象となるIPおよびTCP / UDPパケットフィールドの合計の長さは、合計パケット長の2〜10％です。 この情報をすべてバッチで処理して保存すると、十分なリソースがありません。 幸いなことに、圧倒的な量のトラフィックは、外部と内部のネットワークデバイス間の「ダイアログ」、いわゆる「フロー」のセットで構成されるように構成されています。 たとえば、単一の電子メール転送操作（SMTPプロトコル）の一部として、クライアントとサーバーの間でTCPセッションが開かれます。 パラメータ{発信元IPアドレス、発信元TCPポート、宛先IPアドレス、宛先TCPポート}の定数セットによって特徴付けられます。 バッチベースで情報を処理および保存する代わりに、ストリームパラメータ（アドレスおよびポート）、および追加情報（各側に送信されたパケットの長さの数と合計、オプションでセッションの期間、ルーターインターフェイスのインデックス、ToSフィールドの値など）を保存する方がはるかに便利です。 このアプローチは、セッションが終了した瞬間を明示的にキャプチャできるコネクション型プロトコル（TCP）にとって有益です。 ただし、非セッション指向のプロトコルの場合、タイムアウトなどによってストリームレコードを集約し、論理的に終了することもできます。 以下は、トラフィックフローに関する情報を記録する独自の課金システムの SQLデータベースからの抜粋です。



アクセスデバイスはアドレス（ NAT 、マスカレード）を変換して、単一の外部パブリックIPアドレスを使用してローカルネットワーク上のコンピューターのインターネットアクセスを整理することに注意してください。 この場合、特別なメカニズムがIPアドレスとトラフィックパケットのTCP / UDPポートの置換を実行し、動的変換テーブルに従って内部（インターネット上でルーティング不可能な）アドレスを置き換えます。 この構成では、ネットワークの内部ホストのデータを正しくアカウンティングするために、ブロードキャストの結果が内部アドレスをまだ「非個人化」しないような方法で統計を取得する必要があることを覚えておく必要があります。

トラフィック/統計情報を収集する方法

アクセスデバイス自体（PCルーター、VPNサーバー）で通過するトラフィックに関する情報を、このデバイスから別のサーバー（NetFlow、SNMP）に転送するか、「ワイヤから」（タップ、SPAN）転送することに関する情報を削除および処理できます。 すべてのオプションを順番に分析しましょう。

PCルーター

Linuxを実行しているPCに基づくアクセスデバイス（ルーター）という最も単純なケースを考えてください。

このようなサーバー、アドレス変換、およびルーティングの構成方法については、多くのことが書かれています。 次の論理的なステップ、つまりそのようなサーバーを通過するトラフィックに関する情報を取得する方法に関する情報に興味があります。 3つの一般的な方法があります。

• libpcapライブラリを使用してサーバーのネットワークカードを通過するパケットの傍受（コピー）
• 統合ファイアウォールを通過するパケットの傍受
• パッケージ統計（前述の2つの方法のいずれかで取得）をnetflow集約情報ストリームに変換するためのサードパーティツールの使用

Libpcap

最初のケースでは、フィルター（ man pcap-filter ）を通過した後、インターフェースを通過するパッケージのコピーは、このライブラリーを使用して作成されたサーバー上のクライアントプログラムによって要求できます。 パケットは、第2レベルのヘッダー（イーサネット）で到着します。 取得する情報の長さを制限できます（ヘッダーの情報のみに関心がある場合）。 そのようなプログラムの例は、 tcpdumpおよびWiresharkです。 Windowsにはlibpcapの実装があります 。 PCルーターでアドレス変換を使用する場合、このような傍受は、ローカルユーザーに接続された内部インターフェイスでのみ実行できます。 外部インターフェイスでは、ブロードキャスト後、IPパケットにはネットワークの内部ホストに関する情報は含まれません。 ただし、この方法では、サーバー自体がインターネット上で生成したトラフィックを考慮することはできません（Webまたはメールサービスが実行されている場合に重要です）。

libpcapの作業にはオペレーティングシステムのサポートが必要であり、現在は単一のライブラリをインストールすることになります。 同時に、パケットを収集するアプリケーション（ユーザー）プログラムは次のことを行う必要があります。

• 必要なインターフェースを開きます
• 受信したパケットを通過させるフィルター、キャプチャした部分のサイズ（snaplen）、バッファーのサイズ、
• promiscパラメータを設定します。これにより、ネットワークインターフェイスが、このインターフェイスのMACアドレスにアドレス指定されるだけでなく、通過するすべてのパケットのキャプチャモードになります。
• 各受信パケットで呼び出される関数（コールバック）をインストールします。

選択されたインターフェースを介してパケットが送信されると、フィルターを通過した後、この関数はイーサネット、（VLAN）、IPなどを含むバッファーを受信します。 ヘッダー、snaplenまでの合計サイズ。 libcapライブラリはパッケージをコピーするため、その助けを借りてパッセージをブロックすることは不可能です。 この場合、トラフィックの収集および処理プログラムは、代替方法を使用する必要があります。たとえば、スクリプトを呼び出して、指定されたIPアドレスをトラフィックブロッキングルールに入れる必要があります。

ファイアウォール

ファイアウォールを通過するデータをキャプチャすると、アドレス変換が機能している場合でも、サーバー自体のトラフィックとネットワークユーザーのトラフィックの両方を考慮することができます。 この場合の主なことは、キャプチャルールを正しく作成し、適切な場所に配置することです。 このルールは、システムのライブラリへのパッケージの転送をアクティブにし、そこからトラフィックアカウンティングおよび制御アプリケーションがパッケージを受信できます。 Linuxでは、iptablesがファイアウォールとして使用され、ipq、 netfliter_queue、またはulogがインターセプターとして使用されます。 OC FreeBSDの場合-tee やdivertなどのルールを持つipfw。 いずれの場合でも、ファイアウォールメカニズムは、次の方法でユーザープログラムを操作する機能によって補完されます。

• ユーザープログラム-トラフィックハンドラーは、システムコールまたはライブラリを使用してシステムに登録します。
• ユーザープログラムまたは外部スクリプトは、ルールをファイアウォールに設定します。ファイアウォールは、選択されたトラフィックを（ルールに従って）ハンドラー内に「ラップ」します。
• パケットを渡すたびに、プロセッサはその内容をメモリバッファ（IPヘッダーなど）の形式で受信します。処理（アカウンティング）後、プログラムはオペレーティングシステムのカーネルにそのようなパッケージで次に何をするかを指示する必要があります-ドロップするか、渡すか。オプションとして、可能です。変更したパッケージをカーネルに渡します。

IPパケットはコピーされず、分析ソフトウェアに送信されるため、それを「イジェクト」することが可能になり、特定のタイプのトラフィック（選択したローカルネットワークサブスクライバーなど）を完全または部分的に制限できます。 ただし、アプリケーションプログラムがその決定に関するカーネルへの応答を停止（ハングなど）した場合、サーバーを通過するトラフィックは単にブロックされます。
大量の送信トラフィックを伴う説明されたメカニズムは、サーバーからサーバーに過度の負荷をかけることに注意してください。これは、カーネルからユーザープログラムへのデータの絶え間ないコピーに関連しています。 この欠点は、OSカーネルレベルで統計を収集する方法を奪われ、 NetFlowプロトコルを使用してアプリケーションプログラムに集約された統計を発行することです。

ネットフロー

このプロトコルは、トラフィックのアカウンティングと分析のためにルーターからトラフィック情報をエクスポートするためにシスコシステムズによって開発されました。 最も人気のあるバージョン5は、受信者に、いわゆるフローレコードの形式で過去のトラフィックに関する情報を含むUDPパケットの形式の構造化データのストリームを提供します。


トラフィック情報の量は、トラフィックよりも数桁少ないです。これは、大規模な分散ネットワークで特に当てはまります。 もちろん、netflowの統計を収集するときに情報の転送をブロックすることは不可能です（追加のメカニズムが使用されない限り）。
現在、このプロトコルのさらなる開発が普及しています-バージョン9、フローレコードのテンプレート構造に基づいて、他のメーカーのデバイスの実装（ sFlow ）。 最近、IPFIX標準が採用されました。これにより、統計をより深いレベルのプロトコル（たとえば、アプリケーションタイプごと）で送信できます。
netflowソース（エージェント、プローブ）の実装は、上記のメカニズム（flowprobe、 fprobe 、 softflowd ）で実行されるユーティリティとOSカーネル（FreeBSD： ng_netgraph 、Linux： ipt_neflow ）の両方で実行されるユーティリティの形で、PCルーターで利用できます。 ソフトウェアルーターの場合、netflow統計ストリームはルーター自体でローカルに受信および処理されるか、ネットワーク（UDPを介した送信プロトコル）を介して受信デバイス（コレクター）に送信されます。

コレクタープログラムは、多くのソースから情報を一度に収集でき、アドレススペースが交差している場合でもトラフィックを区別できます。 nprobeなどの追加ツールを使用して、追加のデータ集約、ストリーム分割、またはプロトコル変換を実行することもできます。これは、多数のルーターで大規模な分散ネットワークを管理する場合に重要です。

Netflowエクスポート機能は、シスコシステムズ、Mikrotik、および他のいくつかによってサポートされています。 同様の機能（他のエクスポートプロトコルを使用）は、ネットワーク機器のすべての主要メーカーによってサポートされています。

Libpcap「外側」

タスクを少し複雑にしましょう。 アクセスデバイスがサードパーティのハードウェアルーターである場合はどうなりますか？ たとえば、D-Link、ASUS、Trendnetなど。 その上に、データ取得用の追加ソフトウェアを配置することはほとんど不可能です。 または、インテリジェントアクセスデバイスがありますが、構成することはできません（権限がないか、プロバイダーによって制御されています）。 この場合、パケットをコピーする「ハードウェア」手段を使用して、アクセスデバイスと内部ネットワークのジャンクションでトラフィック情報を直接収集できます。 この場合、イーサネットパケットのコピーを受信するには、専用のネットワークカードを備えた別のサーバーが必要になります。
サーバーは、上記のlibpcapメソッドに従ってパケット収集メカニズムを使用する必要があり、私たちのタスクは、これに割り当てられたネットワークカードの入力にアクセスサーバーを残すデータストリームと同じデータストリームを送信することです。 これを行うには、次を使用できます。

• イーサネットハブ（ハブ）：すべてのポート間で無差別にパケットを単に転送するデバイス。 現代の現実では、それはほこりの多い倉庫のどこかにあり、この方法を使用することはお勧めできません：信頼性の低い、低速（1ギガビット/秒の速度でハブはありません）
• イーサネット-ミラーリング機能を備えたスイッチ（ミラーリング、 SPANポート 。最新のインテリジェント（および高価な）スイッチを使用すると、リモート（RSPAN）を含む別の物理インターフェース、VLANのすべてのトラフィック（着信、発信、両方）を指定ポートにコピーできます
• ハードウェアスプリッター 。1つではなく2つのネットワークカードを収集するためのインストールが必要になる場合があり、これはメインシステムのネットワークカードに追加されます。

当然、アクセスデバイス（ルーター）で許可されている場合、SPANポートを構成できます（Cisco Catalyst 6500、Cisco ASA）。 Ciscoスイッチのこの設定の例を次に示します。
monitor session 1 source vlan 100 !
monitor session 1 destination interface Gi6/3!

SNMP

制御下にルーターがない場合、netflowと通信する必要はなく、ユーザーのトラフィックの詳細に関心がない場合はどうでしょう。 これらは管理されたスイッチを介してネットワークに接続されているだけで、各ポートに落ちるトラフィックの量を大まかに見積もる必要があります。 ご存知のように、サポートをリモートで制御できるネットワークデバイスは、ネットワークインターフェイスを通過するパケット（バイト）のカウンターを表示できます。 それらをポーリングするには、標準化されたSNMPリモート管理プロトコルを使用するのが正しいでしょう。 これを使用すると、指定されたカウンターの値だけでなく、インターフェースの名前や説明、インターフェースを通して見えるMACアドレス、その他の有用な情報など、他のパラメーターも取得できます。 これは、コマンドラインユーティリティ（ snmpwalk ）、グラフィカルSNMPブラウザー、およびより複雑なネットワーク監視プログラム（ rrdtools 、 cacti 、 zabbix 、 whats up goldなど）の両方によって行われます。 ただし、この方法には2つの重大な欠点があります。

• トラフィックは、同じSNMPを使用してインターフェイスを完全に無効にすることによってのみブロックできます
• SNMPトラフィックカウンターは、イーサネットパケットの長さの合計（さらに、ユニキャスト、ブロードキャスト、およびマルチキャストを別々に）を参照しますが、前述のツールの残りはIPパケットに関連する値を提供します。 これにより、イーサネットヘッダーの長さに起因するオーバーヘッドにより、顕著な差異（特に短いパケット）が発生します（ただし、これはL3_byte = L2_byte-L2_packets * 38）。

VPN

これとは別に、アクセスサーバーへの接続を明示的に確立することにより、ネットワークへのユーザーアクセスのケースを検討する価値があります。 古典的な例は古きよきダイヤルアップであり、これは現代世界ではリモートアクセスVPNサービス （PPTP、PPPoE、L2TP、OpenVPN、IPSEC）に類似しています。

アクセスデバイスは、ユーザーのIPトラフィックをルーティングするだけでなく、専用のVPNサーバーでもあり、内部でユーザートラフィックが送信される論理トンネル（多くの場合暗号化）を終端します。
このようなトラフィックを考慮するには、上記のすべてのツール（およびポート/プロトコルによる詳細な分析に適しています）と、VPNアクセス制御ツールを提供する追加メカニズムの両方を使用できます。 まず、 RADIUSプロトコルについて説明します。 彼の作品はかなり複雑なトピックです。 VPNサーバー（RADIUSクライアント）へのアクセスの制御（承認）は、属性（制限の有効なユーザー）のデータベース（テキストファイル、SQL、Active Directory）を持つ特別なアプリケーション（RADIUSサーバー）によって制御されることを簡単に述べます。接続速度、割り当てられたIPアドレス）。 認可プロセスに加えて、クライアントは定期的にサーバーにアカウンティングメッセージを送信します。これには、送信されたバイトカウンターやパケットカウンターなど、現在動作している各VPNセッションのステータスに関する情報が含まれます。

おわりに

上記の交通情報を収集するすべての方法をまとめてみましょう。


短い要約を要約します。 実際には、ソフトウェアおよびハードウェアルーター、スイッチ、VPNサーバーなどの多くのアクセスツールを使用して、管理するネットワーク（クライアントまたはオフィスサブスクライバーを含む）を外部ネットワークインフラストラクチャに接続するための多数の方法があります。 ただし、ほとんどの場合、ネットワークを介して送信されたトラフィックに関する情報を分析または制御するためにソフトウェアまたはハードウェアに送信できるスキームを考え出すことができます。 このツールは、個々のクライアント、プロトコルなどのインテリジェントなアクセス制限アルゴリズムを使用して、アクセスデバイスとのフィードバックを可能にすることも可能です。
これで、材料の分析を終了します。 選択されていないトピックのうち、次のものがありました。

• 交通データがどのように、どこに到達するか
• 交通会計ソフトウェア
• 課金が単純な「リーダー」とどのように異なるか
• どのようにトラフィックを制限できますか
• 訪問したウェブサイトの会計と制限