B 仮想ネットワークTAPおよびL2TPトンネルの設定
この付録では、webサーバー・インスタンス上のイーサネット・トラフィックを取得し、Virtual Ethernet Network TAPおよびLayer 2 Tunneling Protocol (L2TP)トンネルを使用してRUEI NPAコレクタでインスタンスに転送する方法について説明します。 これは、標準のLinuxカーネル・ネットワーク機能およびユーザー領域ツールを使用して実現されます。
始める前に
Real User Experience Insight (RUEI)は、Network Protocol Analyzer (NPA)コレクタによるイーサネット・ネットワーク・トラフィックに対する高度なリアルタイム分析を実行して、クライアント (ブラウザ)とwebサーバー間の通信を監視します。
従来、物理ネットワーク・スイッチまたは物理ネットワーク端末アクセス・ポイント(TAP)デバイス上のSwitch Port Analyzer (SPAN)ポートは、NPAコレクタへのイーサネット・ネットワーク・トラフィックを非侵入的にミラー化するようにデプロイされていました。
NPAコレクタは、ミラーにすべてのイーサネット・パケットが変更されていないかぎり、イーサネット・トラフィックのミラーを受信する方法についての要件はありません。 ただし、たとえば、仮想化ネットワークが多いクラウド環境では、物理デバイスを使用したイーサネット・トラフィックの取得は実行可能または不可能な場合があるため、別のアプローチが必要になります。
この付録では、webアプリケーション・サーバーでイーサネット・トラフィックを取得し、Virtual Ethernet Network TAPおよびLayer 2 Tunneling Protocol (L2TP)トンネルを使用して取得したトラフィックをネットワーク経由でRUEI NPAコレクタに転送するためのベスト・プラクティスについて説明します:
- Virtual Ethernet Network TAP: Linux Traffic Control (TC)フレームワークを使用したトラフィックのミラー化。
- Ethernet Tunnel: L2TPを使用したネットワーク経由でのNPAコレクタへのミラー化トラフィックのトランスポート
このベスト・プラクティスは、標準のLinuxカーネル・ネットワーク機能およびユーザー領域ツールを使用して実現されます。 次のRPMパッケージ・セットは、仮想TAPおよびL2TPトンネルを管理するための使いやすいツール・セットを提供
- ux-tunnel-transmit
- ux-tunnel-receive
ノート:
このコンテキストでの同様の制限は、「Oracle Real User Experience Insightインストレーション・ガイド」のTAPで説明されている物理TAPを使用した従来のデプロイメントの仮想TAPにも適用されることに注意してください。 これは、たとえば、ネットワーク待機時間または飽和状態のネットワークが長いと、パケット損失や大幅な並替えが発生し、レポートの精度に影響する可能性があることを意味します。
前提条件
- RUEIがインストールされているシステム(RUEI NPAコレクタを含む)
- アプリケーション(リモート・システム)がデプロイされた実行中の1つ以上のWebアプリケーション・サーバー
- 両方のシステム間のネットワーク接続
- 両方のシステムへのリモートSecure Shell (SSH)アクセス
- 両方のシステムでのroot / super user (sudo)アクセス
- 取得したネットワーク・トラフィックをトンネリングするのに十分なネットワーク帯域幅
- 仮想TAP / 送信側:
- Oracle Linux 7
- iproute
- iproute-tc (iproute version 5を使用する場合)
- bridge-utils
- vethカーネル・モジュール
- ブリッジ・カーネル・モジュール
- L2TPカーネル・モジュール
- UEKカーネル・バージョン
- UEK4更新7
- UEK5更新1
SSL (HTTPS)で保護されたwebアプリケーション・サーバーを監視できます。 NPAコレクタはエフェメラル・ベースの暗号スイートをモニタリングできないことに注意してください。 その場合は、非フェメラル暗号スイートを使用するようにSSLオフ・ローダーを構成します。
アーキテクチャ
共通のデプロイメント・アーキテクチャには、複数のHTTP webサーバーの前にロード・バランサが含まれます。 ブラウザは、仮想クラウド・ネットワーク内のロード・バランサを使用してインターネット・ゲートウェイ経由で接続します。 ロード・バランサは、SSL暗号化および復号化を実行できます。 ロード・バランサは、HTTPリクエストをバックエンド・セット内のいずれかのWebサーバーに転送します。
各バックエンドWebサーバーで、仮想イーサネットTAPを使用して、HTTPリクエストがミラー化され、L2TPトンネルを介してRUEIインスタンスに送信されます。 RUEIインスタンスは、複数のトンネルを同時に処理します。
段階的な構成
監視するwebサーバー・インスタンスまたはロード・バランサ・インスタンスごとに、この付録の手順を繰り返します。 RUEIインスタンスは、複数のトンネルを同時に処理できます。
ノート:
次の構成ステップのコマンドは、rootユーザーとして、またはSUDOを使用して実行する必要があります。ステップ1: ファイアウォールの構成
ネットワーク・ファイアウォール
イーサネット・トラフィックは、webアプリケーション・サーバー・システムの仮想ネットワーク・イーサネットTAPによって取得されると、L2TPを介してRUEIシステムにトンネリングされます。
ネットワークでは、webアプリケーション・システムからRUEIシステムへのL2TPトラフィックを許可する必要があります。
関連するネットワークのすべてのファイアウォールを更新して、L2TPトラフィックを許可してください: IPプロトコル115。
警告: L2TPにはIPプロトコル番号があります: 115 L2TPはIP上のプロトコルであり、TCP(/IP)上のプロトコルではないことに注意してください。 よくある間違いは、TCP (またはUDP) 「ポート番号」 115がセキュリティ・リストで誤って有効になっているのに対し、かわりにIP プロトコル番号115を有効にする必要があることです。
RUEIシステムとWebアプリケーション・サーバー・システムの両方でのLinuxファイアウォール
ファイアウォールRUEIシステム
ノート:
OCI Marketplaceを使用する場合、RUEIシステム・ファイアウォールはL2TPを許可するようにすでに構成されています。
RUEIシステムに流れるL2TPトラフィックを許可するには、ファイアウォールで次のルールを有効にします。 たとえば、ネイティブOracle Linux firewalldを使用する場合は、次のようになります:
firewall-cmd --zone=public --add-protocol=115
firewall-cmd --zone=public --add-protocol=115 --permanentファイアウォールWebアプリケーション・サーバー
一般に、Oracle Linuxファイアウォールは、ローカル・マシンからのすべてのトラフィックを許可 / 信頼し、ネットワークに流入します。 システムの出力フローに制限がある場合は、webアプリケーション・サーバーで次のコマンドを使用してL2TPトラフィックを許可します:
firewall-cmd --direct --add-rule ipv4 filter OUTPUT 0 -p l2tp -j ACCEPT
firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 0 -p l2tp -j ACCEPTステップ2: RUEI仮想イーサネットTAPおよびL2TPトンネルの設定
RUEI上のL2TPトンネル
準備
L2TPトンネル構成には、適切なトンネルのソースおよび宛先エンドポイントIPが必要です。 特に指示がないかぎり、この章のすべての手順はSSHを使用してRUEIインスタンスで実行する必要があります。
RUEIへのL2TPトンネルのインストール
rootユーザーで次のコマンドを実行します。
cd /root/ruei
./ruei-install.sh rpms/ux-tunnel-receive-*.rpmノート:
OCI Marketplaceを使用する場合、RPMはすでにインストールされています。
設定
L2TPトンネルの構成
- rootユーザーとして、構成ファイル
tunnels.confを編集します。/opt/rueiは、RUEI_HOMEのインストールで顧客が構成したディレクトリに置き換える必要があります(/etc/ruei.confで確認できます)。ノート:
初期tunnels.confファイルはRPMファイルのインストール後に作成されました。 - 前述の手順で取得したトンネルのソースIPと宛先IPを使用して、受信トンネルを構成します。 次の形式を使用して
tunnels.confファイルに行を追加します:receiving-side-ip transmit-side-ip - -次に例を示します。
10.10.10.10 10.10.10.11 - -この構成は、10.10.10.10 (RUEI)と10.10.10.11 (WEBSERVER)の間にL2TPトンネル(受信側)を設定するようにトンネル・ヘルパー・ツールに指示します。
ノート:
受信側は複数のトンネルを処理できます。 トンネルごとに、構成ファイルに行を追加します。ノート:
L2TPトンネルにはトンネルIDが必要です。 デフォルトでは、送信側はローカル・トンネル送信元IPをトンネルIDとして使用します。 NATがネットワークで適用される場合、RUEI受信システムのSrc-IPが異なる可能性があります。 その場合は、tunnels.confファイル内のSrc-IPとDst-IPだけでなく、トンネルIDも必ず含めてトンネルを構成してください。次に例を示します:10.10.10.10 192.168.1.11 – 10.10.10.11ノート:
トンネルIDは、IPアドレスまたは数値として書式設定できます。 複数のトンネル間でIPが競合する場合は、IPアドレスではなく一意の番号を使用します。
L2TPトンネルの起動
トンネル・サービスをリロードします:
systemctl reload ux-tunnel-receiveトンネル・サービス(systemctl stop ux-tunnel-receive)を停止すると、トンネル・サービスをリロードするかわりにRUEIコレクタも自動的に停止する場合があります。 これは、トンネル集約インタフェースが削除されたためです。 ウォッチドッグは自動的にコレクタの再起動を試みます。 1つ以上の適切なネットワーク・インタフェースが検出されると、再起動に成功します。
L2TPトンネルの検証
L2TPトンネル・インタフェースをリストします:
ip link
サンプル出力:
10: ruei-mtun: <BROADCAST,NOARP,PROMISC,UP,LOWER_UP> mtu 64000 qdisc noqueue state UNKNOWN link/ether [MAC] brd ff:ff:ff:ff:ff:ff
11: ruei-mtun-00000: <BROADCAST,NOARP,PROMISC,UP,LOWER_UP> mtu 64000 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether [MAC] brd ff:ff:ff:ff:ff:ffより高度なトンネル設定の場合、ux-tunnel-receive configをオンザフライで使用すると、構成ファイルを手動で編集したり、既存のオンライン・トンネルのトラフィックのトンネリングやキャプチャを中断することなく、トンネルを追加および削除できます。
RUEI NPAコレクタの設定
ノート:
RUEIインスタンスがOCI Marketplaceからデプロイされている場合、この項はスキップできます。L2TPトンネル集約デバイスのみを使用するようにRUEI NPAコレクタを構成し、他のトンネル・インタフェースを破棄します。 RUEI webユーザー・インタフェースにadminとしてログインし、次のステップを実行します:
- 構成タブをクリック
- 左側のペインでコレクタ・プロファイルをクリック
- メイン・ペインでネットワーク・データ・コレクタの構成をクリック
- System (localhost)を右クリックし、Assign network interfaceをクリック
- 選択モードを指定されたインタフェースに設定
- 'ruei-mtun'インタフェースを追加します。
- 「保存」をクリックします。
RUEI NPAコレクタは、「保存」をクリックすると自動的に再起動されます。 変更がアクティブ化されるまで数分かかります。
'ruei-mtun-<NUMBER>'インタフェースをコレクタのインタフェースのリストに追加しないでください。 トンネル・ツールは、'ruei-mtun-<NUMBER>'インタフェースから'ruei-mtun'へのすべてのトラフィックを集約します。
WEBSERVER上の仮想Ethernet TAPおよびL2TPトンネル
準備
L2TPトンネル構成には、適切なトンネルのソースおよび宛先エンドポイントIPが必要です。 さらに、仮想Ethernet TAPには、ミラー化されるネットワーク・インタフェース名とミラー化されるTCP/IPポートが必要です。
特に指示がないかぎり、この章のすべての手順はSSHを使用してWEBSERVERインスタンスで実行する必要があります。
宛先IP (リモート、RUEI)
次のコマンドを使用して、L2TPトンネルの宛先IPを特定できます:
host <dns-name-RUEI>出力例: 10.10.10.10
注意: RUEIがネットワーク・アドレス変換(NAT)の背後にある場合、ローカルに構成されたIP (RUEIインスタンス上のip address showで決定可能)を使用する必要はありませんが、NAT (外部)アドレスを使用する必要があります。 前述のように、host (DNS resolve)コマンドを使用すると、ほとんどの状況で正しいIPアドレスが提供されます。
Webサーバーのポート番号
サーバーが実行されているTCP/IPポート番号については、webサーバーの構成を参照してください。 または、「診断の送信」 (「ローカル・サービスへの受信トラフィックの検証」)で説明されているように、自動ポート/サービス検出ツールを使用します。
Example: port 80
インストール
RUEIシステムからアプリケーションwebサーバーにux-tunnel-transmit RPMをコピーし、rootユーザーとしてインストールします:
rpm -ivh ux-tunnel-transmit-*.rpmノート:
RUEIシステムからアプリケーションwebサーバーにux-tunnel-transmit RPMをコピーし、rootユーザーとしてインストール: RPMは/root/ruei/rpmsにあります。
設定
仮想ネットワークTAPおよびL2TPトンネルの構成
- rootユーザーとして、構成ファイルを作成します:
cd /opt/ruei/tunnel/transmit/conf cp tunnel.conf.example tunnel.conf - 前述の手順で取得したトンネルの送信元および宛先IPを使用して、送信トンネルを構成します。 次の形式を使用して、
tunnel.confに行を追加します:receiving-side-ip transmit-side-ip mirror-if-name mirror-port-listExample:
10.10.10.10 10.10.10.11 ens3 i80この構成は、10.10.10.11 (WEBSERVER)と10.10.10.10 (RUEI)間の仮想ネットワークTAPおよびL2TPトンネル(送信側)を設定するようヘルパー・ツールに指示します。
ノート:
ポート番号(80)の前のiに注目してください。 これは、イングレス・トラフィックをミラー・リングするように仮想タップに指示します。 または、'o'プレフィクスを使用してエグレス・トラフィックをミラー化することもできます。 複数のポートをミラー化できます。 各ポート(およびそのプレフィクス)をカンマ区切りリスト(空白なし)に追加します。 さらに、ミラー・ポート・リストでキーワードallを使用すると、すべてのトラフィックをミラー化できます。
ノート:
送信側は1つのトンネルを処理できます。
仮想ネットワークTAPおよびL2TPトンネルの起動
トンネル・サービスを起動します。
ノート:
トンネル・サービスが現在実行中の場合は、まず停止してからサービスを再起動します。systemctl stop ux-tunnel-transmit
systemctl start ux-tunnel-transmit仮想ネットワークTAPおよびL2TPトンネルの検証
L2TPトンネル・インタフェースをリストします:
ip link出力例:
15: ruei-tun1: <BROADCAST,NOARP,PROMISC,UP,LOWER_UP> mtu 64000 qdisc prio master ruei-br1 state UNKNOWN mode DEFAULT group default qlen 1000 link/ether [MAC] brd ff:ff:ff:ff:ff:ff
16: ruei-br1: <BROADCAST,NOARP,PROMISC,UP,LOWER_UP> mtu 64000 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether [MAC] brd ff:ff:ff:ff:ff:f
17: ruei-veth1in@ruei-veth1out: <BROADCAST,MULTICAST,NOARP,PROMISC,UP,LOWER_UP> mtu 64000 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether [MAC] brd ff:ff:ff:ff:ff:ff
18: ruei-veth1out@ruei-veth1in: <BROADCAST,MULTICAST,NOARP,PROMISC,UP,LOWER_UP> mtu 64000 qdisc noqueue master ruei-br1 state UP mode DEFAULT group default qlen 1000 link/ether [MAC] brd ff:ff:ff:ff:ff:ffステップ3: RUEI NPAコレクタがトラフィックを受信していることの確認
この章を続行する前に、仮想ネットワークTAPおよびトンネル構成で指定されたアプリケーションのポート番号もRUEIにプロトコルとして追加されていることを確認してください。 プロトコル構成は、RUEI UIの「構成」>「セキュリティ」>「プロトコル」セクションにあります。
RUEI NPAコレクタがトラフィックを受信したことを確認するには、RUEI webユーザー・インタフェースで管理ユーザーとして次のステップを実行します:
- 「構成」タブをクリックします。
- 左側のペインで「セキュリティ」をクリックします。
- 左側のペインで「プロトコル」をクリックします。
- メイン・ペインでプロトコル(アプリケーション構成に応じてHTTPまたはHTTPS)をクリックして、「プロファイル・ポートの編集」ウィンドウを開きます。
- ポート番号を入力し、「追加」をクリックします。
- 「保存」をクリックします。
- メイン・ペインで「ネットワーク・データ・コレクタの構成」をクリックします。
- 「システム(localhost)」をクリックして、コレクタ統計ウィンドウを開きます。
- 左ペインの様々な統計メニュー・アイテムをクリックして、トラフィック受信を確認します。 ミラー・イーサネットが入るインタフェースはruei-mtunです。
ステップ4: RUEIでのアプリケーション・インスタンス/スイートの構成
トラフィックが正しくフローしたら、RUEIでスイートまたはアプリケーション・インスタンスを構成します。 詳細は、「Oracle® Real User Experience Insightユーザーズ・ガイド」の「スイートおよびWebサービスの使用」を参照してください。
トラフィックが予想どおりに流れていない場合は、「診断」を参照してください。
診断
仮想TAPおよびL2TPのベスト・プラクティスには様々な仮想ネットワーク・インタフェースが含まれており、トンネルは様々なファイアウォールを通過する必要がある場合があります。 トラフィックが正しく受信されない場合は、様々なステップを実行して構成を確認する必要があります。 送信側と受信側の両方に診断ステップがあります。
診断の送信
ローカル・サービスへの受信トラフィックの検証
最初のステップでは、予想されるwebトラフィックがWebアプリケーション・サーバーに流れているかどうかを確認します。
次のツールを使用して、サーバーIPおよびサーバー・ポート別に集計されたローカル・サービス(webアプリケーション・サーバーを含む)へのトラフィック(接続)を自動的に検出してリストします。 デフォルトでは、ツールは以前に構成されたトンネル・ミラー・インタフェース(この例ではeth0)上のパケットを調べます。 異なるインタフェースで同じチェックを実行するには、別のインタフェースを指定します。
cd /opt/ruei/tunnel/transmit
./ux-tunnel-transmit diag traffic servers出力例:
[info] Detecting server IPs and ports on interface 'eth0', capture time: 30s, max packets: 1000
[info] Using filter: tcp[tcpflags] == tcp-syn|tcp-ack
[info] Server-IP Port Connections
[info] 10.10.10.01 80 38
[info] 10.10.10.02 7001 3トンネル・ステータスの検証
さまざまなローカルの原因により、パケットがL2TPトンネルによって受け入れられず、サイレントに破棄される可能性があります。 送信側のトンネル・ステータスを確認するには、次のツールを使用します。
./ux-tunnel-transmit diag tunnel check出力例:
[info] Interface Local IP Remote IP Tx: packets Tx: errors Tunnel status
[info] ruei-tun1 10.10.10.10 10.10.10.11 0 0 OKシステムから離れるL2TPトラフィックの検証
次のコマンドを使用して、L2TPでカプセル化されたパケットが送信システムを離れていることを確認します。 Eth0は、L2TPパケットがシステムから離脱するインタフェースとして使用されます。 、L2TPパケットがルーティングされる実際のインタフェースに置き換えてください。
/usr/sbin/tcpdump -n -nn -i eth0 proto l2tp出力例:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
08:03:29.170192 IP 10.10.10.10 > 10.10.10.11: l2tp 106
08:03:29.380252 IP 10.10.10.10 > 10.10.10.11: l2tp 106
08:03:29.590259 IP 10.10.10.10 > 10.10.10.11: l2tp 106診断の受信
着信トンネルの検証
次のツールを使用して、受信L2TPトンネルを自動的に検出します。 ux-tunnel-transmitで構成および開始された各トンネルは、20秒ごとにキープアライブpingを送信します。 このキープアライブpingは、着信トンネルを検出するために使用されます。
sudo ./ux-tunnel-receive diag monitor detect出力例:
[info ] Detecting tunnels on interface 'any', capture time: 30
[info ] Type Dst-IP Src-IP Tunnel-ID NAT-Status
[info ] L2TP 10.10.10.10 192.168.10.11 10.10.10.11(168430091) yes
[info ] L2TP 10.10.10.10 192.168.10.12 10.10.10.12(168430092) yes
[info ] Detected tunnels: 2L2TPトンネルにはトンネルIDが必要です。 デフォルトでは、送信側はローカル・トンネル送信元IPをトンネルIDとして使用します。 NATがネットワークで適用される場合、RUEI受信システムのSrc-IPが異なる可能性があります。 その場合は、tunnels.confファイル内のSrc-IPとDst-IPだけでなく、トンネルIDも必ず含めてトンネルを構成してください。次に例を示します:
16859033
トンネル・ステータスの検証
さまざまなローカルの原因により、パケットがL2TPトンネルによって受け入れられず、暗黙的に破棄される可能性があります。 次のツールを使用して、受信側の各トンネルのステータスを確認します。
./ux-tunnel-receive diag tunnels check出力例:
[info ] Interface Local IP Remote IP Rx: packets Rx: errors Tunnel status
[info ] ruei-mtun-00000 10.10.10.10 10.10.10.11 180144698 0 OK
[info ] ruei-mtun-00001 10.10.10.10 10.10.10.12 0 0 OKトンネル・インタフェースがエラーを報告すると、そのトンネル・ステータスはFAILとして報告されます。
トンネル集約インタフェースでの着信トラフィックの確認
すべてのトンネルから着信するすべてのトラフィックは、受信側で'ruei-mtun'に集約されます。
次のツールを使用して、サーバーIPおよびサーバー・ポート別に集計されたミラー化されたサービス(webアプリケーション・サーバーを含む)へのトラフィック(接続)を自動的に検出してリストします。 デフォルトでは、このツールはトンネル集約インタフェース'ruei-mtun'上のパケットを調べます。
sudo ./ux-tunnel-receive diag traffic servers出力例:
[info] Detecting server IPs and ports on interface 'ruei-mtun', capture time: 30s, max packets: 1000
[info] Using filter: tcp[tcpflags] == tcp-syn|tcp-ack
[info] Server-IP Port Connections
[info] 10.10.10.01 80 38
[info] 10.10.10.02 7001 3システムに入るL2TPトラフィックの検証
次のコマンドを使用して、L2TPカプセル化パケットが受信システムに入っていることを確認します。 Eth0は、L2TPパケットがシステムに入るインタフェースとして次のように使用されます。 、L2TPパケットを受信する実際のインタフェースに置き換えてください。
./usr/sbin/tcpdump -n -nn -i eth0 proto l2tp出力例:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
08:03:29.170192 IP 10.10.10.11 > 10.10.10.10: l2tp 106
08:03:29.380252 IP 10.10.10.11 > 10.10.10.10: l2tp 106
08:03:29.590259 IP 10.10.10.11 > 10.10.10.10: l2tp 106