まえがき
IKEv2は完全に新しいものであり、理解するのが難しく、VPNネットワーク構築の概念全体を完全に変えるものであると考える必要がないことをすぐに強調する必要があります。 IKE(1と2の両方)は、直接データ保護のために指定されたプロトコルが必要とする必要なキー情報をESP(または必要に応じてAH)に提供するためだけに設計されています。 ESP自体、その動作モード(トンネル/トランスポート)および関連するすべての概念は変わりません。
IKEv2の主な機能と前任者との違いについて簡単に説明します
私の意見では最も重要なことを要約します。
1.両方のプロトコルはUDP / 500(NAT-Tの場合は4500)で動作しますが、相互に互換性がありません。 IKEv1がトンネルの一方の端にあり、IKEv2がもう一方の端にあることはうまくいきません。 同時に、同じルーターはIKEv2トンネルとIKEv1トンネルの両方を同時に終了できます。 IKEv1ヘッダーと2ヘッダーには十分な違いがあるため、同じポートであっても、ルーターは処理対象を判別できます。
2. IKEv2には、プロトコルを理解しやすくする側面の1つであるアグレッシブ/メインモードなどの概念がなくなりました。
3. IKEv2では、phase1という用語はIKE_SA_INIT(暗号化/ハッシュプロトコルを交換し、DHキーを生成する2つのメッセージ)に置き換えられ、phase2はIKE_AUTH(ESPのピア認証とキー生成を直接実装する2つのメッセージ)に置き換えられます。 IKE_AUTHの通信は、IKE_SA_INITによって生成されたSAを使用して常に暗号化されます。 Isakmp SAは現在ikev2 saと呼ばれ、ipsec saはChild SAと呼ばれています。
4. IKEv2では、ピア間の認証方法が自動的にネゴシエートされなくなり、IKEv2ポリシーに関連付けられなくなりました。 つまり IKEv1の初期の各isakmpポリシーには、どのタイプの認証になるかを示す認証行があり、このポリシーが選択された場合、認証方法は手動で設定され、このピアで認証が実行されることが明確に決定されますが、これは事前共有キーによるものです。 さらに、IKEv2では非対称認証が可能になりました。 つまり エンドポイントAが証明書でエンドポイントBを認証し、Bが事前共有キーでAを認証するようにすることができます。 または、Aは事前共有キー1を使用してBを認証し、Bは事前共有キー2を使用してAを認証します。 他のオプションが可能です。 さまざまなEAP方式を使用した認証。
5. Mode Config(ikev1はフェーズ1.5と呼ばれ、リモートRAVPN / EasyVPN接続の設定に使用されるもの)、NAT-Tおよびキープアライブは、プロトコル仕様で直接記述されており、不可欠な部分です。 以前は、これらのものは必要に応じてベンダーによって実装されていました。
6. IKEv2は、DoS攻撃からコントロールプレーン(サービスプレーン)を保護するための追加のメカニズムを追加しました。 その本質は、安全な接続(IKE_SA_INIT)を確立するために各要求に応答する前に、IKEv2 VPNゲートウェイが要求要求のソースにCookieを送信し、同じ方法で応答するのを待つことです。 ソースが応答した場合-素晴らしい、それでDH生成を開始できます。 送信元が応答しない場合(DoS攻撃の場合、これが起こります-これは本質的にTCP SYNフラッド攻撃に匹敵します)、VPNゲートウェイはそれを忘れます。 このメカニズムがなければ、すべてのIKE_SA_INIT IKEv2要求がだれからでも出されるため、VPNゲートウェイはDHキー(ご存じのように非常にリソースを消費するプロセスです)を生成しようとし、すぐに(一時的ではありますが)コントロールプレーンが削除されます。
FlexVPNとは何ですか?
FlexVPNは、Cisco IOSルータにIKEv2を実装するフレームワークです。 つまり これは、IOSコマンド構文ではIKEv2 + IPSecです。 それ以上。
シスコがFlexVPNの特徴的な機能と位置付けている主な機能であるFlexVPN(Flexキーワードはフレキシブル)は、同じVPNゲートウェイ構成により、異なるタイプのトンネルをリモートアクセス、サイト間などにチェーンできることです。 。 私の意見では、VTIインターフェイスを使用する場合、従来のIKEv1構成で同じ(まあ、またはほぼ同じ)柔軟性を実現できます。 まあ、大丈夫、これが私のすべてです。
次に、FlexVPN構文の外観、使用するコマンド、意味、意味、IKEv1の類似コマンドとの関係を分析します。
IKEv2設定のFlexVPN構文
したがって、Cisco IOSのIKEv2のメイン(および、IMHO、すべて)コンポーネントは次のとおりです。
1.提案
2.ポリシー
3.キーリング
4.プロフィール
次に、順番にそれぞれ。
提案
IKEv2提案は、IKE_SA_INITフェーズを確立/保護するために使用されるアルゴリズムを制限します。 根本的には、完全ではありませんが、IKEv1の暗号isakmpポリシーに類似しています。
次のようになります。
暗号ikev2プロポーザルPROP_1 暗号化aes-cbc-256 aes-cbc-128 3des グループ14 5 2 整合性sha 256 sha1 md5
isakmpポリシーとの最初の違いは、複数のアルゴリズム/暗号化キーの長さ/ DH /ハッシュを一度に1つの提案に入れることができることです。 前述の2番目の違いは、認証は別の問題であるため、認証行がないことです。 3番目の違いは、提案が構成の独立した部分ではなく、ポリシーに配置する必要があることです。
方針
IKEv2ポリシーは、提案などのコンテナです。 最初に例を示し、次に説明します。
暗号ikev2ポリシーPOLICY_1 一致VRF VRF1 マッチアドレスローカル203.0.113.10 提案PROP_1
ご覧のとおり、ポリシーは提案を指します。 ただし、これに加えて、1)インターフェイスが配置されているVRF、リモートピアが接続されているVRFに応じて、1つまたは別の提案を選択する機能が追加されます。 2)リモートピアが接続されているローカルアドレス。 IKEv1でこの暗号isakmpポリシーを比較すると、暗号isakmpポリシーはすべての接続に対してグローバルでした。 原則として、一部のピアではポリシー1、2、3のみを使用し、他のパートでは4.5.6を使用できるようにする方法はありませんでした。 このような機会がありますが、これには大きな実用的利益があるかどうかはわかりません。 しかし、それでも...
したがって、私はもう一度強調します:
IKEv2の暗号ikev2ポリシー+暗号ikev2プロポーザルには、IKEv1の暗号isakmpポリシーと同じ役割があります。
キーリング
IKEv2キーリングは、事前共有キーを保存するリポジトリです。 明らかに、キーリングが使用され、事前共有キーの認証方法が選択されている場合にのみ意味があります。 PKIが認証に使用される場合、キーリングではなくトラストポイントを設定する必要があります。 IKEv1から類推すると、最も単純なケースでは、事前共有キーを指定するために次の構造が使用されました。
暗号isakmpキーciscoアドレスxxxx 255.255.255.0
つまり 事前共有キーは個別の構成アイテムであり、それぞれが独自のものでした。 IKEv2では、一種のコンテナ、キーリングが登場しました。これにより、構成がより構造的に見えるようになり、+いくつかの追加機能が追加されました。
HQにインストールされたvpnゲートウェイのキーリングが2つのリモートサイトと対話する場合の例(htmlでテーブルを描画する深いスキルがない場合、図として挿入します):

