概要
IPsecバックネットワークのCatoクラウドからWANへのアクセスには接続性が最も重要です。 IPsecサイトの接続が途切れると、業務機能が妨げられる可能性があります。 このプレイブックは、このシナリオでのトラブルシューティングをガイドすることを目的としています。
症状
以下のいずれかの方法で、IPsec接続の失敗を検出することができます。 管理者は次の症状を確認する場合があります：
CMAでIPsecサイトが切断されています
接続の不安定な履歴
IPsec接続を通じて通過するトラフィックのパフォーマンスが低い
可能性のある原因
トラブルシューティングの際に特定できる可能性のある原因は以下のとおりです。
ピア接続性
これは、ピアがL3アンダーレイ上で一貫してお互いに到達できる能力を含みます。
IPsec設定の不一致
変換セットまたは認証の不一致により、トンネルが全く形成されないか、再鍵が完了する前に失敗することがあります
アンダーレイパフォーマンス
IPsecは、トンネル内で満足のいくパフォーマンスを得るために、安定したアンダーレイ接続に依存しています。
注：
IPsecサイトを持つアカウントの場合、RPFルールの外部IPがIPsecサイトのIPアドレスとオーバーラップしている場合、そのルールがIPsecトンネルのポートUDP/500およびUDP/4500を除外していることを確認してください。
問題のトラブルシューティング
管理者が遭遇する可能性のある症状のトラブルシューティング手順は以下のとおりです。 これらの手順は、直面する問題の可能性のある原因を特定することを目的としています。 解決手順は、後にこのプレイブックでハイライトされます。
CMAでの切断または不安定なIPsecサイトのトラブルシューティング
イベントから情報の収集
ホーム > イベントページで管理者はアカウント内のIPsecサイトの接続イベント履歴を迅速に把握できます。 イベントを「サイト接続状況」プリセットを選択するか、「接続性」イベントタイプと「切断済み」サブタイプでフィルタリングすることで、関連イベントに絞り込むことができます。 該当するサイトの名前を「ソースサイト」フィールドでフィルタリングするか、トンネルプロトコル値「IPSEC」で全IPsecサイトフィルタリングすることもできます。
質問しているサイトの切断イベントのタイムスタンプを確認することで、調査を絞り込むことができます。 このタイムスタンプで発生した広範なネットワークイベントやローカル電源イベントはありますか？ この監査証跡に関連する変更があるか確認して関連付けることができますか？
切断イベントが見つからず、トンネルが不安定と報告されている場合、Catoとリモートピアの間のパラメータ不一致により、再鍵処理時に問題が発生する可能性があります。 さらなる分析のために以下の手順を継続します。
サイトIPsec接続履歴の表示
重要：
このファイルがCMAで利用できない場合（ファイルが見つからない）、フェーズ1（またはIKEv2のIKE_SA）がリモートピアと交渉されていないことを意味します。 IKEと認証パラメータが両方のピア間で一致していることを確認してください。
ネットワーク > サイト > サイト設定 > IPsecのタイムラインは接続されていないIPsecサイトのトラブルシューティングに不可欠です。
タイムラインボタンが提供するCSVファイルには、関連トンネルログの履歴が記録されています。 これらのログは、IPsec接続の接続性の欠如を引き起こしている問題の明確な兆候を提供することができます。 インディケーターメッセージの一般的な例を以下に示します：
トラフィックセレクターが一致しないと示唆するメッセージは、第2フェーズの設定で不一致がある証拠です。特に、IPsecピアリングの各側に利用可能なサブネットに関してです。 この場合のエラーが表示された場合は、IPsec設定の不一致を解決に移動してください。
上記のメッセージは、オーセントペイロードでの設定の不一致を示しています。 もちろん、接続が成功するためにPSKがこれらのペイロードと一致している必要があります。 これが接続の試みに表示される場合は、IPsec設定の不一致を解決に移動してください。
上記のタイムラインには、設定済みのピアと接続を試み、応答を受け取らなかったことが示されています。 このタイムラインでは、ピアと何のやり取りもなく、SAが非活動状態で閉じられることが見られます。 これは通常、リモートピアにL3到達性がない場合に発生します。 これらのインスタンスでは、ピア接続解決をご覧ください。
IKEv1とIKEv2のための可能なタイムラインエラーメッセージの完全なリストはこちらを参照してください。
パケットキャプチャを使用してトラブルシュート
注：
パケットキャプチャを行う際、トンネルに設定したPoPIPは10.x.y.zという内部IPに抽象化されます。
また、ネットワーク > サイト > サイト設定 > IPsec ページにパケットキャプチャツールがあります。 これにより、ピア間の制御トラフィックのパケットトレースを提供します。 上記でハイライトされた問題もこれらのパケットキャプチャに表現されています。
TS_UNACCEPTABLE
変換セット内のサブネットの不一致については、情報パケットがエラーを知らせます。 このIKEv2の例では、情報メッセージTS_UNACCEPTABLEは変換セット内の設定不一致を示しています。 この問題を修正するには、IPsec設定の不一致を解決に移動してください。
NO_PROPOSAL_CHOSEN
セキュリティアソシエーション内のパラメータの不一致の場合、いずれのピアもペイロード内にエラーを含めます。 このIKEv2の例では、エラーNO-PROPOSAL-CHOSENは、CMAで設定されたアルゴリズムまたはDHグループのどれかがリモートピアの設定と一致していないことを明確に示しています。 これはトンネルの初期確立または再鍵プロセス中に発生する可能性があります。
AUTHENTICATION_FAILED
以下のキャプチャは、IKEv2のもう一つの例を示しており、今回は認証に使用されたPSKが一致しなかったことを示しています：
One-Way Packets
パケットキャプチャにより、IPレベルでのピアとの接続性問題を特定するのに役立ちます。 以下の例では、パケットキャプチャは一方向の送信トラフィックのみを示しており、ピアが到達不能であることを示唆しています。 トラブルシューティングを行う管理者が到達不能なピアを確認した場合、ピア接続解決に移動してください。
上記のインスタンス、またはIKEv1またはIKEv2におけるピア間の設定の不一致を示唆するその他のインディケーターについては、IPsec設定の不一致を解決に移動してください。
VPNの低パフォーマンスのトラブルシューティング
VPNで低パフォーマンスが見られる場合、これには通常パケットロス、高レイテンシー、頻繁な切断の形式が含まれます。
影響を受けるアプリケーションを介したトンネルを通るトラフィックにパケットロスが見られ、IPsec接続を介して1つのホストから別のホストへのICMPプローブでテストすることで確認できます。
遅延とトンネル切断もアプリケーションのパフォーマンスに明らかであり、質問しているサイトのためのネットワーク > サイトモニタリング > ネットワークアナリティクスページからも確認できます。
パフォーマンスの問題が特定された場合、アンダーレイパフォーマンスの解決に移動してください。
AzureIPSecでのパケットドロップ
AzureでIPSecを設定する際、トンネルスループットと1秒あたりのパケット数(PPS)はVPNゲートウェイのSKUと暗号化アルゴリズムによって決定されます。 例えば、Microsoftのドキュメントによれば、GCMAES256を使用したとき、VpnGw3 Generation2 gatewayは最大140,000PPSを処理できます。
トラフィックがこれらのしきい値を超えた場合、Azureは余剰パケットを自動的にドロップし、顕著なパフォーマンス劣化を引き起こす可能性があります。 一般的な症状の1つは、スループットの減少であり、CMAのネットワークアナリティクスに現れるトラフィック量の減少として見られることがあります。 しかし、これを診断するには、Azureポータル内でVPNゲートウェイメトリックを直接監視し、トンネルスループットと影響を受けているVPN接続のPPS値をリアルタイムで把握する方が正確です。
この問題を軽減するためには、高いIPSec SKUへのアップグレード、またはAzure vSocketのデプロイを検討し、どちらもVPNトンネルの容量を強化し、トラフィック過負荷によるパケットドロップを防止できます。
発見された問題の解決
ピア接続の解決
IPsecピアがタイムラインエントリやパケットキャプチャによってパケットをPoPに送信していないことが示される場合、リモートピアがCMAでトンネルに割り当てられたIPアドレスと同じIPアドレスに接続するように設定されていることを確認してください。
この設定が確認された場合、リモートピアがNATで制限された接続をトラバースできるように、ポート4500だけでなくポート500でも応答することを確認します。 リモートピアにNAT-T（NAT traversal）が有効であるべきです。
リモートピアデバイスがインターネット経由でICMPリクエストに応答するように設定されている場合、そのデバイスのパブリックIPにICMPリクエストをテストして、その一般的な到達可能性を確認することもできます。
直近のステータスページの健全性の変更を確認してください。 PoPが問題を抱えている場合、これはIPsecトンネルに影響を及ぼす可能性があります（それぞれのトンネルは1つのCato PoPロケーションに接続されています）。 ステータスページでCato PoPのヘルスを監視することができます。
リモートピアがAzureやAWSなどのクラウドベンダーである場合、そのステータスページも確認できます。
このIPsec接続に対してピアデバイスが依然として到達不能の場合は、管理者に連絡して、IPsec接続用に公共でアクセス可能であることを確認してください。
IPsec設定の不一致の解決
変換セットのピア設定がサイト > IPsecページの設定と一致していることを確認してください。
Cato側のピーリングを、ピアの特定の変換セットに一致させるために構成するには、IKEv1とIKEv2のリンクされたドキュメントに記載されているように設定を編集してください。
トンネルの両側のIPレンジ（セレクター）は一致しなければなりません。 CMAでは、次のようにIPレンジが設定されていることを確認してください：
ローカルIPレンジ（ピア側）: サイト設定 > ネットワークに移動し、IPsecピア（例：ファイアウォールまたはルーター）背後にあるサブネットを定義します。
リモートIPレンジ（Cato側）: サイト設定 > IPSec > ルーティングに移動し、トンネルを横断できるローカルIPレンジを定義します（通常、他のサイトからのネットワークです）。 このフィールドが構成されていない場合、トンネルは暗黙のセレクター0.0.0.0 <> 0.0.0.0付きのルートベースVPNと見なされます。
一部のベンダーは、変換セット内に含まれるすべてのサブネットを単一の変換セットメッセージのみに含めることを要求します。 これがピアの場合、管理者はサイト > 高度な設定の下で「IKEv2 ペイロードごとに単一のTSを送信」を使用する高度な設定オプションを利用する必要があります。
アンダーレイ パフォーマンスの解決
アンダーレイパフォーマンスの解決のための焦点は、リモートピアに対するパフォーマンスを分離することです。
リモートピアが8.8.8.8のような公開Webサーバーにpingを送信できることをテストしてください。 遅延またはパケット ロスがトンネルと一貫している場合、問題はリモート ピアの環境内に存在すると結論付けることができます。
Catoサポートへのケースの持ち上げ
上記のトラブルシューティング手順の結果を記載したサポートチケットを提出してください。 チケットに次の情報を含めてください：
タイムスタンプ付きの関連タイムラインエントリ
関連するパケットキャプチャ
一致する変換セットの確認、サブネットの関連付け、および認証/暗号化パラメータを含む