ソケットサイトトンネル接続トラブルシューティング

概要

サイトの接続性は、ソケットの背後にあるホストがCatoクラウド経由でWANにアクセスするために重要です。 サイトの接続の欠如は、ビジネスの機能を中断させる可能性があります。 このプレイブックは、このシナリオでのトラブルシューティングのガイダンスを提供することを目的としています。

症状

ソケット接続の失敗は、さまざまな方法で現れる可能性があります。 管理者は、以下の症状に気付くことがあります：

• サイトがCMAで切断されています 
• サイトが予期しないPoPに接続
  
• ネットワークアナリティクスはトンネルが不安定であることを示します

可能性のある原因

トラブルシューティング中に特定できる可能性のある以下の原因があります

• ソケットの接続性がない
  
• DTLSトラフィックは一方通行のみ
  
• 不適切なアンダーレイ性能
  
• IPジオロケーションの制限
• 不適切なPoP選択設定
• 不正確なベースラインでのSLA設定
• ソケットの前にNATデバイスが配置

問題のトラブルシューティング

管理者が直面する可能性のある症状を解決するための手順が以下にリストされています。 これらのステップは、直面する問題の可能性のある原因を特定することを目的としています。 解決手順はプレイブックの後のセクションで強調されます。

CMAでサイトが切断された問題のトラブルシューティング

イベントからの情報を収集する

CMAのホーム > イベントページを使用して、管理者はアカウント内のサイトの接続イベントの履歴を迅速に入手できます。 イベントは「サイト接続状況」のプリセットを選択するか、イベントタイプ「接続性」およびサブタイプ「切断」をフィルタリングして、関連するイベントにフィルタリングできます 「ソース サイト」フィールドを使用して、問題のサイト名に対してさらにフィルタリングすることができます。

問題のサイトからの関連する切断イベントのタイムスタンプを確認することで、調査に集中するのに役立ちます。 このタイムスタンプに発生した既知の広範なネットワークイベントやローカル電源イベントはありますか？ これに先立ち関係する可能性のある監査証跡の変更はありますか？

ソケット接続のチェック

ソケットの接続要件を理解するには、Catoソケット接続前提条件をご覧ください。

ソケットの接続ステータスは、そのローカルWebUIから確認できます。 ローカルでソケットWebUIにログインする。 ソケットが接続されるためには、Catoクラウドへの接続に使用されているWANポートが緑色のステータスアイコンを表示している必要があります。 緑以外のインジケーターは、接続に問題があることを示しています。 さまざまなステータスアイコンの色の意味は、リンクステータスアイコンの理解に記載されています

赤いアイコンの場合、ソケットとISPデバイスの間に正常な物理的接続があることを確認してください。 これには、ケーブルが確実に接続されていること、ポートのLEDが期待通りに点灯していることが含まれます。

IPの競合もソケットの接続ステータスによって検出されます。 IP競合警告は、このKB記事で説明されているように、競合が最初に検出された時点から24時間表示され続けます。

ツールのインターネットバイパスによる強制回復ステータスが標準であることを確認してください。 「強制バイパス」ボタンを押すと、すべてのLANトラフィックがCatoをバイパスすることになり、Catoトンネルが停止し、サイトがCMAで切断された状態として表示されます。 したがって、このデバイスへのすべてのリモート設定とアクセスは失敗します。 冗長化セットアップでは、プライマリソケットが「強制バイパス」で有効化されている場合、セカンダリソケットは引き続きバックアップソケットとして残り、ソケット背後のトラフィックは直接インターネットにルーテッドされます。

以下のスクリーンショットは、プライマリソケットで『強制バイパス』が有効になっており、セカンダリソケットはスタンバイのままです。 

フォースリカバリーのステータスがアクティブの場合、強制バイパス終了ボタンをクリックしてこの状態を終了します。

接続の問題が発生した場合、さらなるテストを行うためにツールタブを利用できます。 Catoに接続するには、ソケットはCatoのパブリックIPアドレスへのL3アクセスが必要です。 Pingツールを使用して、このソケットがWANポートを介してCatoのIPアドレスやドメイン、または8.8.8.8のようなよく知られたIP到達可能アドレスに到達できることを確認してください。 どれも到達できない場合は、ソケット接続なし問題解決 セクションを閲覧してください。

パケットキャプチャ実行中