プロフィール
IKEv2プロファイルはFlexVPNの基礎であり、その主要コンポーネントです。 VPNゲートウェイへのリモートアクセスの「ポリシー」を定義します。 目的により、IKEv2プロファイルは、Cisco IOSのIKEv1 isakmpプロファイルまたはASAをリコールする場合のトンネルグループ(接続プロファイル)と完全に類似していますが、より多くの機能があり、設定の柔軟性がより高くなっています。 これは、VPN相互作用の参加者によって自動的にネゴシエートされるのではなく、静的に決定されるパラメータの一種のリポジトリです。 彼はどのような機能を果たしますか? VPN接続、特にIKE_INIT_SAを確立するプロセスでは、VPNゲートウェイが知る必要があります(括弧内の数字は、使用されている文献のリストへのリンクではなく、以下に示す構成行へのリンクです)。
1.接続ピアの認証方法(PKI?事前共有キー?)。 IKEv2では、前述の認証タイプはネゴシエートされないため、明示的に定義する必要があります。 FlexVPNは、このためにikev2プロファイル(1)を使用します。
2.デッドピア検出(DPD)パラメーターはどうあるべきか。 IKEv2では、DPDタイマーも自動的にネゴシエートされませんが、ikev2プロファイル(2)設定で手動で設定されます(グローバルに定義できます)。
3.事前共有キーを使用した認証の場合、リモートピアの認証に使用するキーリングは、ikev2プロファイル(3)パラメーターでもあります。
4. PKI認証の場合、リモートピア認証に使用するトラストポイントは、ikev2プロファイル(4)パラメーターでもあります。
5.リモートごちそうを紹介する方法、独自のIKEv2_IDとして選択するものはikev2プロファイル(5)パラメーターでもあります。
6.どのiVRFで-トラフィックを復号化した後(VRF対応IPSec)-ikev2プロファイル(6)パラメーター。
IKEv2プロファイルの例:
暗号ikev2プロファイルprofile_name
一致するlocal_address |証明書マップ| FVRF |リモートピアのIKEv2_ID
認証{ローカル|リモート{rsa-sig |事前共有| ecdsa-sig}} (1)
dpd interval retry-interval {オンデマンド|定期的} (2)
IDローカル{アドレス| dn |電子メール| fqdn | key-id} (5)
キーリング名(3)
ivrf名(6)
pkiトラストポイントラベル[署名| 確認] (4)
仮想テンプレート番号
つまり IKEv2プロファイルは、多くのVPN接続設定を定義します。 また、構成にはそのようなプロファイルが多数存在する可能性があり、それぞれがゲートウェイに誰が/何に接続されているか(またはゲートウェイが誰に接続されているか)に応じて異なるパラメーターセットを定義できます。 そして、この「依存」は、matchディレクティブによって決定されます(1つのプロファイルのmatchディレクティブは複数になる場合があります)。
たとえば、2つのプロファイルがあります。
暗号ikev2プロファイルPROFILE1 IDの一致リモートアドレス1.1.1.1 以下はPROFILE1プロファイルパラメータのセットです 暗号ikev2プロファイルPROFILE2 一致IDリモートfqdn remotepeer2.someorg.com 以下はPROFILE2プロファイルパラメータのセットです
この設定では、Src IP = 1.1.1.1のリモートピアがローカルゲートウェイに接続すると、PROFILE1で説明されているパラメーターがそれに適用されます(ピア)。 fqdn = remotepeer2.someorg.comのピアがローカルゲートウェイに接続されている場合、PROFILE2で説明されているパラメーターがそれに適用されます。
ここでは、目に見えない線を引く必要があります。この時点で、IOS手段でプロトコルを設定するという文脈でIKEv2と呼ばれるものはすべて終了し、新しいものはないということは必須です。 また、線を表示できます。 ここにあります:
次は?
したがって、上記の4つの構成(ポリシー、提案、キーリング、プロファイル)によって、IKEv1で呼び出されるphase1の構成が決まります。 IKEv2では、これはIKE_SA_INITですが、本質はまったく同じです。
IKE_SA_INITが構成された後はどうすればよいですか? そうだね。 IPSecプロファイルを設定し、どのトラフィックがトンネルを通過するかを決定する必要があります(プロキシACLまたはトンネルインターフェイス-ルーティングがこれを担当するVTI)。 IKEv1が2番目のフェーズ設定と呼んだものを実行します。 IKEv1とIKEv2の設定のこの部分はまったく同じです。 全体の構成がどのように見えるか、簡単な例で以下に示します。
まったく考えない
管理者が実際にすべての仕組みを掘り下げて何らかのスマート設定を実行することを本当に望んでいない/遅すぎることを望まない場合、IOSのFlexVPNは、管理者がVPNをすばやく設定するための最小限のアクションを必要とする方法でデフォルトになっていることに言及する必要があります。 このために、いわゆるスマートデフォルトが意図されています。 スマートデフォルトは、事前設定されたデフォルトのikev2プロポーザル/ポリシー/プロファイル、ipsecプロファイルなどです。 客観的には、スマートデフォルトは非常に有用であり、存在する権利があります。 構成内に既にあるのに、なぜ同じ設定を常に駆動するのですか? sh run all |を実行すると、それらを見ることができます。 暗号化。 コマンド出力は次のようになります(出力の一部は不要なため省略されています)。
暗号ikev2プロポーザルのデフォルト 暗号化aes-cbc-256 aes-cbc-192 aes-cbc-128 整合性sha512 sha384 sha256 sha1 md5 グループ5 2 暗号ikev2ポリシーのデフォルト matchfvrf any プロポーザルのデフォルト 暗号ikev2 natkeepalive 0 暗号ikev2診断エラー50 暗号ikev2 dpd 0 0定期的 暗号ikev2制限max-in-negotation-sa 40 暗号ikev2制限max-sa 0 暗号ikev2ウィンドウ5 暗号ikev2フラグメンテーションmtu 576 crypto ipsec transform-set default esp-aes esp-sha-hmac モードトランスポート 暗号ipsecプロファイルのデフォルト セキュリティアソシエーションのライフタイムキロバイトを設定する4608000 セキュリティアソシエーションのライフタイムを3600秒に設定 セキュリティアソシエーションのアイドル時間を設定しない セキュリティアソシエーションリプレイウィンドウサイズの設定なし
つまり 構成では、デフォルトでIKEv2プロポーザルとIKEv2ポリシーの両方、およびIPSecトランスフォームセットとIPSecプロファイルが構成されていることがわかります。 さらに、最も深刻なアルゴリズムが最高の優先度を持つように構成されており、これは私たちにぴったりです。 当然、VPNの最高の予測可能性は、すべてのパラメーターの手動構成によってのみ提供されますが、最後の手段として、デフォルトのパラメーターを使用できます。
例
次に、事前共有認証を使用したサイト間VPNの非常に単純な例を検討します。 トポロジは次のようになります。

