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サーバー間の通信を監視します。
従来、物理ネットワーク・スイッチまたは物理ネットワークTerminal Access Point (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コレクタへのミラー化トラフィックのトランスポート
NPA Collectorを使用する前に、次の点に注意してください:
- ソリューションはベスト・プラクティスとして出荷されます。
- NPA Collectorにイーサネット・アクセスがあることを確認する責任があります。
- スクリプトの使用が企業のセキュリティ・ポリシーに準拠していることを確認する必要があります。
このベスト・プラクティスは、標準のLinuxカーネル・ネットワーク機能およびユーザー領域ツールを使用して実現されます。 次のRPMパッケージ・セットは、仮想TAPおよびL2TPトンネルを管理するための使いやすいツール・セットを提供します。
- ux-tunnel-transmit
- ux-tunnel-receive
ノート:
このコンテキストでの同様の制限は、「Oracle Real User Experience Insightインストレーション・ガイド」のTAPで説明されている物理TAPを使用した従来のデプロイメントに仮想TAPに適用されます。 つまり、たとえば、ネットワーク待機時間が長い場合や飽和状態のネットワークでは、パケット損失や大量の再順序付けが発生し、レポートの精度に影響を与えます。
操作、システムの影響、および帯域幅に関する考慮事項
仮想TAPおよびL2TPトンネル・ソリューションはソフトウェアにデプロイされ、Linuxカーネルによって処理され、次のように影響します:
- サーバー・ネットワーク・パケット・スケジューリング
- エグレス: ミラー化されたインタフェースのデフォルトのキューイング規則が ‘prio’に変更されます
- イングレス: ミラー化されたインタフェース上のデフォルトのキューイング規則が有効です
- サーバー・パフォーマンス
- 仮想TAP:
- 様々な追加仮想インタフェース(混合モード)が追加され、使用されています:
- 仮想イーサネット・ペア
- ブリッジ
- Linux Traffic Control (TC)フィルタ:
- パケット・ミラー(構成ポートごとまたはすべてのトラフィック)
- ループ保護
- 様々な追加仮想インタフェース(混合モード)が追加され、使用されています:
- L2TPトンネル: カプセル化とカプセル化解除
- 不要なカーネル・パケット処理を防ぐために調整されたIPv4/6カーネル・パラメータ(sysctl)
- 不要なカーネル・パケット処理を防止するための追加ルーティング表
- 仮想TAP:
- セキュリティ
- ファイアウォールがL2TPプロトコル(115)のトラバースを許可するように調整されました
- カーネル接続トラッキング・システムへのミラー・トラフィック(再入力)を防ぐために調整されたファイアウォール
- バンド幅
- トンネルを介してカプセル化されたトラフィックを送信するには、追加の帯域幅が必要です:
- イーサネット・デバイスからのミラー化された「イングレスおよびエグレス」トラフィックは「集計」で、その「同じ」イーサネット・デバイスのエグレス上にL2TPでカプセル化されます。
- L2TPプロトコル・オーバーヘッド
- IP断片化のオーバーヘッド
- トンネルを介してカプセル化されたトラフィックを送信するには、追加の帯域幅が必要です:
- その他
- L2TPカーネル・モジュールの自動ロードおよびアンロード
前提条件
- RUEIがインストールされているシステム(RUEI NPAコレクタを含む)
- アプリケーション(リモート・システム)がデプロイされた実行中の1つ以上のWebアプリケーション・サーバー
- 両方のシステム間のネットワーク接続
- 両方のシステムへのリモートSecure Shell (SSH)アクセス
- 両方のシステムでのroot / super user (sudo)アクセス
- 取得したネットワーク・トラフィックをトンネリングするのに十分なネットワーク帯域幅
- 仮想TAP / 送信側:
- iproute
- iproute-tc (iproute version 5を使用する場合)
- kernel-modules-extra (Oracle Linux 8以降)
- vethカーネル・モジュール
- bridgeカーネル・モジュール
- L2TPカーネル・モジュール
- UEKカーネル・バージョン
- UEK4更新7
- UEK5更新1
SSL (HTTPS)で保護されたwebアプリケーション・サーバーを監視できます。 NPAコレクタはエフェメラル・ベースの暗号スイートをモニタリングできないことに注意してください。 その場合は、非エフェメラル暗号スイートを使用するようにSSLオフ・ローダーを構成します。
アーキテクチャ
共通のデプロイメント・アーキテクチャには、複数のHTTP webサーバーの前にロード・バランサが含まれます。 ブラウザは、仮想クラウド・ネットワーク内のロード・バランサを使用してインターネット・ゲートウェイ経由で接続します。 ロード・バランサは、SSL暗号化および復号化を実行できます。 ロード・バランサは、HTTPリクエストをバックエンド・セット内のいずれかのWebサーバーに転送します。
各バックエンドWebサーバーで、仮想イーサネットTAPを使用して、HTTPリクエストがミラー化され、L2TPトンネルを介してRUEIインスタンスに送信されます。 RUEIインスタンスは、複数のトンネルを同時に処理します。
インストールの選択肢
次の2つのインストール・メソッドがあります:
- ステップ・バイ・ステップ構成
- RUEIシステムのイーサネット・トンネル
- Web Application Serverシステムの仮想Ethernet TAPおよびEthernetトンネル
- 自動
- ステップ・バイ・ステップ構成を使用したRUEIシステムのイーサネット・トンネル
- ‘Automated Install’を使用したWebアプリケーション・サーバー・システムの仮想Ethernet TAPおよびEthernetトンネル
ステップ・バイ・ステップ構成
監視する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 protocol番号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としてログインし、次のステップを実行します:
- 「構成」タブをクリックします。
- 左側のペインで「コレクタ・プロファイル」をクリックします。
- メイン・ペインで「ネットワーク・データ・コレクタの構成」をクリックします。
- 「システム(localhost)」を右クリックし、「ネットワーク・インタフェースの割当て」をクリックします。
- 「選択モード」を「指定されたインタフェース」に設定します。
- ‘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サーバーの構成を参照してください。 または、「診断の送信」 (「ローカル・サービスへの受信トラフィックの検証」)で説明されているように、自動ポート/サービス検出ツールを使用します。
例: 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-list例:
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サービスの使用」を参照してください。
トラフィックが予想どおりに流れていない場合は、「診断」を参照してください。
自動インストール
Webアプリケーション・サーバー・システムでの仮想Ethernet TAPおよびEthernetトンネルのインストールおよび構成は自動化されており、複数の監視対象システムを簡単に設定できます。
前提条件
- RUEIシステムのイーサネット・トンネル「構成済」および「アクティブ化済」
「ステップ・バイ・ステップ構成」のRUEIシステムに関連するステップに従います。
- ターゲットのアプリケーション・サーバー・システムへのリモートSSHアクセス[HOST]
- キー・ベースの認証アイデンティティ・ファイル[IDENTITY-FILE]
- リモート・ユーザー名[USER]
- リモート・ユーザー用のパスワードレスsudoアクセス
- sudoではTTYなしのアクセスを許可する必要があります(ttyは必要ありません)
- リモート・ユーザーは、BASH、標準のコマンドライン・ツールおよびLinuxカーネル・ネットワーク構成コマンドライン・ツール(ip、tc、bridgeなど)を実行できます
- RUEIシステムからアプリケーション・サーバー・システムへのSSHファイアウォール・アクセス
ノート:
検出および自動化は、最新のOracle Linuxシステムでの標準サーバー・インストールでテストされています。 ほとんどの場合、検出とインストールは成功しますが、検出と自動インストールは、様々なLinuxカーネルおよびオペレーティング・システム・コンポーネントに依存します。 そのため、このスクリプトはベスト・エフォート・アプローチに基づいて作成されており、すべての可能なシステム構成をサポートすることはできません。概要
各アプリケーション・サーバー・システムは、SSH接続を介してRUEIシステムから自動的にインストールされます。 リモート・システムとの接続は、キー・ベースの認証を使用して実現されます。 プロセスは次の2つのステップに分割されます:
- リモート・システムでのHTTPおよびHTTPS webサービスの実行の自動検出
- 自動的に検出された構成を使用して、リモート・システム上の仮想Ethernet TAPおよびEthernetトンネルの自動インストール、構成、およびアクティブ化を行います。
ステップ1: 実行中のHTTPおよびHTTPS webサービスの自動検出
自動検出プロセスは、仮想イーサネットTAPを構成できるように、リモート・アプリケーション・サーバー・システムで稼働しているwebサービスを検出しようとします。 仮想イーサネットTAPは、リモート・システム上のwebアプリケーションのイーサネット・トラフィック(イングレスおよびエグレス)の取得を担当します。 取得されたトラフィックは、イーサネット・トンネルを使用してRUEIシステムに送信されます。
検出プロセスは、次のように設計されています:
- すべてのオープンIPv4ベースのサービス / ポート(リスナー・ソケット)を検出
- サービス / ポートがプレーンHTTPを実装しているかどうかを検出
- サービス / ポートがHTTPS (SSL)を実装しているかどうかを検出
- SSLエフェメラル・ベースの暗号スイートが使用されているかどうかを検出
(RUEIと互換性がありません)
- SSLエフェメラル・ベースの暗号スイートが使用されているかどうかを検出
次のステップを実行します。
cd $RUEI_HOME/tunnel/receive
./ux-tunnel-receive discover tunnel -c USER@HOST -i IDENTITY-FILE >detect.info
cat detect.infoステップ2: 自動インストール、構成、アクティブ化
このステップの後、新しい仮想Ethernet TAPおよびEthernetトンネルが完全に構成され、動作しています。 トラフィックは、リモート・アプリケーション・サーバー・システムで取得され、RUEIシステムで転送および受信されます。
次のステップが実行されます:
- リモート
- ソフトウェアのインストール(ux-tunnel-transmit RPM)
- 検出された構成を使用して仮想Ethernet TAPを構成
- 検出された構成を使用してEthernetトンネルを構成
- 仮想Ethernet TAPおよびEthernetトンネルのアクティブ化
- ローカル
- 検出された構成を使用してEthernetトンネルを構成
- 新しいEthernetトンネルのアクティブ化
次のステップを実行します。
./ux-tunnel-receive discover tunnel-install -c USER@HOST -i IDENTITY-FILE -f detect.info -a ux-tunnel-transmit-<version>.rpmノート:
ux-tunnel-transmit-<version>.rpmは、インストール・ディレクトリ/root/ruei,のRBACホスト、またはそれ以外の場合に、出荷されたRUEIリリースZIPで確認できます。ノート:
仮想ネットワークTAP、Ethernetトンネルを検証し、トラフィックのRUEI処理を構成または検証するには、次を参照してください:- ステップ・バイ・ステップ構成 / 「ステップ3: RUEI NPAコレクタがトラフィックを受信していることの確認」
- ステップ・バイ・ステップ構成 / 「ステップ4: RUEIでのアプリケーション・インスタンス/スイートの構成」
- 診断
診断
仮想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