ソケットのPoPにDTLSトンネルを確立するためのリクエストに応答があることを確認するために、パケットキャプチャを行うこともできます。 該当WANポートでキャプチャを行う際には、UDP/443でPoPに向かう双方向のパケットが見えるはずです。 以下のスクリーンショットは、DTLSハンドシェイクが成功し、アプリケーションデータパケットの交換が行われていることを示しています。

アウトバウンドDTLSパケットのみが検出されるか、DTLSハンドシェイクが完了しない場合は、未完了のDTLSハンドシェイク解決を参照してください。 

ソケット手前にあるNATデバイスのため、トンネルを確立できない

複数のWANリンクを使用するソケットの場合、ソケットとPoPの間にNATデバイスがあると、1つ以上のWANリンクがPoPに接続できない可能性があります。 これにより、サイトのHAステータスが未準備であるなどの接続問題が発生することがあります。

PoPは、各受信DTLS接続の送信元ポートを使用して、各WANリンクを同じ論理トンネルに接続します。 NATデバイスは送信元ポートを変更することがあり、WANリンクが他のWANリンクと同じ論理トンネルに接続できなくなることを防ぎます。

LTE/5GプロバイダとのDTLS接続失敗

このケーススタディで述べたように、LTE/5Gプロバイダーを使用してCatoに接続する場合、ISPはポートUDP/443でのDTLSハンドシェイクを妨害することがあり、これはハンドシェイク中にAPNのようなキャリア特有のデータとして見えることがあります。

双方向のDTLS通信があるにも関わらず、ハンドシェイクが完了していません。そのため、Catoトンネルは起動しません。 

この問題を解決するには、DTLSポートをUDP/1337に変更してください。不完全なDTLSハンドシェイクの解決をご覧ください。 

予期しないPoP選択のトラブルシューティング

ISPのIPアドレスと現在選択されているPoPを確認

監視下で、サイトを選択し、サイトの概要ウィンドウを開きます。 サイトソケットセクションで、「ログを表示」をクリックして、最近の接続をすべて表示します。 Catoに接続されるISPの公開IP（リモートIP）を探し、ISPの名前と所在地を確認してください。 「PoP」列は、サイトが接続されている現在のPoPを表示します。

「リモートIP」とISPの所在地が期待通りかどうか、ISPが予期しないロケーションを通じて接続をバックホールしていないことを確認することが重要です。 ISPの所在地（都市）は、CMA内のサイトの一般設定で指定された国/都市と一致または近接している必要があります。

CMAでのPoP選択設定を確認

サイトで古くなったり誤って設定された優先PoPロケーションは、接続をサブ最適なPoPに強制する可能性があります。 PoP選択の設定は、ネットワーク > サイト > サイト設定 > 一般 ページを通じてサイトごとに表示できます。

ここで適切でない接続のために設定が構成されている場合、またはCatoのPoP選択メカニズムに最適なPoPを決定させることを優先する場合、不適切なPoP選択設定の解決セクションをご覧ください。

ソケットでのPoP選択設定を確認 

ソケット構成に古くなったり適切でないPoP選択の設定も存在する可能性があります。 この場合かどうかを表示するには、ソケットのWebUIでクラウド接続設定へ移動してください。ソケットWebUIの使用をご覧ください。

ここに設定が存在し、CatoのPoP選択メカニズムに最適なPoPを決定させることを優先する場合、不適切なPoP選択設定の解決セクションをご覧ください。

PoPステータスを確認

最寄りの地理的PoPがメンテナンスや他の問題の影響を受けているため、ソケットが予期しないPoPに接続される可能性があります。 これが該当するかどうかを確認するには、PoPステータスページを確認してください。 

ジオロケーションの位置制限を確認

Cato MSAに従い、特定のジオロケーションのソケットサイトは他の場所にあるPoPへの接続が制限されています。 MSAはCatoサービスを購入する際に説明されます。

特定のジオロケーションのソケットサイトは利用可能なPoPのプールに限定されます。例えば、中国のソケットサイトは中国内のPoPに接続し、ベトナムのソケットサイトはアジア内のPoPのプールに接続します。

これについての詳細は、MSAをご覧ください。

ソケットがPoPの間を移動する兆候を確認する

イベントページを使用して、接続の問題によりソケットが最初に特定された最適PoPにない可能性を判断できます。 フィールドを選択して、ソケットが異なるPoPに接続するタイムラインを作成します。