Site1RouterとSite2Routerルーターの間にIPSec / IKEv2トンネルを構成し、動的ルーティングプロトコルを使用してトンネルを介して各ルーターのループバックの相互アクセスを保証する必要があります。
この場合の各ルーターの構成は次のようになります。

この例では、IKEv2とIPSecの構成に関連する構成が強調表示されています。 この例では、同じスマートデフォルトを使用します(shは上記のすべての出力を実行します-つまり、これらの設定を取得して各ルーターの構成にメンタル的に追加できます)。IKEv2ポリシー/提案、IPSecトランスフォームセットのデフォルトパラメータ。 IPSecプロファイルもデフォルトで使用されます。 構成では、ikev2プロファイルを参照し、トンネルインターフェイスでハングして保護します。 その結果、構成は非常にコンパクトで読みやすくなります。 この例からわかるように、IKEv1のフェーズ2に関連していたすべての構成は、IKEv1の構成と似ています。 つまり 同じ暗号化ipsecトランスフォームセットが作成されます(ここではデフォルトのものが使用されます)。このトランスフォームセットはikev2プロファイルと一緒にipsecプロファイルにアタッチされます。ipsecプロファイルはipsec ipv4(VTI)モードで動作するインターフェイスでハングします。
いくつかのshowコマンド
トンネルが正常にインストールされたら、いくつかのコマンドの出力を見てみましょう。
Site1Router#sh crypto ipsec sa
インターフェース:Tunnel0 暗号マップタグ:Tunnel0-head-0、ローカルアドレス10.1.12.1 保護されたVRF:(なし) ローカルident(addr / mask / prot / port):(0.0.0.0/0.0.0.0/0/0) リモートident(addr / mask / prot / port):(0.0.0.0/0.0.0.0/0/0) current_peer 10.1.23.3ポート500 許可、フラグ= {origin_is_acl、} #pktsカプセル化:1680、#pkts暗号化:1680、#pktsダイジェスト:1680 #pkts decaps:1678、#pkts decrypt:1678、#pkts verify:1678 #pkts圧縮:0、#pkts圧縮解除:0 圧縮されていない#pkts:0、#pkts compr。 失敗:0 #pktsは解凍されていません:0、#pkts解凍は失敗しました:0 #send errors 0、#recv errors 0 ローカル暗号エンドポイント:10.1.12.1、リモート暗号エンドポイント:10.1.23.3 パスmtu 1500、ip mtu 1500、ip mtu idb FastEthernet1 / 0 現在の送信SPI:0x31A6B95A(833010010) PFS(Y / N):N、DHグループ:なし インバウンドesp sas: spi:0xE6E9033F(3874030399) 変換:esp-aes esp-sha-hmac、 使用中の設定= {トンネル、} conn id:11、flow_id:11、sibling_flags 80000040、暗号マップ:Tunnel0-head-0 saタイミング:残りのキーの有効期間(k /秒):(4268866/1723) IVサイズ:16バイト リプレイ検出サポート:Y ステータス:アクティブ(アクティブ) インバウンドah sas: インバウンドpcp sas: アウトバウンドesp sas: spi:0x31A6B95A(833010010) 変換:esp-aes esp-sha-hmac、 使用中の設定= {トンネル、} conn id:12、flow_id:12、sibling_flags 80000040、暗号マップ:Tunnel0-head-0 saタイミング:残りのキーの有効期間(k /秒):(4268866/1723) IVサイズ:16バイト リプレイ検出サポート:Y ステータス:アクティブ(アクティブ)
sh crypto ipsec saの出力は、従来のIkev1をセットアップする場合と同じです。ESPは、IKEv2またはIKEv1のキー情報を誰が準備するかを気にしないからです。 次:
Site1Router#sh crypto ikev2 saの詳細
IPv4暗号IKEv2 SA Tunnel-id Local Remote fvrf / ivrf Status 1 10.1.12.1/500 10.1.23.3/500なし/なし準備完了 Encr:AES-CBC、keysize:256、Hash:SHA512、DH Grp:5、Auth sign:PSK、Auth verify:PSK 寿命/アクティブ時間:86400/12375秒 CE id:1003、Session-id:2 ステータスの説明:交渉完了 ローカルSPI:1625F2D9751CC54FリモートSPI:B9C9990767BC0006 ローカルID:10.1.12.1 リモートID:10.1.23.3 ローカル要求メッセージID:2リモート要求メッセージID:6 ローカルの次のメッセージID:2リモートの次のメッセージID:6 キューに入れられたローカル要求:2リモートに入れられた要求:6 ローカルウィンドウ:5リモートウィンドウ:5 DPDを0秒に設定、0を再試行 NAT-Tは検出されません Cisco Trust Security SGTは無効です SAのイニシエーター:いいえ
ここでは、既に使用されている暗号化/ハッシュアルゴリズム/ DHグループであるIKEv2に固有の情報が表示されています。 IKEv2プロファイルが特定のVRFに関連付けられていないこともわかります(smart-defaultが使用されたため)。 接続のイニシエーターがSite2Routerであったことがわかります。
次:
Site1Router#sh暗号エンジン接続がアクティブ
暗号エンジン接続 IDタイプアルゴリズム暗号化復号化LastSeqN IPアドレス 11 IPsec AES + SHA 0223223 10.1.12.1 12 IPsec AES + SHA 222 0 0 10.1.12.1 1003 IKEv2 SHA512 + AES256 0 0 0 10.1.12.1
ここでも、新しいものはありません。 2つの単方向IPSec SA(11と12で始まる行)と1つの双方向IKEv2 SAがあります。
予想どおり、sh crypto isakmp saの出力には何も表示されません。
Site1Router#sh crypto isakmp sa
IPv4暗号ISAKMP SA dst src state conn-id status
まあ、そのようなもの。 このテキスト全体があまりにも混乱したり、表面的すぎたりせず、誰かに役立つことを願っています。