IPsecサイト接続性のトラブルシューティング

概要

IPsecの背後にあるネットワークがCatoクラウド経由でWANにアクセスするためには、接続性が不可欠です。 IPsecサイトの接続が欠如していると、ビジネス機能が妨げられる可能性があります。このプレイブックは、このシナリオでのトラブルシューティングをガイドすることを目指しています。

症状

IPsec接続の失敗は、以下の方法で判断できます。管理者が次の症状を指摘することがあります：

IPsec サイトは CMA で切断されています
接続の不安定さの履歴
IPsec接続を通過するトラフィックの性能が低い

考えられる原因

トラブルシューティング中に判明する可能性のある原因は以下の通りです。

ピア接続性
- これには、L3アンダーレイを通じてピアが一貫して到達できる能力を含みます。
IPsec構成の不一致
- 変換セットまたは認証の不一致が原因で、トンネルが全く形成されないか、リキーを完了する前に失敗することがあります
アンダーレイの性能
- IPsecは、トンネル内で満足のいく性能を得るために安定したアンダーレイ接続に依存しています。

注意: IPsecサイトを持つアカウントにおいて、RPFルールの外部IPがIPsecサイトのIPアドレスと重複する場合、ルールがIPsecトンネルポートUDP/500およびUDP/4500を除外することを確認してください。

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

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

CMAにおけるIPsecサイトの接続切れまたは不安定のトラブルシューティング

イベントからの情報収集

CMAのホーム > イベントページを使用して、管理者はアカウント内のIPsecサイトの接続イベントの履歴を迅速に取得できます。イベントは『サイト接続状況』のプリセットを選択またはイベントタイプ『接続性』とサブタイプ『切断』でフィルターすることで関連するイベントにフィルタリングできます。さらに、問題のあるサイトの名前を『送信元サイト』フィールドでフィルタするか、『IPSEC』トンネルプロトコルの値を使用して全てのIPsecサイトをフィルタできます。

関係のあるサイトからの切断イベントのタイムスタンプを確認することで、調査の焦点を絞ることができます。このタイムスタンプで発生している既知の広域ネットワークイベント、またはローカル電源イベントはありますか？この前に、関連する可能性のある監査証跡の変更はありましたか？

切断イベントが見つからず、トンネルが依然として不安定と報告される場合、Catoとリモートピアとの間のパラメータの不一致により、再キー処理の際に問題が発生している可能性があります。さらなる分析については、以下の手順に従ってください。

サイトIPsec接続履歴の閲覧

重要: このファイルがCMAで利用できない場合（ファイルが見つからない）、フェーズ1（またはIKEv2のIKE_SA）がリモートピアと交渉されていないことを意味します。 IKEおよび認証のパラメータが両方のピア間で一致していることを確認してください。

ネットワーク > サイト > サイト設定 > IPsec にあるタイムラインは、切断されたIPsecサイトのトラブルシューティングに不可欠です。

タイムラインボタンから提供されるCSVは、関連するトンネルログの履歴を表示します。これらのログは、IPsec接続における接続不足の原因となる問題を明確に示すことができます。代表的なメッセージの一般的な例は以下の通りです：

トラフィックセレクタが一致しないことを示すメッセージは、ピアのフェーズ2設定間の構成不一致の証拠であり、特にIPsecピアリングの各側に利用可能なサブネットに関するものです。これが原因として示唆されるエラーが表示された場合、IPsec設定の不一致を解決するをご覧ください。

上記のメッセージも構成の不一致を示しており、今回は認証ペイロードに関するものです。もちろん、接続が成功するためには、PSKがこれらのペイロードと一致する必要があります。これらがどの接続試行でも明らかである場合、IPsec設定の不一致を解決するをご覧ください。

上記のタイムラインは、構成されたピアとの接続試行を示していますが、応答を受け取りませんでした。このタイムラインでは、ピアとのやり取りがなく、非アクティブのためSAが閉じられたことがわかります。これは通常、リモートピアへのL3到達性がない場合に発生します。このような場合は、ピア接続性の解決を参照してください。

IKEv1およびIKEv2の可能なタイムラインエラーメッセージの完全なリストはこちらで見つけることができます。

パケットキャプチャを使用したトラブルシューティング

注意: パケットキャプチャを取得する際、トンネル用に設定したPoP IPは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が一致しない場合です:

一方向パケット

