none
【RRAS】　RRASサービス再起動後にIKEv2接続が出来なくなる。 RRS feed

 > 

  • 質問

  • Question
    サインインして投票
    0
    サインインして投票

    お世話になります。

    RRASでVPNサーバを構成しています。
    【ルーティングとリモートアクセスの構成と有効化】を行い
    【SSL証明書のバインド】から証明書を選択し、適用しました。

    この時点では、
    IKEv2、SSTP、L2TP、PPTPはすべて接続できることを確認しました。

    その後、RRASサービスを再起動しました。
    この時点で、IKEv2で接続しようとすると、
    「13801  IKE 認証資格情報は受け付けられません」となり接続できなくなります。
    SSTP、L2TP、PPTPについては、問題なく利用が継続できます。

    検索すると、
    https://social.technet.microsoft.com/Forums/Lync/en-US/eb82a642-6061-4d53-8f0e-425188b31be9/ikev2-unable-to-connect-after-restarting-service?forum=winservergen

    や

    https://social.technet.microsoft.com/Forums/ie/en-US/97fe3d7f-57f2-4b8c-8966-01a869a6fa78/windows-rras-cannot-find-ikev2-certificate-after-restart?forum=winserver8gen

    が引っ掛かり、証明書の問題を疑われていますが、構成直後では、問題は発生しないため、証明書には問題がないと思っています。
    ５~６回ほど試しましたが、構成時点では、IKEv2接続は問題なく接続できておりサービス再起動後に、IKEv2のみ接続ができなくなります。

    この問題はどのようにすれば解消されるかご教示ください。

    2018年3月9日 21:24
    |

すべての返信

  • Question
    サインインして投票
    1
    サインインして投票

    チャブーンです。

    この件ですが、トラブルシューティングが必要な案件だと思います。で、

    が引っ掛かり、証明書の問題を疑われていますが、構成直後では、問題は発生しないため、証明書には問題がないと思っています。

    このような「思い込み」になりかねないバイアス条件はいったん外し、エラーメッセージに基づき「必要な設定が満たされているか」を順繰りで確認することが、結果的には早道です。私であれば、以下を疑い順に確認するでしょう。

    1. VPNサーバーの「FQDNが正しい」ことを確認する。具体的には「コンピューター名」の正しさと、「プライマリDNSサフィックス」の正しさを確認する。プライマリDNSサフィックスはしたの方法で確認できます。
      http://ascii.jp/elem/000/000/423/423070/
    2. VPNサーバー証明書のサブジェクト名および「代替されたサブジェクト名(SAN)」が1のFQDNと完全合致していることを確認する。サブジェクト名は必ずしも合致していなくてかまいませんが、SANは必ず合致している必要があります(未設定は事実上許されません)。SANでは「DNS名」で登録されている必要があります。Windows CAからの登録のしかたは、以下にあります。
      https://blogs.technet.microsoft.com/isablog/2011/10/09/how-to-generate-a-certificate-with-subject-alternative-names-san/
    3. VPNサーバー証明書の「格納先ストア」が正しいことを確認する。サーバー証明書は「[ローカルコンピューター]-[個人]」に格納されないと機能しません。

    個人的な見解ですが、SSTPなどIISに依存したものはIISの機能である「証明書のバインド」によって、動作可能なバインドが「意図せずできてしまう」可能性がありますが、IKEは本来この機能の対象外なので、サーバーFQDNと証明書のSAN設定が異なる場合、最終的にバインドに失敗します。最初の設定時のみこういった背景で「一見うまくいっている」ように見えているだけではないでしょうか？

    したがって私であれば、上記3点はどのようなケースでも必ずチェックする内容になるでしょう。

    フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。

    2018年3月10日 9:40
    |
    モデレータ
  • Question
    サインインして投票
    0
    サインインして投票

    お世話になります。ご連絡ありがとうございます。
    まず、個人的な見解についてですが、初回構成時時に接続したクライアントでtracertで経路を確認したところ、
    vpnサーバにて割り当てたIPを経由した経路で接続しています。
    その為、    「一見うまくいっている」という点には該当しないと思われます。

    また、1-3について構成上のに誤りがあるの状況と仮定すると、初回接続が成立すること自体が
    重大なセキュリティー上の欠陥ということでしょうか？（つながるべきでない場合につながってしまう）

    ご回答よろしくお願いいたします。

    2018年3月10日 13:01
    |
  • Question
    サインインして投票
    1
    サインインして投票

    チャブーンです。

    申し訳ないのですが、この件については、話がかみ合っていないように思います。

    前提として、「設定が正しいのに」サービス再起動だけで接続ができなくなる、というのは致命的な問題で、広範囲に起こることなら様々なユーザー間で、大問題として情報が共有されているはずです。そういう話しはネット上を含めほぼありませんので、私の環境であれば、自分側=設定の誤り、を想像しますし、それが自然だと思います。

    私自身では「個人的な見解」に書いたような話しは、経験則としてありがちな動作と承知していますので、その見地からもつながる=設定がすべて正しい、などとは思わず、確実に設定を確認します。トラブルシュートの基本として、「○○であるべきがちゃんと○○である」を確認して、はじめてほかの可能性を考慮できます。

    質問者さんとの方針が違う以上、私として申し上げられるのはここまでですので、質問者さん調査方法で解決したい、ということであれば、MS有償サポートをご検討いただくのが、総合コストの点からよろしいかと思います。

    https://www.microsoft.com/ja-jp/services/professional.aspx

    フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。

    2018年3月13日 4:09
    |
    モデレータ
  • Question
    サインインして投票
    0
    サインインして投票

    色々試した結果、事象がわかり、自分的にはすっきりしたので、クローズにしようと思います。

    結論から言うと
    サービス再起動前に接続できる　　　　←　こちらが異常な状態（たぶんバグ）
    サービス再起動後に接続出来なくなる　←　こちらが正常な状態（設定誤り）

    RRASで証明書の選択を行ったときに、L2TP/IPSec　をテストするのに事前共有キーを
    合わせて設定しました。（設定誤り）

    「OK」ボタンを押すと、ルータの再起動が促され、ここで「はい」を押すと、再起動が走るのですが、
    この再起動がどうも不十分で、事前共有キーの設定がIKEv2の方へ反映されないようです。

    その為、クライアントが接続したときに、サーバがクライアントに対して事前共有キーを要求せず
    VPNが成立していました。（接続できてはダメだけど接続できてしまう。）

    サービスからRRASのサービスを再起動すると、クライアントに対して、事前共有キーを
    要求するようになり事前共有キーを設定できるクライアントはほとんどないので、接続できなくなる。（正常な動作）

    Android strongswanクライアントがログを吐いてくれたお陰でわかりました。

    1.事前共有キーを削除して、RRASを再起動
    2.その後、事前共有キーを登録する。

    を行うと、また、「異常な状態」と化したので、
    L2TP/IPSECで事前共有キーを使い、IKEv2では、事前共有キーを使わない。
    という本来できない構成がとれます。
    理由がわかってしまえば、これはこれで便利そうなので、放置しておこうと思います。

    2018年3月15日 11:56
    |