「サイトが再接続されました」のイベントプリセットを使用し、問題のサイトへのフィルタを追加、「イベントメッセージ」のフィールド値を「パフォーマンスの問題が検出され、Catoクラウド内の異なるサービスノードへ再接続されました」に設定すると、トンネル接続パラメータが設定されたSLA閾値を超えてPoPが移動したすべてのインスタンスを確認できます。 ソケットサイトが複数のPoPに対してSLA閾値を超えている場合、接続SLA設定を確認するためにトラブルシューティングを続行します。

接続SLAが厳しすぎないことを確認する

接続SLAは、特にISPインターネット接続などの公共の基盤を持つダイナミックネットワーク環境において、サイトが最適なPoPに接続されることを保証する上で重要な役割を果たします。 ただし、接続SLAが厳しすぎると、管理者の希望する場所以外のPoPへの不要な再接続が発生する可能性があります。

各サイトの接続SLAの設定はネットワーク > サイト > サイト設定 > 接続SLAの下に表示されます。

ネットワークアナリティクスを使用して最終区間のパフォーマンスメトリクスのベースラインを構築するには、このサイトにSLAメトリクスが適しているかどうかを考慮します。

これらのパラメータが適していない場合は、不正なベースラインでのSLA設定の解決をご覧ください

パラメータが適していても、複数のPoPへのPoPの再最適化イベントが定期的に発生している場合は、パフォーマンスの悪い基盤を解決するセクションをご覧ください。

上記の手順に従った後もソケットが不適切なPoPに接続し続ける場合は、サポートにチケットを開き、現在のPoPと期待するPoPを強調表示してください。

不安定なトンネルのトラブルシューティング

最終区間とサイト接続性能の関連性を確認

特定のサイトがPoPとの接続でパフォーマンスが低下している場合、パケットロスの原因が基礎ISPラインのパフォーマンスにあるかを特定することが重要です。

これは、特定の期間内で観察された最終区間の性能と、他のパフォーマンス問題を相関させ、パターンを探すことによって行われます。

ネットワークアナリティクスを使用してこれを行うことができます。

上記の例は、サイトトンネルからPoPへの上りパケットロスを示しています。 約10%のスパイクがいくつか発生し、期間を通して一定の低いレベルの損失があります。

これを同じ期間内の最終区間の性能と比較すると、以下のことがわかります：

最終区間でもパフォーマンスの変動が見られますが、約10-20%の損失が一定しています。 これにより、ソケットからCato PoPへのトンネルでのパケットロスは、基盤のパフォーマンス不良の症状である可能性が高いことが明らかです。

パフォーマンス問題をトラブルシューティングする際にこの場合は、低い基盤パフォーマンスの解決を表示してください

類似したサイトのクロスリファレンス

サイト間で共有されているプロパティを使用して、問題に関する事実を推測しようとすることができます。 例えば、下記のサイトで接続性の問題が発生しています。 接続されたPoPがロンドンであることに注意してください：

この情報は、ロンドンに接続されている可能性のある他のサイトをクロスリファレンスして、問題が共有されているかどうかを確認するために使われることができます。 これは以下のスクリーンショットで確認できます：

クロスリファレンスにより、問題がCato PoPにあることが示唆される場合は、PoPステータスの確認セクションを表示してください。

クロスリファレンスは、共有ISPを持つサイトにも役立ちます。 これは以下の例で示されています：

このクロスリファレンスがISPに接続性の問題があることを示唆する場合は、低い基盤パフォーマンスの解決セクションを表示してください。

接続SLAがあまりにも寛容でないことを確認

コネクションSLA は、特にISPインターネット接続のようなパブリックのアンダーレイがある動的なネットワーク環境で、サイトが最適なPoPに接続されることを保証する上で重要な役割を果たします。 ただし、あまりにも寛容なコネクションSLAは、管理者が望む以上にソケットがサブオプティマルなPoP接続を保持することを許可し、それにより敏感なアプリケーションに影響を及ぼす可能性があります。

ネットワーク > サイト > サイト設定 > コネクションSLAの下で、各サイトごとのコネクションSLA設定を見ることができます。

ネットワークアナリティクスを使用して最終区間パフォーマンスメトリクスのベースラインを構築し、そのSLAメトリクスがこのサイトに適しているかどうかを考慮してください。

これらのパラメータが適していない場合は、誤ったベースラインでのSLA設定の解決を参照してください。

発見された問題を解決する

ソケットの接続性の解決

