パケットキャプチャを用いたクライアント VPN のトラブルシューティング

Last updated
Save as PDF

このドキュメントは原文を 2024年10月03日付けで翻訳したものです。

最新の情報は原文をご確認ください。

この記事では、クライアント VPN 接続時のユーザーと MX 間のトラフィックフローについて解説します。また、パケットキャプチャや Wireshark を使用したトラフィックフローのトラブルシューティング方法についても概説します。

この記事では、期待される動作やトラブルシューティング手順を含め、クライアント VPN 接続の問題をパケットキャプチャを使用して解決する際のベストプラクティスをご紹介します。

注: 本記事では、IKEv1 をアグレッシブモードではなく、メインモードで使用していることを前提としています。アグレッシブモードは、プロトコルに既知のセキュリティ上の脆弱性があるため、MX 14 以前のファームウェアバージョンでは推奨されません。また、アグレッシブモードは、MX 15 以降のファームウェアバージョンにおけるクライアント VPN ではサポートされていません。

ネゴシエーションプロセス

クライアント VPN 接続は、以下のプロセスでネゴシエートされます。

Client VPN Negotiation Process.png

このガイドでは、WAN パケットキャプチャを使用して、このプロセスの失敗をトラブルシューティングするための方法を紹介します。

WANパケットキャプチャを理解する

Client VPN WAN Pcap.png

必要に応じて、クライアントのパブリック IP と ISAKMP および ESP で WAN パケットをフィルタリングします。ネゴシエーションステップの確認のため、ISAKMP パケットの「Next payload」フィールドを探します。クライアントから送信される「Security Association」から確認していきます。

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

クライアントから ISAMKP トラフィックがない場合

クライアントがプライマリ MX の WAN IP (ウォームスペアの VIP)に接続していることを確認します。
アップストリームで UDP 500 のインバウンドトラフィックがブロックやドロップされていないかを確認します。
MX が NAT 配下にある場合、アップストリームデバイスで UDP ポート500と4500のポートフォワーディング設定が必要な場合があります。
OS 固有の原因を排除するために、異なるデバイス(別のOSやスマートフォンなど)で接続テストを実施します。

ISAKMP フェーズ 1

1. セキュリティアソシエーション(Security Association)

ISAKMP Phase 1 Security Association.png

イニシエータは Security Association を送信し、レスポンダは Security Association 応答を送信します。

2. 鍵交換(Key Exchange)

ISAKMP Phase 1 Key Exchange.png

イニシエータは Key Exchange を送信し、レスポンダは Key Exchange 応答を送信します。

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

フェーズ 1 は UDP 500 を使用し、フェーズ 2 は UDP 500 または UDP 4500(NAT-T) を使用します。

MXがクライアントに応答しない場合、以下を確認してください。
- 宛先 IP アドレスと MAC アドレス(またはウォームスペアの VIP)が正しいこと
- MX でポート 500 に対してポートフォワーディングが設定されていないこと
- クライアントが同じ MX 配下から接続試行していないこと
- クライアントのパブリック IP が、非 Meraki VPN ピア IP や現在接続している別の VPN クライアントと一致していないこと
- デフォルトのクライアント VPN 設定を上書きするような追加の設定が MX に適用されていないこと
双方で Security Association を送信し続けている場合、クライアント側でポート 500 のトラフィックが受信できていない可能性があります。
片方が Key Exchange を送信し続けている場合、以下いずれかの原因が考えられます。
- 事前共有鍵（PSK）が正しくない
- フェーズ 2 を開始するためのポート 4500 のトラフィックがドロップまたはフィルタリングされ、クライアントに到達していない

ISAKMP フェーズ 2

3. ピア識別(Identification）

ISAKMP Phase 2 Identification.png

イニシエータが Identification を送信し、レスポンダが Identification 応答を送信します。

4. ハッシュ(Hash)

ISAKMP Phase 2 Hash.png

イニシエータがハッシュを送信し、レスポンダがハッシュ応答を送信します。

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

フェーズ 2 は UDP 4500(NAT-T) または場合によっては UDP 500 を使用します。

双方がフェーズ 2 パケットを送信し続けている場合、以下いずれかの原因が考えられます。
- 暗号化設定または認証設定が正しくない
- サブネットの定義が正しくない (サイト間 VPN のみ)

クライアントデバイスの VPN 設定を確認してください。詳細は「Client VPN OS Configuration」を参照してください。

ESP

双方向の ESP トラフィックが確認できたらトンネルは確立されています。

ユーザー認証はこの段階で行われます。
WAN パケットキャプチャはこの段階以降、すべて暗号化されているため調査に利用できなくなります。
MX と認証サーバー間で認証が成功しているかを確認してください。

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

Merakiクラウド認証の場合、以下を確認します。

MX の WAN ポートからDNS経由で meraki.com を名前解決ができ、必要なすべてのクラウド接続要件がアップストリーム機器で許可されていること
Meraki デバイスのクラウド通信要件の詳細は、「クラウド接続のためのアップストリームファイアウォールルール」を参照
ダッシュボード上でアカウントの「クライアントVPNの承認」項目が「Yes」になっており、パスワードにも誤りがないこと

RADIUS 認証の場合、以下を確認します。

接続が成功するために、MX がサーバーから受信する RADIUS 認証パケットで ACCESS-ACCEPT を受け取っていること
RADIUS サーバーのイベントログ
詳細は「RADIUS問題解決ガイド」を参照

Active Directory 認証の場合、以下を確認します。

MX とサーバー間の Active Directory パケットで TLS 接続が成功していること
Active Directory サーバーのイベントログ

すべての認証タイプで共通

認証ログやパケットが表示されない場合は、クライアントが認証情報を送信していない可能性があります。
- クライアントの VPN 設定を確認してください。詳細は「Client VPN OS Configuration」を参照してください。
- 問題が特定のクライアントで発生している場合、該当のクライアント端末でトラブルシューティングを実施してください。(例：再起動の実施、競合するソフトウェアの確認)
認証が成功しているにもかかわらずクライアントが接続に失敗する場合、クライアント VPN サブネットの IP プールが枯渇していないか確認してください。