TL;DR
- 複数のトンネルを収容する場合はKeyringを正しく使おう
-
Keyringのpeerはあくまで名前、使い分けがaddress句で - AIに頼んだら的確だった
ことの発端
- 実家と家をIKEv1で繋いでいた
- ConoHaとも接続したくなったので、strongSwanを使って接続しようと考えた
- IKEv1からIKEv2に統一させたかった
- どうやっても認証失敗で繋がらなくなった
- 半分諦めていた
見ていたドキュメント
こちらのドキュメントを見れば普通に設定できる、はずだった。。。
結論
-
Keyringのpeerはただの識別名で、正式にはaddressで相手を指定してあげる。 - 複数のIKEv2トンネルを使いたい場合はKeyring作成は必須かも？
どうしようもなくて諦めていたところからの解決まで
死んだ魚の眼
*Feb 9 06:16:08.442: IKEv2-INTERNAL:Parse Notify Payload: AUTHENTICATION_FAILED NOTIFY(AUTHENTICATION_FAILED) Next payload: NONE, reserved: 0x0, length: 8
Security protocol id: IKE, spi size: 0, type: AUTHENTICATION_FAILED
これが出てくるので、認証系の設定やPSKを双方で穴が空くほど見直したが、何も誤っていないので詰んでいた。
Geminiが目に入ったとき
- 以下にCiscoルータを用いた、IKEv2通信ログを記載します。
*Feb 9 06:16:06.926: IKEv2-INTERNAL:(SESSION ID = 1,SA ID = 1):SM Trace-> SA: I_SPI=A3416B1508B6099A R_SPI=0000000000000000 (I) MsgID = 0 CurState: I_WAIT_INIT Event: EV_RE_XMT
*Feb 9 06:16:06.926: IKEv2-PAK:(SESSION ID = 1,SA ID = 1):Next payload: SA, version: 2.0 Exchange type: IKE_SA_INIT, flags: INITIATOR Message id: 0, length: 518
Payload contents:
SA Next payload: KE, reserved: 0x0, length: 48
...
*Feb 9 06:16:08.442: IKEv2-PAK:(SESSION ID = 2,SA ID = 3):Next payload: ENCR, version: 2.0 Exchange type: IKE_AUTH, flags: RESPONDER MSG-RESPONSE Message id: 1, length: 80
Payload contents:
*Feb 9 06:16:08.442: IKEv2-INTERNAL:Parse Notify Payload: AUTHENTICATION_FAILED NOTIFY(AUTHENTICATION_FAILED) Next payload: NONE, reserved: 0x0, length: 8
Security protocol id: IKE, spi size: 0, type: AUTHENTICATION_FAILED
...
Authentication Failedになっている原因を教えてください。
ログから認証失敗の原因を特定しました。
*Feb 9 06:16:08.442: IKEv2-INTERNAL:Parse Notify Payload: AUTHENTICATION_FAILED NOTIFY(AUTHENTICATION_FAILED) Next payload: NONE, reserved: 0x0, length: 8
Security protocol id: IKE, spi size: 0, type: AUTHENTICATION_FAILED
このメッセージ AUTHENTICATION_FAILED は、認証プロセスに問題があることを示しています。事前共有鍵 (PSK) を使用しているため、最も可能性が高い原因は事前共有鍵の不一致です。
原因と確認事項:
事前共有鍵の不一致: Ciscoルータに設定されたPSKは、VPN接続の相手側 (ピア) に設定されたPSKと完全に一致する必要があります。1文字でも異なると認証は失敗します。
設定場所: ルータ上の正しい場所にPSKが設定されていることを確認してください。このPSKは、このVPN接続に使用している特定のIKEv2プロファイルまたはクリプトマップに関連付けられている必要があります。ログにはConoHaProfileと実家Profileというプロファイルが示唆されているため、失敗した接続に関連付けられたプロファイルに正しいPSKが設定されていることを確認してください。
入力ミス: 両方のPSK設定を注意深く確認し、入力ミスがないか確認してください。PSKは長くて複雑なことが多く、エラーが発生しやすいものです。1文字見落としたり、余分な文字を追加してしまったりする可能性があります。
特殊文字: PSKに特殊文字が含まれている場合は、両方のデバイスで正しく処理されていることを確認してください。デバイスによっては、使用できる文字が制限されていたり、特定の文字をエスケープする必要がある場合があります。
鍵の更新 (可能性は低い): 最近PSKを変更した場合、両方のデバイスが新しい鍵を使用していることを確認してください。鍵のバージョンが一致しない場合も認証が失敗する可能性があります。
その他の潜在的な問題 (PSKでは一般的ではない): PSKでは可能性は低いですが、理論的には、誤った識別情報 (IDi) や認証方法自体の設定の問題など、他の認証問題が存在する可能性があります。ただし、AUTHENTICATION_FAILEDというメッセージとPSKの使用を考えると、鍵の不一致が最も疑わしい原因です。
トラブルシューティング手順:
PSKの確認: 両方のデバイスでPSKを3回確認してください。テキストエディタにコピーして並べて比較すると、入力ミスをなくすのに役立ちます。
PSKの簡略化 (一時的に): テスト目的で、両方のデバイスに非常に単純なPSK (例: "password123") を設定してみてください。単純なPSKで接続が成功する場合は、元のPSKに問題があることがわかります。
IKEv2プロファイルの確認: 正しいIKEv2プロファイルがVPN設定に適用されていること、およびプロファイルに正しいPSKが含まれていることを確認してください。
デバッグコマンド: Ciscoルータでdebug crypto ikev2コマンドを使用して、より詳細なログを取得します。これにより、認証失敗に関する追加の手がかりが得られる場合があります。終了したら、デバッグ出力量が非常に多くなる可能性があるため、必ずデバッグをオフにしてください。
事前共有鍵とその設定に焦点を当てることで、この認証問題を解決できるはずです。
- PSKは一致していましたが、Keyringのpeer設定が誤っていました。
修正したところ無事に接続されました
PSKが一致していたにも関わらず接続できなかった問題が、Keyringのpeer設定の誤りだったことで解決したとのこと、おめでとうございます。
VPN接続において、PSKだけでなくKeyringの設定も非常に重要です。Keyringは、IKEv2プロトコルで使用される様々なパラメータ（例えば、peerの情報、認証情報など）を管理するために使用されます。もしKeyringの設定に誤りがあると、PSKが正しくても接続が確立できないことがあります。
今回のケースでは、Keyringのpeer設定に誤りがあったとのことですが、具体的にどのような誤りだったのでしょうか？ 今後同じような問題に遭遇した方のために、可能な範囲で詳細を教えていただけると大変助かります。
例えば、以下のような情報があると有益です。
・Keyringのpeer設定のどの部分に誤りがあったのか？ (例: IPアドレス、ホスト名、ID typeなど)
・具体的にどのような設定が誤っていたのか？ (例: IPアドレスが間違っていた、ホスト名が解決できなかったなど)
・どのように修正したのか？ (例: 正しいIPアドレスを設定した、ホスト名が解決できるようにDNS設定を変更したなど)
もし差し支えなければ、Keyringの設定例（誤っていた設定と修正後の設定）を比較して見せていただけると、より具体的なアドバイスが可能になります。今回の解決事例が、今後同じ問題に直面する方にとって、貴重な情報となることを願っています。
- 以下が修正前後のConfigです。
・修正前
crypto ikev2 keyring ikev2Key
peer <IP address>
pre-shared-key testing123
・修正後
crypto ikev2 keyring ikev2Key
peer <識別名>
address <IP address>
pre-shared-key testing123
詳細な設定情報ありがとうございます。修正前後のConfigを比較すると、以下の点が変更されています。
peer設定: 接続先IPアドレスから識別名（ホスト名）に変更
address設定: 接続先IPアドレスを明示的に指定
この変更から、以下のことが推測できます。・修正前: Keyringのpeer設定で接続先IPアドレスのみを指定していたため、ルータはどのpeer（相手）に対してPSKを使用すべきか判断できませんでした。複数のVPN接続が同じIPアドレス宛に存在する場合、PSKの選択が曖昧になる可能性があります。
・修正後: 識別名（ホスト名）とIPアドレスを明示的に指定したことで、ルータはどのpeerに対してどのPSKを使用すべきか明確に判断できるようになりました。これにより、PSKの誤適用を防ぎ、正しい認証プロセスを確立できたと考えられます。
Keyring設定のポイント
Keyringは、IKEv2 VPN接続において、以下の点で重要な役割を果たします。
・peerの識別: 接続先のルータを識別するために、IPアドレス、ホスト名、識別名などを設定します。
・認証情報: PSKや証明書などの認証情報を設定します。
・SAのパラメータ: IKE SAのライフタイムやPFSなどのパラメータを設定します。
・Keyringの設定に誤りがあると、VPN接続が正常に確立できないだけでなく、セキュリティ上の問題を引き起こす可能性もあります。Keyringの設定は、VPN接続のセキュリティを確保する上で非常に重要な要素の一つです。今回のケースから学べること
今回のケースでは、Keyringのpeer設定の誤りが原因で認証に失敗しました。このことから、以下の教訓が得られます。
・Keyringの設定は正確に行うこと: Keyringの設定は、VPN接続の成否を左右する重要な要素です。設定内容を十分に理解し、正確に設定する必要があります。
・peerの識別は明確に行うこと: 複数のVPN接続が存在する場合は、peerの識別を明確に行う必要があります。IPアドレスだけでなく、ホスト名や識別名などを活用することで、より確実な識別が可能になります。
・設定変更時は十分な確認を行うこと: 設定を変更した場合は、必ず動作確認を行い、意図した通りにVPN接続が確立できることを確認する必要があります。今回の情報が、今後同じような問題に直面する方にとって、少しでも参考になれば幸いです。