パケットキャプチャは、ピアとのIPレベルでの接続問題を特定するのにも役立ちます。以下の例では、パケットキャプチャは一方通行の送信トラフィックのみを示しており、ピアが到達不能であることを示唆しています。トラブルシューティングの管理者が到達不能のピアを確認した場合、ピア接続性の解決に進んでください。

IKEv1またはIKEv2のピア間での上記のインスタンスやその他の設定不一致の指標がある場合、IPsec設定の不一致の解決に進んでください。

VPN上での低パフォーマンスのトラブルシューティング

VPN上で低パフォーマンスが見られる場合、これは通常、パケットロス、高レイテンシー、または頻繁な切断の形で現れます。

トンネルを通過するトラフィックではパケットロスが見られる可能性があり、それは影響を受けているアプリケーションを通じて確認され、IPsec接続を介して一方のホストから他方のホストへのICMPプローブでテストすることにより確認できます。

レイテンシーとトンネル切断もアプリケーションパフォーマンスに現れ、該当するサイトのネットワーク > サイト監視 > ネットワークアナリティクスページで判断できます。

パフォーマンス問題が特定された場合、アンダーレイパフォーマンスの解決に進んでください。

Azure IPSecでのパケットドロップ

AzureとIPSecを構成する際、トンネルスループットと1秒あたりのパケット数（PPS）は、VPNゲートウェイのSKUおよび使用される暗号化アルゴリズムによって決まります。例えば、Microsoft のドキュメントによると、VpnGw3 Generation2 ゲートウェイは、GCMAES256 を使用する際に最大で毎秒 140,000 パケット (PPS) を処理可能です。

トラフィックがこれらのしきい値を超えると、Azure は自動的に余分なパケットをドロップし、パフォーマンスの顕著な低下を引き起こす可能性があります。一般的な症状の一つにスループットの減少がありますが、これは CMA のネットワークアナリティクスでトラフィック量の減少として現れる可能性があります。しかし、これを診断するより正確な方法は、Azureポータル内でVPNゲートウェイのメトリックを直接モニタリングすることであり、これにより影響を受けたVPN接続のトンネルスループットとPPS値をリアルタイムで把握できます。

この問題を緩和するために、より高い IPSec SKU にアップグレードするか、Azure vSocket をデプロイすることを検討できます。これらのいずれも、VPN トンネルの容量を高め、トラフィックの過負荷によるパケットドロップを防ぐことができます。

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

ピア接続性の解決

IPsec ピアが PoP にパケットを送信していない、タイムラインエントリやパケットキャプチャで示されるようなシナリオでは、CMA でトンネルに割り当てられたのと同じ IPアドレスに接続するようにリモートピアが設定されていることを確認してください。

この構成が確認された場合、リモートピアが NAT で制約された接続をポート 4500 およびポート 500 でのトラフィックに応答することで通過できることを確認してください。 NAT-T (NAT Traversal) はリモートピアに有効化する必要があります。

遠隔ピアデバイスがインターネット経由で ICMP リクエストに応答するように設定されている場合、デバイスのパブリック IP に対する ICMP リクエストをテストすることで、その一般的な到達可能性をテストすることもできます。

最近のステータスページの健全性の変更を確認してください - PoPに問題がある場合、これはIPsecトンネルに影響を与える可能性があります（各トンネルは1つのCato PoP ロケーションに接続されています）。ステータスページで Cato PoP の健康状態を監視できます。

リモートピアが Azure や AWS のようなクラウドベンダーである場合、それらのステータスページも確認できます。

この IPsec 接続でピアデバイスが依然として到達不能な場合、IPsec 接続のために公開アクセス可能であることを確認するため、管理者に連絡してください。

IPsec 設定の不一致を解決する

変換セットのピア設定が、サイト > IPsec ページの設定と一致することを確認してください。

特定のトランスフォームセットと一致するようにカト側のピアリングを設定するには、関連する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をピンする能力をテストしてください。遅延やパケットロスがトンネルと一致する場合、問題がリモート環境にあることが結論付けられます。

カトサポートへのケースの提出

上記の問題解決ステップの結果とともにサポートチケットを投稿してください。チケットには以下の情報を含めてください：

タイムスタンプを含む関連するタイムラインのエントリ
関連するパケットキャプチャ
一致する設定の確認、サブネット関連および認証/暗号化パラメータを含む