セキュリティと VPN : IPSec ネゴシエーション/IKE プロトコル

IPsec FAQ: Avaya はなぜ ASA のコードアップグレードの後で IPSec VPN によって接続することできるもはや電話ではないですか。

2015 年 11 月 26 日 - 機械翻訳について
その他のバージョン: PDFpdf | 英語版 (2015 年 8 月 22 日) | フィードバック

概要

この資料は Avaya が電話が組み込みインターネット プロトコル セキュリティ(IPsec)クライアントを使用するシステムで配置されるとき直面する問題を記述したものです。

Atri Basu およびグスタボ マディーナによって貢献される、Cisco TAC エンジニア。

Avaya が Cisco 適応性があるセキュリティ アプライアンス モデル(ASA)のコードアップグレードの後で IPSEC VPN によって接続することできるもはや電話ではない理由

この問題を理解するために、どのようにネットワークアドレス変換走査(NAT-T)および NAT ディスカバリ(NAT-D)作業理解する必要があります。 NAT-D プロセスはこれらのステップで構成されます:

  1. IPsec ホスト間の 1つ以上の NAT デバイスを検出する。
  2. ピアが NAT-T をサポートすれば識別します。
  3. インターネット キー エクスチェンジ(IKE)の NAT デバイスを通して IPsecパケットの User Datagram Protocol (UDP; ユーザ データグラム プロトコル) カプセル化の使用をネゴシエートします。

NAT-D は各端からの他に両方の IKE 同位の IP アドレスおよびポートのハッシュします送信 します。 両端がそれらをハッシュしたらおよび計算したらその間 NAT がないことを同じ結果を、確認します生んで下さい。 送信 されます一連の NAT-D ペイロードとしてハッシュします。 各ペイロードは 1 ハッシュが含まれています。 倍数の場合には、複数の NAT-D ペイロード 送信 されますハッシュします。 通常、たった 2 つの NAT-D ペイロードがあります。 NAT-D ペイロードはメインモードの第 3 および第 4 パケットとアグレッシブモードの第 2 および第 3 パケットに含まれています。 この例はリモートアクセストンネルを使用するので、アグレッシブモードです。

NAT-D ペイロードに含まれている詳細の 1 つは Vendor ID (VID)です。 同位ヘルプ間の VID の交換は Request For Comments(RFC) 3947 に記述されているようにリモートホストの NAT-T 機能を、確認します:

The format of the NAT-D packet is:

1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload length |
+---------------+---------------+---------------+---------------+
~ HASH of the address and port
+---------------+---------------+---------------+---------------+

The payload type for the NAT discovery payload is 20.

電流は NAT-D ペイロードのペイロードのタイプをです 20 受け入れました。 ASA のデバッグを検知 する場合、見ます:

[IKEv1]IP = 192.168.96.120, IKE_DECODE RECEIVED Message (msgid=0) with payloads:
HDR + KE (4) + NONCE (10) + UNKNOWN (15), *** ERROR *** + UNKNOWN (15),
*** ERROR *** + NONE (0) total length : 232

パケットキャプチャからのスナップショットはここにあります:

電話をかけるべき ASA:

ASA への電話:

Avaya はペイロード 20 を認識しないし、ASA はペイロードのタイプ 15 を理解しません。 この動作のための説明は、2004 年に、同じ RFC が 15 とペイロードのタイプを定義したのであります。 従って、2004 年以来、このペイロードのタイプを使用する Avaya 電話はもはや対応 RFC ではないです。 このように、それはなぜより古いをコードするために使用しましたか。 、Avaya のように、より古いコード(バージョン 8.0.x)のいくつかがまだ古い ID をサポートするので。 ただし、より新しいコード(バージョン 8.2.1+)は新しい RFC 値と対応であるはずで、ペイロード type15 をサポートするべきではありません。 それにもかかわらず、そののまわりで問題を引き起こすものがであるペイロード type15 をサポートするとさまざまなバージョンがまだ見つけることができます。

組み込み VPN クライアントが右の paylod ID を使用するように電話のファームウェアを修復する Avaya 必要。 残念ながら、Avaya 他のいくつかの電話は、46xx シリーズのような生産に、もはやないし、修正を得ません。 この場合、新しい機器を得るか、または動作していたバージョンに ASA をダウングレード必要がある必要があります。 明らかにこの後のオプションは初めのバグ修正を得るためにアップグレードした場合利用できません。 報告されるより古いペイロード ID 必要を使用するおよびそれらのバージョンで解決される問題の Cisco のソフトウェア バージョン。


関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


Document ID: 116294