| Oracle® Real User Experience Insight管理者ガイド 12cリリース6 (12.1.0.7) for Linux x86-64 E61773-01 |
|
 前 |
 次 |
この付録では、RUEIコレクタ・エンジンへのGRE Ethernet (レイヤー2)トンネルを設定する方法、およびこの構成でタップを使用する方法について説明します。
|
注意: この手順を実行する前に、関連するシステムへのコンソール・アクセスを設定してください。これが必要なのは、間違ったコマンドを発行するとネットワークがオフラインになって、サーバーへの接続が切断される可能性があるためです。その場合、ネットワークを修復するためにコンソール・アクセスが必要になります。 |
RUEIユーザーズ・ガイドに、ネットワーク内のインストールを検出する方法について説明されています。トンネルのエンドポイントどうしが互いに通信できるかぎり、GREトンネリングを行うと、ネットワーク内の任意の場所にあるコレクタ・エンジンを検出できます。GREトンネリングが効率的であっても、パケットにヘッダーが追加されることによってネットワーク・スループットのオーバーヘッドが発生したり、それらのパケットのカプセル化およびカプセル化解除によりCPU時間のオーバーヘッドが発生したりすることで、ネットワーク・スループットが低下する可能性があることに注意してください。
GRE Ethernetトンネリングは、Linuxのカーネル・バージョン2.6.28以降でサポートされており、GRE Ethernetトンネル(gretap)のインタフェースを設定および構成するために、ユーティリティ(具体的にはIPユーティリティ)を含むiprouteパッケージの最新バージョンが必要です。
OL6では、GRE Ethernetトンネルを設定できるUEKカーネル(現時点でLinuxバージョン2.6.39-400.109.1.el6uek)と、GRE Ethernetトンネルの追加、削除または変更に必要な適切なバージョンのiprouteパッケージ(OL6.4の場合はiproute-2.6.32-23.el6.x86_64)が提供されるため、この手順ではGRE Ethernetトンネルを設定する基礎としてOracle Linux 6.4を使用しています。
Oracle Linux 5は、UEKカーネル(OEL5.9の場合はLinuxバージョン2.6.39-400.21.1.el5uek)をサポートできますが、サポート対象外であり、GRE Ethernetトンネルを設定できる新しいバージョン(2.6.28以上)のiprouteパッケージが必要となります。このようなiprouteパッケージ・バージョンは現在正式にはサポートされていないため、この手順では扱っていません。
コレクタのインストールと構成の詳細は、『Oracle Real User Experience Insightインストレーション・ガイド』を参照してください。
この付録ではタップおよびGREトンネルの様々な局面について詳しく説明しますが、完了する必要のあるプロセスの概要は次のとおりです。
B.2.2項「手動設定」およびB.2.3項「スクリプトによる設定」の説明に従って、手動またはスクリプトによるGRE設定を実行します。
B.2.4項「トンネルを一方向に設定」の説明に従って、宛先エンドポイントでトラフィックの受信のみが行われていることを確認します。
B.2.5項「仮想タップの追加」の説明に従って、タップを追加します。
B.3項「GREトンネリングのためのコレクタの構成」の説明に従って、コレクタを構成します。
B.7項「GREトンネルのテスト」の説明に従って、設定をテストします。
B.10項「GREトンネル環境の変更の永続化」の説明に従って、再起動後も構成が保持されることを確認します。
この項では、1つのGREトンネルの作成について説明し、(両方のエンドポイントがOL6マシンであることを想定して)どちらかのエンドポイントでタップ(ソース)トラフィックまたはGREトンネル出力(宛先)トラフィックを集計できるように設定する方法について説明します。このプロセスでは、1台のマシンに1つまたは複数のタップを追加し、1つまたは複数の受信GREトンネルをリスニングするようにコレクタを設定できます。
次のコンポーネントが必要です。
2つのOL6システム・エンドポイント(一方のエンドポイントがRUEIコレクタとして設定されている)
各システムに次のパッケージがインストールされている必要があります。
iproute2
tcpdump
bridge-utils
各システムに次のカーネル・モジュールが存在し、ロードされている必要があります。
ip_gre - GREトンネリングのサポート
bridge - ブリッジのサポート
veth - 仮想イーサネット・インタフェースのサポート
この項では、(RUEIコレクタを含む) 2つのOL6システムを、一方はソースとして、もう一方は宛先として、手動で設定する方法について説明します。このプロセスとB.2.3項「スクリプトによる設定」のいずれかを選択できます。
両方のシステムを準備するには、次の手順を実行します。
B.5項「GREトンネルの手動構成」の手順に従って、ソース・システムと宛先システムの間にGREトンネルをインストールします。
B.6項「Linuxブリッジの作成および設定」の手順に従って、ソース・システムと宛先システムそれぞれにブリッジ(BRTUN)をインストールします。
ソース・システムと宛先システムの両方で、B.6.3項「ブリッジ・インタフェースの追加および削除」の説明に従って、ローカルGREトンネル・エンドポイント・インタフェース(GRETUN)をブリッジ(BRTUN)に追加します。
B.7項「GREトンネルのテスト」の手順を実行すると、GREトンネル・インタフェースと両端のブリッジ・インタフェースの両方に、ソースからトンネルを通過して受信された生成済テスト・トラフィックが表示されるはずです。
B.2.4項「トンネルを一方向に設定」に進みます。
この項では、(RUEIコレクタを含む) 2つのOL6システムを、一方はソースとして、もう一方は宛先として、スクリプトを使用して設定する方法について説明します。このプロセスとB.2.2項「手動設定」のいずれかを選択できます。
両方のシステムを準備するには、B.4項「tunnelctlスクリプトを使用したGREトンネルの構成」の説明に従って、tunnelctlスクリプトを使用してブリッジ型GREトンネルを作成します。
この時点で、ソース・システムと宛先システムの両方が設定されていますが、ブリッジまたはトンネルを通過するトラフィックがありません。タップをトンネル・ソースに接続する前に、宛先GREトンネル・エンドポイント(宛先システムのGRETUN)でトラフィックの受信のみが可能であり、トンネルを介した送信はできないことを確認する必要があります。
ここでは、トラフィックに関与するのではなくトラフィックを監視するだけなので、実際にはGREトンネルが一方向であることを確認する必要があります。Linuxトラフィック・シェーピングを使用して、宛先エンドポイント・システムのGRETUNインタフェースの送信トラフィックをブロックします。
次の手順を実行してください。
このqdiscに使用するハンドル(HANDLE)を選択します。たとえば、GREトンネルID (ID)を再利用できます。
rootとして次のコマンドを入力して、GRETUNのルートqdiscを、送信トラフィックをフィルタできるqdisc (prio)で置き換えます。
tc qdisc replace dev GRETUN parent root handle HANDLE: prio
マシンからのすべての送信GREトラフィックを通過させるフィルタを追加して、ミラー化されないようにします。
tc filter add dev GRETUN parent HANDLE: \ protocol all prio 1 u32 \ match u32 0 0 flowid HANDLE:1 \ action drop
これで、GREトンネルは一方向になります。これをテストするには、一方のシステムでpingを使用してトラフィックを生成し、もう一方のシステムでtcpdumpを使用してトラフィックを表示して(B.7項「GREトンネルのテスト」を参照)、次に逆方向でテストを再実行します。ソース(タップ)から宛先(RUEIコレクタ)への方向は正常に機能しますが、宛先(RUEIコレクタ)からソース(タップ)への方向のトラフィックは何も表示されないはずです。
次の手順を実行して、ソース・システムのローカル・インタフェースの1つに仮想タップを作成します。
宛先RUEIシステムで監視するトラフィックのソース・システムで、インタフェース(「ETH」)を選択します。
B.8項「仮想タップの作成」の手順を使用して、手順1で選択したインタフェースに仮想タップを作成します。
ソース・システムで、B.6.3項「ブリッジ・インタフェースの追加および削除」の手順を使用して、作成したタップ・インタフェース(TAP)をブリッジ(BRTUN)に追加します。
宛先システムで、rootとして次のように入力して、GREトンネルの受信トラフィックをテストします。
tcpdump -i GRETUN -c 100 -n
注意: B.8.4項「タップのテスト」で説明するように、宛先システムのブリッジ・インタフェースに表示されるトラフィックも、ソース・システムのブリッジ・インタフェースに表示されるトラフィックと同じになったはずです。
GREトンネルの設定およびテストが完了したら、GREトンネルでトラフィックをリスニングするようにコレクタを構成できます。RUEIコレクタ・エンジンがGRE Ethernetトンネルをリスニングできるようにする手順は、次のとおりです。
RUEIを使用して(「構成」→「セキュリティ」→「コレクタ・プロファイル」)、構成するコレクタ・プロファイルを指定します。デフォルトのネットワーク・ベース・プロファイルは、「システム・ネットワーク・データ・コレクタ」という名前です。必要に応じて、新規のプロファイルを作成します。以降の手順では、選択したプロファイルをPROFILEと表記します。
構成するPROFILEコレクタが、選択したコレクタ・プロファイルによって制御されていることを確認します。
$RUEI_USERユーザーとしてRUEIレポータ・システムにログインします。
次のコマンドを入力します。
execsql config_set_profile_value PROFILE config ForceInterface add greID
説明:
greIDは、すでに作成したトンネル・インタフェースです。
PROFILEは、前述の手順1で選択したプロファイルです。
新しい構成が自動的にコレクタに伝播されるようになります。インタフェースは物理インタフェースではなく、このインタフェースが稼働しているか停止しているかをコレクタが判断するために使用する特定の内部信号がないため、インタフェースをリスニングするようにコレクタを強制設定する必要があります。そうしない場合、コレクタはインタフェースを使用しません。
インタフェースを通過するパケットをフィルタするファイアウォールが存在しないことを確認します。このタスクの実行方法についてはこのドキュメントでは説明しませんが、考慮する必要のある注意点を次に簡単に示します。
ファイアウォールは、すべてのトラフィックをGREトンネル・ネットワーク内の反対側の1つのインタフェースにルーティングするのではなく、インタフェースを完全に無視するように設定する必要があります。これは、フィルタリングによりCPUのオーバーヘッドが発生し、それがスループットにマイナスの影響を与える可能性があるためです。
一般的なファイアウォール・ルール(すべてのインタフェースに適用されるルール)が、現在構成しているインタフェースにも適用される可能性があるので、これを、このインタフェースに適用されないように変更する必要があります。回避策として、このインタフェースを無視するための新しいルールを追加します。
インタフェースに影響を与える可能性のあるネットワーク抑制を無効にします。このタスクの実行方法については、このドキュメントでは説明しません。
この項では、RUEIに付属のtunnelctlスクリプトを使用してGREトンネルを作成する方法について説明します。
次のコンポーネントが必要です。
2つのOL6システム・エンドポイント(一方のエンドポイントがRUEIコレクタとして設定されている)
各システムに次のパッケージがインストールされている必要があります。
iproute2
tcpdump
bridge-utils
各システムに次のカーネル・モジュールが存在し、ロードされている必要があります。
ip_gre - GREトンネリングのサポート
bridge - ブリッジのサポート
veth - 仮想イーサネット・インタフェースのサポート
2つのエンドポイントが互いにアクセスできること(たとえば、pingを使用してテストします)。関連するポートが、すべてのファイアウォール内のエンドポイントおよびその間にあるルーターで開かれていること。
2つのエンドポイントにtunnelctlスクリプトの実行可能コピーが存在していること。
両方のエンドポイントでrootユーザー・アクセスが可能になっていること。
次の手順を実行して、最初のエンドポイントを設定します。
ローカルおよびリモートのエンドポイントのIPアドレスを指定します。
両方のエンドポイントに使用する数字のID (123など)を作成します。このIDは、両側のトンネルを識別するために使用されます。
sshを使用してrootとしてログインし、次のコマンドを入力します。
tunnelctl create gre Local_IP Remote_IP ID
説明:
Local_IPは、現在のサーバーのアドレスです。
Remote_IPは、リモート・サーバーのアドレスです。
IDは、前の手順で作成したIDです。
トンネルが作成されたことを確認します。
tunnelctl list
greIDという名前のインタフェースが表示されます。
トンネルを設定するには、両方のエンドポイントを構成する必要があります。もう一方のエンドポイントは、ストリームを複製してGRE Ethernetトンネルを介して送信する機能を備えたスイッチまたはルータにするか、あるいは複製やストリーミングを設定できる別のLinuxサーバーにできます。
もう一方のエンドポイントが、ストリームを複製してGRE Ethernetトンネルを介して送信する機能を備えたルーターまたはスイッチである場合は、製品のドキュメントを参照して必要となる手順を確認してください。
もう一方のエンドポイントがLinuxサーバーである場合は、2番目のエンドポイントで、(トンネルの作成時にはローカルおよびリモートのIPアドレスを元に戻す必要があることに注意して)「トンネル・エンドポイントの設定」の手順を繰り返します。
この項では、GREトンネルを手動で作成する方法について説明します。
次のコンポーネントが必要です。
2つのOL6システム・エンドポイント(一方のエンドポイントがRUEIコレクタとして設定されている)
各システムに次のパッケージがインストールされている必要があります。
iproute2
tcpdump
bridge-utils
各システムに次のカーネル・モジュールが存在し、ロードされている必要があります。
ip_gre - GREトンネリングのサポート
2つのエンドポイントが互いにアクセスできること(たとえば、pingを使用してテストします)。関連するポートが、すべてのファイアウォール内のエンドポイントおよびその間にあるルーターで開かれていること。
2つのエンドポイントにtunnelctlスクリプトの実行可能コピーが存在していること。
両方のエンドポイントでrootユーザー・アクセスが可能になっていること。
次の手順を実行して、最初のエンドポイントを設定します。
|
注意: この手順を完了するまで、インタフェースを起動しないでください。 |
ローカルおよびリモートのエンドポイントのIPアドレスを指定します。
両方のエンドポイントに使用する数字のID (123など)を作成します。このIDは、両側のトンネルを識別するために使用されます。
sshを使用してrootとしてログインし、次のコマンドを入力して、GREモジュールをLinuxカーネルにロードします。
modprobe ip_gre
次のコマンドを入力して、GREモジュールがLinuxカーネルにロードされたことを確認します。
lsmod | grep gre
sshを使用してrootとしてログインし、次のコマンドを入力します。
ip link add ID type gretap local Local_IP remote Remote_IP
説明:
Local_IPは、現在のサーバーのアドレスです。
Remote_IPは、リモート・サーバーのアドレスです。
IDは、手順2で作成したIDです。
トンネルが作成されたことを確認します。
ip link show
greIDという名前のインタフェースが表示されます。
B.9.1項「ミラー化されたトラフィック用のインタフェースの構成」の手順を実行して、トンネル・インタフェースからのトラフィックをルーティングしないようにカーネルを構成します(IFACEは、現在準備しているインタフェース名(greIDなど)で置き換えてください)。
トンネルを設定するには、両方のエンドポイントを構成する必要があります。もう一方のエンドポイントは、ストリームを複製してGRE Ethernetトンネルを介して送信する機能を備えたスイッチまたはルータにするか、あるいは複製やストリーミングを設定できる別のLinuxサーバーにできます。
もう一方のエンドポイントが、ストリームを複製してGRE Ethernetトンネルを介して送信する機能を備えたルーターまたはスイッチである場合は、製品のドキュメントを参照して必要となる手順を確認してください。
もう一方のエンドポイントがLinuxサーバーである場合は、2番目のエンドポイントで、(トンネルの作成時にはローカルおよびリモートのIPアドレスを元に戻す必要があることに注意して)「トンネル・エンドポイントの手動設定」の手順を繰り返します。
この項では、ミラー化されたデータのレイヤー2 hubとして機能するLinuxブリッジを作成および設定する方法について説明します。仮想タップおよびGREトンネルをブリッジに追加して、必要な構成を作成できます。複数のブリッジを設定することもできますが、このような構成についてはこのドキュメントでは説明しません。
次のコンポーネントが必要です。
次のパッケージがインストールされている必要があります。
iproute2
tcpdump
bridge-utils
次のカーネル・モジュールが存在し、ロードされている必要があります。
bridge
次の手順を実行して、ブリッジを作成します。
sshを使用してrootとしてログインし、次のコマンドを入力します。
brctl addbr BRTUN
説明:
BRTUNはブリッジの名前です。
次のコマンドを入力して、ブリッジが作成されたことを確認します。
brctl show
次のコマンドを入力して、スイッチではなく(ダム)ハブとして機能するようにブリッジを構成します。
brctl setfd BRTUN 0brctl setageing BRTUN 0
次のコマンドを入力して、ブリッジをサイレントとして構成します。
brctl stp BRTUN off
B.9.1項「ミラー化されたトラフィック用のインタフェースの構成」の手順を実行して、ブリッジ・インタフェースからのトラフィックをルーティングしないようにカーネルを構成します(IFACEは、現在準備しているインタフェース名(BRTUN>など)で置き換えてください)。
次のコマンドを入力して、ブリッジをアクティブ化し、すべてのトラフィックを受け入れるように設定します。
ip link set BRTUN promisc on arp off up
インタフェース(IFACE)をブリッジに追加するには、次のコマンドを入力します。
brctl addif BRTUN IFACE
インタフェース(IFACE)をブリッジから削除するには、次のコマンドを入力します。
brctl delif BRTUN IFACE
ブリッジの現在の構成は、次のコマンドを入力することによっていつでも確認できます。
brctl show
2つのエンドポイント間のGREトンネルを設定し、ミラー化されたトラフィックがLinux(仮想)マシンにルーティングされないように、ミラー化されたトラフィック用のインタフェースを設定した後は、一方の終端でping、もう一方の終端でtcpdumpを実行してGREトンネル・トラフィックを表示することにより、未使用のGRE Ethernetトンネルをテストできます。次の手順では、2つのエンドポイントをソースおよび宛先と表記しますが、ソースはpingが実行されているエンドポイントで、宛先はトラフィックの確認のためにtcpdumpが使用される場所です。
両方のシステムでrootとして次のコマンドを入力して、いずれかのエンドポイント・システムのGREトンネル・インタフェースが稼働中であることを確認します。
ip li set GRETUN up
ソース・システムでrootとして次のコマンドを入力して、トンネルを介してICMPパケットを送信します。
ping -I GRETUN 127.1.1.1
このIPアドレスはローカル・アドレスであるため、誤ってどこかにルーティングされることのないように選択されています。ping -Iを使用すると、ICMPパケットはGREトンネルを介してのみ送信され、宛先エンドポイントからの可視性は制限されます。
宛先システムでrootとして次のように入力して、GREのカプセル化されたトンネル・トラフィックが受信されたことを確認します。ETHは、トンネル・インタフェースそのものではなく、トンネルのルーティングに使用されるインタフェース(ローカル・エンドポイント、通常はeth0)です。
tcpdump -i ETH -c 100 proto gre
次のように、GREパケット(GREv0)でラップされた前述のIPアドレスに対するARPリクエストまたはICMPリクエスト(あるいはその両方)が表示されます。
… IP server_A > server_B: GREv0, length 46: ARP, Request who-has 127.1.1.1 tell server_A, length 28 … IP server_A > server_B: GREv0, length 102: IP server_A > 127.1.1.1: ICMP echo request, id 62057, seq 1, length 64
この項では、OL6 Linuxマシン上の他のライブ・インタフェースからミラー化されたトラフィックを提供するタップ・ネットワーク・インタフェースを作成する一般的な方法について説明します。この方法では、Linuxトラフィック・シェーピングを使用してインタフェースの受信データと送信データをミラー化し、そのネットワーク・トラフィックを新しく作成された一連の仮想イーサネット・インタフェースにコピーします。
2つの仮想イーサネット・インタフェースのセットは、一方に入ってきたデータがもう一方から出るように互いに接続されているため、この意味で、両者は1つの仮想NICケーブルとして機能しています。これらの仮想イーサネット・インタフェースは一般的に、仮想ネットワーキングで使用されます。
ローカル・インタフェース(ssh接続を制御するインタフェースや、GREトンネル・トラフィックを伝送するインタフェースなど)はいずれもこの方法を使用してミラー化できることに注意してください。これが可能なのは、この章に示したトラフィック・シェーピング・ルールの1つによって、GREトラフィックがミラー化されたトラフィックから除外されるためです。
この手順では、1組の仮想インタフェース(ETHmirrorとETHtap)を作成します。たとえば、インタフェースeth0をタップする場合は、まず、eth0mirrorおよびeth0tapという仮想インタフェースのセットを作成します。このようにインタフェースに名前を付けると、GREトンネルへの複数のローカル・インタフェースをミラー化できるため、システムでこれらのインタフェースと他のミラーリング設定とを区別できます。以後、これらをETH、MIRRORおよびTAPと表記します。
ETHインタフェースのトラフィックは、MIRRORインタフェース上でミラー化されます。これらは仮想イーサネット・ペアであるため、MIRRORインタフェースを通過するすべてのトラフィックはTAPインタフェースにも表示され、任意のネットワーク構成でそのTAPインタフェースを(直接またはブリッジ内で)使用できます。
次のコンポーネントが必要です。
OL6 Linuxシステムにこのタップを作成する必要があります。
次のパッケージがインストールされている必要があります。
iproute2
tcpdump
次のカーネル・モジュールが存在し、ロードされている必要があります。
veth - 仮想イーサネット・インタフェースのサポート
ミラー化するライブ・インタフェース(以後、ETHと表記)が存在していること。
次の手順を実行して、ミラー仮想インタフェースおよびタップ仮想インタフェースを作成します。
rootとして次のコマンドを入力して、1組の仮想インタフェースを作成します。
ip li ad TAP type veth peer name MIRROR
rootとして次のコマンドを入力して、インタフェースをアクティブ化します。
ip li set dev TAP up promisc on arp off ip li set dev MIRROR up promisc on arp off
トラフィック・シェーピングによって、特定のインタフェース(ETH)のすべての受信トラフィックおよび送信トラフィックを、新しく作成したMIRROR仮想インタフェースにコピーできます。トラフィック・シェーピングの仕組みについてはこのドキュメントでは説明していませんが、個々の手順が注釈として付けられています。
ミラー設定そのものは単純ですが、GREトラフィック(GREv0、「GREトンネルのテスト」を参照)がミラー化されないようにするためのフィルタを追加する必要があります。GREトンネルのトランスポートに使用されるインタフェースをミラー化する場合にGREトンネル自身のトラフィック(ループ)が強制的に伝送されると、ほぼ確実にネットワークやサーバーの障害が発生するため、伝送されないよう確認するためにこの手順を実行する必要があります。
受信トラフィックをミラー化する手順は、次のとおりです。
rootとして次のコマンドを入力して、入口qdiscをETHに追加します。
tc qdisc add dev ETH ingress
すべての受信GREトラフィックをミラー化されないようにマシンに渡すためのフィルタを追加します。
tc filter add dev ETH parent ffff: \
protocol all prio 1 u32 \
match ip protocol 47 0xff flowid 1:1 \
action pass
残りのすべてのトラフィックをMIRRORインタフェースにミラー化するためのフィルタを追加します。
tc filter add dev ETH parent ffff: \ protocol all prio 2 u32 \ match u32 0 0 flowid 1:2 \ action mirred egress mirror dev MIRROR
すべての送信トラフィックをミラー化する手順は、次のとおりです。
rootとして次のコマンドを入力して、ETHのルートqdiscを、送信トラフィックをフィルタできるqdisc (prio)で置き換えます。
tc qdisc replace dev ETH parent root handle 10: prio
すべての送信GREトラフィックをミラー化されないようにマシンに渡すためのフィルタを追加します。
tc filter add dev ETH parent 10: \
protocol all prio 1 u32 \
match ip protocol 47 0xff flowid 10:1 \
action pass
残りのすべてのトラフィックをMIRRORインタフェースにミラー化するためのフィルタを追加します。
tc filter add dev ETH parent 10: \ protocol all prio 2 u32 \ match u32 0 0 flowid 10:2 \ action mirred egress mirror dev MIRROR
|
注意: この手順の完了後にMIRRORインタフェースを非アクティブにした場合、ETHネットワーク・トラフィックは中断されます。残りの設定ではTAPインタフェースのみを使用しますが、MIRRORインタフェースを非アクティブにしても結果は変わらないため、MIRRORインタフェースはアクティブのままにしておきます。 |
この時点では、2つの新しいインタフェース(MIRRORおよびTAP)があります。MIRRORはトラフィック・シェーピング・ルールでETHからのネットワーク・トラフィックをミラー化するために使用され、TAPはMIRRORの仮想インタフェースに相当するものです。以降はMIRRORをアクティブのままにしておき、データがシステムによりルーティングされていないかぎり、ネットワーキング設定で自由にTAPを使用できるようにします。正常に機能するかテストするには、TAPインタフェース上のトラフィックを確認します。そのトラフィックは、ETH上のトラフィックからGREトラフィックを除いた量と同じになるはずです。
rootとして次のコマンドを入力して、TAPインタフェース上のトラフィックを確認します。
tcpdump -i TAP -c 100 -n
手順1の出力を、次のコマンドの出力(ETH上のトラフィックからGREトラフィックから除外した量)と比較します。
tcpdump -i ETH -c 100 -n ! proto gre
注意: 同じ出力を確認するには、両方のコマンドを同時に実行する必要があります。前述の手順を同時に実行すると、出力が整列していない可能性がありますが、位置合せされた後は両者が同じであることがわかります。
この項では、特定のインタフェースを通過するパケットがLinuxカーネルによりルーティングもフィルタも行われないように設定する方法について説明します。
次の手順では、IFACEは、すべてのパケットをルーティングせずに受け入れるように設定するインタフェースを示しています。
rootとして次のコマンドを入力して、arpまたはマルチキャスト・パケットに応答せずにすべてのトラフィックを受け入れるようインタフェースを構成します。
ip link set IFACE down promisc on arp off multicast off
前述のコマンドを実行すると、誤ってデータをルーティングすることがないように、(停止されていない)インタフェースも停止されることに注意してください。すべての手順が完了するまで、インタフェースを再起動しないでください。
インタフェースにIPv6アドレスが自動的に割り当てられないようにするには、次のコマンドを発行します。
sysctl -w net.ipv6.conf.IFACE.autoconf=0 sysctl -w net.ipv6.conf.IFACE.accept_ra=0
インタフェースにIPv4またはIPv6アドレスがすでに割り当てられているか確認します。
ip address show IFACE
前述のコマンドの出力から、inet (IPv4)またはinet6 (IPv6)で始まるすべてのアドレスを削除します(IPは削除するアドレス)。
ip address delete IP dev IFACE
このインタフェースが、(受信しないため応答することもない)それ自身のIPアドレスに対するARPリクエストにのみ応答することを確認します。
sysctl -w net.ipv4.conf.IFACE.arp_ignore=1
受信パケットが破棄されないように、逆方向パス・フィルタリングを無効にします。
sysctl -w net.ipv4.conf.IFACE.rp_filter=0
トンネルに対してルーティングを設定する(あるいは何もルーティングを指定しない)ことができるように、空のルーティング表番号を選択します。
この例では、表番号200を使用します。次のコマンドを使用して、表が空であることを確認します。
ip route show table 200
これらの手順を使用して1つのシステムに複数のインタフェースを設定する場合、表が空のままであるため、それらのインタフェースがすべて同じ表を使用できます。
カーネルが空の表を使用してこのインタフェースのルーティング情報を参照するように、ルーティング表ルールを作成します。
ip rule add iif IFACE table 200
次のコマンドを発行して、ルールが追加されたことを確認します。
ip rule show
出力は次のようになります。
0: from all lookup local
32765: from all iif IFACE lookup 200
32766: from all lookup main
32767: from all lookup default
システムでファイアウォールがアクティブになっている場合、インタフェースを介して受信されたパケットがそのファイアウォールによってフィルタされないように確認します。ここに示すファイアウォール・アプリケーションの種類が多すぎるため、この方法についてはこのドキュメントで説明しませんが、考慮する必要のある注意点を次に簡単に示します。
ファイアウォールは、すべてのトラフィックをGREトンネル・ネットワーク内の反対側の1つのインタフェースにルーティングするのではなく、インタフェースを完全に無視するように設定する必要があります。これは、フィルタリングによりCPUのオーバーヘッドが発生し、それがスループットにマイナスの影響を与える可能性があるためです。
一般的なファイアウォール・ルール(すべてのインタフェースに適用されるルール)が、現在構成しているインタフェースにも適用される可能性があります。これらのルールをこのインタフェースに適用されないように変更するか、このインタフェースを無視するための新しいルールを追加する必要があります。
一部のシステムではネットワーク抑制が有効になっており、インタフェースを構成するためには、これを削除するか無効にする必要があります。そうしない場合、コピーまたはミラー化されたネットワークのパケットの一部が破棄される可能性があります。ネットワーク抑制の構成を変更する方法については、このドキュメントでは説明しません。トラフィック・シェーピングを使用する場合、このドキュメントで説明されているトラフィック・シェーピング・ルールに細心の注意を払う必要があります(B.8.3項「ミラーの構成」およびB.4項「tunnelctlスクリプトを使用したGREトンネルの構成」も参照)。
GREトンネル構成に問題がなければ、この付録に示す設定コマンドを実行する起動スクリプトを作成します。スクリプトには次の処理に対応するアイテムを含める必要があります。
GRE Ethernetトンネル作成
ファイアウォール構成
ネットワーク抑制
