IPSecトンネルとパケットキャプチャに関する一般的なコントロールプレーンの問題のトラブルシューティング

はじめに

このドキュメントでは、Cisco IOS® XEルータのサイト間VPNがネゴシエートされる際に、パケットキャプチャなどのツールがコントロールプレーンの問題にどのように役立つかについて説明します。

前提条件

要件

次の項目に関する知識が推奨されます。

• Cisco IOS® CLI設定に関する基本的な知識。
• IKEv2およびIPsecに関する基礎知識。

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアのバージョンに基づいています。

• CSR1000V：バージョン16.12.0を実行するCisco IOS XEソフトウェア。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

背景説明

パケットキャプチャは、VPNピアデバイス間でパケットが送受信されているかどうかを確認するのに役立つ強力なツールです。また、デバッグは論理的な解釈であり、キャプチャはピア間の物理的なインタラクションを表すため、IPSecデバッグで確認される動作がキャプチャで収集された出力と一致するかどうかも確認されます。そのため、接続の問題を確認したり、破棄したりできます。

便利なツール

キャプチャの設定、出力の抽出、および詳細な分析に役立つ便利なツールがあります。次のその一例を示します。

• Wireshark：これは広く知られ、使用されているオープンソースパケットアナライザです。
• キャプチャの監視：ルータ上のCisco IOS XE機能。キャプチャの収集に役立ち、トラフィックフローの状態、収集されたプロトコル、およびタイムスタンプの光出力を提供します。

IOS XEルータでのキャプチャの設定方法

キャプチャは、収集するトラフィックのタイプと、対象トラフィックのVPNピアまたはセグメントの送信元アドレスおよび宛先アドレスを定義する拡張アクセスリスト(ACL)を使用します。パス上でNAT-Tが有効になっている場合、トンネルネゴシエーションではUDPポート500とポート4500が使用されます。ネゴシエーションが完了してトンネルが確立されると、NAT-Tが有効な場合、対象トラフィックはIPプロトコル50(ESP)またはUDP 4500を使用します。

コントロールプレーンに関連する問題をトラブルシューティングするには、トンネルのネゴシエーション方法をキャプチャするためにVPNピアのIPアドレスを使用する必要があります。

config terminal
ip access-list extended <ACL name>
permit udp host <local address> host <peer address>
permit udp host <peer address> host <source address>
exit
exit

設定されたACLは、キャプチャされたトラフィックを絞り込むために使用され、トンネルのネゴシエーションに使用されるインターフェイスに配置されます。

monitor capture <capture name> access-list <ACL name> buffer size <custom buffer size in MB> interface <source interface of teh router> both 

キャプチャを設定したら、キャプチャを操作して停止したり、クリアしたり、次のコマンドで収集したトラフィックを抽出したりできます。

• 一般的なキャプチャ情報を確認します。show monitor capture
• キャプチャの開始/停止：monitor capture cap start/stop
• キャプチャがパケットを収集していることを確認します。show monitor capture cap buffer
• トラフィックの簡単な出力を参照してください:show monitor capture cap buffer brief
• キャプチャのクリア：monitor capture cap clear
• キャプチャ出力を抽出します。
  • キャップキャップバフダンプの監視                             
  • monitor capture cap export bootflash:capture.pcap

パケットキャプチャによるトンネル確立の分析

前述のように、IPSecトンネルをネゴシエートするには、NAT-Tが有効になっている場合、ポート500およびポート4500を使用してパケットがUDP経由で送信されます。キャプチャを使用すると、ネゴシエートされるフェーズ（フェーズ1またはフェーズ2）、各デバイスの役割（イニシエータまたはレスポンダ）、作成されたSPI値などの詳細な情報をパケットから確認できます。

ルータからのキャプチャの簡単な出力を示すと、ピア間のインタラクションが確認され、UDPパケットが送信されます。

ダンプを抽出し、pcapファイルをルータからエクスポートした後、Wiresharkを使用してパケットの詳細情報を表示できます。

送信された最初のIKE_SA_INIT ExchangeパケットのInternet Protocolセクションに、UDPパケットの送信元アドレスと宛先アドレスがあります。User Datagram Protocol（UDP；ユーザデータグラムプロトコル）セクションには、使用されているポートとInternet Security Association and Key Management Protocol(ISAKMP)セクション、プロトコルのバージョン、交換されるメッセージのタイプ、デバイスのロール、および作成されるSPIが表示されます。IKEv2デバッグを収集すると、同じ情報がデバッグログに表示されます。

IKE_AUTH交換ネゴシエーションが行われると、ペイロードは暗号化されますが、前に作成されたSPIや作成されたトランザクションのタイプなど、ネゴシエーションに関する一部の情報が表示されます。

最後のIKE_AUTH交換パケットが受信されると、トンネルネゴシエーションが完了します。

NATが中間にある場合のトランザクション

Nat-transversalは、トンネルネゴシエーションが行われるときに表示されるもう1つの機能です。中間デバイスがトンネルに使用される一方または両方のアドレスをnat処理している場合、フェーズ2（IKE_AUTH交換）がネゴシエートされると、デバイスはUDPポートを500から4500に変更します。

サイドAで取得されたキャプチャ：

サイドBで取得されたキャプチャ：

コントロールプレーンのよくある問題

トンネルネゴシエーションに影響を与えるローカルまたは外部の要因があり、キャプチャで特定することもできます。次に、最も一般的なシナリオを示します。

設定の不一致

このシナリオは、各デバイスフェーズ1およびフェーズ2の設定を確認することで解決できます。ただし、リモートエンドにアクセスできないシナリオが存在する可能性があります。どのデバイスがフェーズ1または2のいずれかでパケット内でNO_PROPOSAL_CHOSENを送信するかを特定することによって、ヘルプをキャプチャします。この応答は、設定に何らかの問題がある可能性があり、どのフェーズを調整する必要があるかを示しています。

再送信

IPSecトンネルネゴシエーションは、エンドデバイス間のパス上でネゴシエーションパケットがドロップされているために失敗する可能性があります。廃棄されるパケットは、フェーズ1またはフェーズ2のパケットです。この場合、応答パケットを期待するデバイスは最後のパケットを再送信し、5回試行しても応答がない場合、トンネルは終了し、最初から再開されます。

トンネルの両側のキャプチャは、トラフィックをブロックしている可能性のある要素と、トラフィックが影響を受ける方向を特定することによって役立ちます。