接続性の問題がソケットのみに影響を与えているかどうかを隔離することが重要です。 同じISP接続にノートパソコンを接続した場合、DNSの解決やアドレスのpingに同じ問題が生じるかどうかを確認しますか？ その場合は、ISPに連絡して進捗を図ってください。

テストラップトップがIPv6が無効になっていることを確認し、静的IPアドレス割り当ての場合、テスト時にソケットと同じIPを割り当てます。

接続性の問題がソケットに限定されている場合、WebUIのネットワーク設定タブの下でIP構成が正しいことを確認してください：

不完全なDTLSハンドシェイクの解決

プロバイダと確認して、UDPポート443でのDTLSトラフィックがインターネットへ出力されることが許可されていることを確かめてください。 必要に応じて、このポートはCato PoPに接続するための異なるポートを設定するに記載されているように、UDP/1337に変更できます。

貧弱なアンダーレイパフォーマンスの解決

低いアンダーレイパフォーマンスは、そのアンダーレイ上に構築されたトンネルのすべてに影響を与えます。 アンダーレイはISPのドメインですが、性能問題が発生している場所を特定し、可能な場合は性能問題を軽減するためのツールがいくつかあります。

ソケットのWebUIには、ISPの接続を通じて公開アクセス可能なホストにピンを送ることができるトレースルートツールがあります。 公開アクセス可能なホスト名へのpingでは、ソケットとサービス間のL3経路上で損失または過剰遅延が導入されるホップを特定できます。

上記のインスタンスでは、パケットロスがISPによって提供されたL3境界から直接導入されていることが明確です。

最終的には、いかなるアンダーレイの問題もISPに持ち込まれる必要がありますが、CMAの設定が正しいことを確認することで、パフォーマンスの問題の影響を軽減するのに役立ちます。 ソケットインタフェースの帯域幅構成が、回線によって提供される帯域幅に対して正確であることを確認してください。 ソケットWebUIの速度テストツールを実行して接続をベンチマークできます。 さらに、接続のバースト性パラメータを削減することで、CatoがQoSエンジンを早期に作動させ、優先度の低いトラフィックをより重要なアプリケーションに代えてドロップすることができます。 

不適切なPoP選択設定の解決

手動PoP選択設定を元に戻し、ソケット接続の最適なPoPを選択できるようにするには、最初にCMAに手動PoPロケーション設定がないことを確認し、ソケットでも同様に設定します。

CMAでは、ネットワーク > サイト > 一般 > 優先PoPロケーションでこれを行うことができます。

「自動」が選択されていることを確認してください。

ソケットWebUIでクラウド接続設定に移動します。

宛先が「Steering」に設定されていることを確認してください。

誤った基準値でのSLA設定の解決

SLA設定が適切であることを確認する最初のステップは、サイトからの重要なアプリケーションのための重要なしきい値または要件を理解することです。

これを展開するために、2つの例を考えてみましょう。

• アプリケーションAは、低いレベルのパケットロスに寛容であり、良好なパケットの再注文能力を持っていますが、サービスが機能するためにはセッションを維持する必要があります。フローを中断し再作成することでアプリケーション内に問題が発生します。
• アプリケーションBは、断続的なパケットロスに非常に敏感です。 低いレベルの損失でもデータ転送が中断され、転送を最初からやり直さなければならないことがあります。 とはいえ、制御チャネルはセッションの終了と再接続に非常に耐性があります。

アプリケーションAのプロファイルでは、長い時間ウィンドウであっても低いレベルの損失を許容するSLA設定を作成します。サービスが他の方法で影響を受ける場合でも、セッションを維持するためにPoPへの接続を保持することが優先されます。

アプリケーションBは、対照的に、厳密なSLA設定が必要です。 転送の整合性を保護するため、パケットロスがわずかでも検出された場合はPoPを移動することが望ましいです。

サイトは明らかに異なるプロファイルと要件を持つアプリケーションの混合を使用しています。 管理者は、適切なSLAポリシーを得るために、これらのニーズを戦略的にバランスさせる必要があります。 

Catoサポートへのお問い合わせ

この手順書に従っても問題が解決しない場合は、サポートチケットを提出してください。 リクエストに対する最も有効な対応を得るためには、この手順書の使用中に行ったトラブルシューティング手順の結果を管理者が提供する必要があります。 例えば、以下を含む：

• 特定のイベントに注意を引くための関連フィルター。
• WebUIテストの結果。
• ネットワーク分析の結果。
• SLA構成の要件。