Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

例:Junos OS での PKI の設定

この例では、PKI を構成、確認、およびトラブルシューティングする方法を示します。このトピックは、以下のセクションで構成されています。

要件

この例では、以下のハードウェアとソフトウェアのコンポーネントを使用しています。

  • Junos OS リリース 9.4 以降

  • Junos OS 拡張サービスリリース 8.5 から 9.3

  • SRXシリーズ デバイスまたはJシリーズ デバイス

メモ:

この設定例は、記載されているソフトウェア リリースを使用してテストされており、それ以降のすべてのリリースで動作することを想定しています。

ネットワークトポロジー

図 1 に、ポリシーベースの VPN を構成するためにこの例で使用するネットワーク トポロジーを示します。

1: ネットワーク トポロジ図 Network Topology Diagram

必要な設定

メモ:

PKI の管理は、ポリシーベース VPN とルートベース VPN の両方で同じです。

この例では、次の設定を前提としています。

  • リモートVPNピアは、ジュニパーネットワークスのSSG5ファイアウォール/VPNデバイスです(支店で最もよく使用されます)。

  • デバイスの内部 LAN インターフェイスは ge-0/0/0 ゾーン信頼にあり、プライベート IP サブネットがあります。

  • デバイスのインターネット インターフェイスは ge-0/0/3 ゾーンが信頼されておらず、パブリック IP があります。

  • ローカルLANとリモートLAN間のすべてのトラフィックが許可され、どちらの側からでもトラフィックを開始できます。

  • SSG5は正しく事前設定されており、すぐに使用できるローカル証明書、CA証明書、およびCRLがロードされています。

  • SSG5デバイスは、ssg5.juniper.net(IKE ID)のFQDNを使用するように構成されています。

  • 1024 ビット鍵を持つ PKI 証明書が、両側の IKE ネゴシエーションに使用されます。

  • CA は、両方の VPN ピアのドメイン labdomain.com にあるスタンドアロン CA です。

メモ:

Junos OS での PKI の管理と使用に関する手順の詳細については、『 Junos OS セキュリティ設定ガイド』を参照してください。

メモ:

Microsoft や OpenSSL などの PKI ベンダーの CA の使用方法の詳細については、「 付録 B: 共通証明機関の管理」を参照してください。

メモ:

SSG5およびその他のジュニパーネットワークスのScreenOSベースのプラットフォームでのPKI設定の詳細については、こちらをご覧ください。 Juniper Networks PKI(公開鍵インフラストラクチャ)入門およびFAQ、 ScreenOSでX.509証明書を使用するを参照してください。

構成

このトピックは、次のセクションで構成されています。

PKI の基本的な構成手順

手順

  1. ギガビットイーサネットインターフェイス(ge-0/0/0.0 および ge-0/0/3.0)にIPアドレスとプロトコルファミリーを設定します。

  2. インターネットネクストホップへのデフォルトルートを設定します。

    この例では、VPNトラフィックは の1.1.1.1ネクストホップを持つインターフェイスge-0/0/0.0で受信しています。したがって、トラフィックはインターフェイスge-0/0/3.0上で発信されます。トンネル ポリシーでは、着信インターフェイスと発信インターフェイスを考慮する必要があります。

    メモ:

    オプションで、OSPF などの動的ルーティング プロトコルを使用できます(このドキュメントには記載されていません)。新しいセッションの最初のパケットを処理する場合、Junos OS デバイスはまずルート検索を実行します。デフォルトルートでもある静的ルートは、発信VPNトラフィックのゾーンを決定します。

  3. システムの時刻と日付を設定します。

    コンフィギュレーションがコミットされたら、 コマンドを使用してクロック設定 show system uptime を確認します。

  4. NTP サーバ アドレスを設定します。

  5. ドメイン ネーム システム (DNS) 構成を設定します。

    多くの CA は、ホスト名(FQDN など)を使用して PKI のさまざまな要素を指定します。CDP は通常、FQDN を含む URL を使用して指定されるため、Junos OS デバイスで DNS リゾルバーを設定する必要があります。

    [edit]
    user@host# set system name-server 4.2.2.1
    user@host# set system name-server 4.2.2.2
    

  6. 次の方法で証明書要求を生成します。

    • CA 設定を指定する CA プロファイルの作成。

    • PKCS10 証明書要求の生成。

      PKCS10 証明書要求プロセスでは、公開鍵と秘密鍵のペアを生成し、その鍵ペアを使用して証明書要求自体を生成します。

      メモ:

      CA プロファイルに関する次の情報をメモします。

      • CA プロファイルは、認証局の属性を定義します。

      • 各 CA プロファイルは、CA 証明書に関連付けられています。古い CA 証明書を削除せずに、新規または更新された CA 証明書をロードする必要がある場合は、新しいプロファイルを作成する必要があります。このプロファイルは、CRL のオンライン・フェッチにも使用できます。

      • 異なるユーザー用に作成されたシステムに複数のそのようなプロファイルが存在する可能性があります。

    手順
    1. 次の必須値を持つ信頼済み CA プロファイルを作成します。

      • CA プロファイル名 — (この例では ms-ca) (任意の値)

      • CA アイデンティティ - labdomain.com。(CA ドメイン名)

    2. 失効チェックを作成して、証明書の失効を確認する方法を指定します。

      メモ:

      オプション disable を使用して失効チェックを無効にするか、 を選択して crl CRL属性を設定できます。

    3. CRL を更新する頻度を指定するために、更新間隔を時間単位で設定します。既定値は、CRL での次の更新時刻、または次の更新時刻が指定されていない場合は 1 週間です。

    4. CRL (HTTP または LDAP) を取得する場所 (URL) を指定します。デフォルトでは、URL は空で、CA 証明書に埋め込まれた CDP 情報を使用します。

      メモ:

      URL には、ldap://<ip-or-fqdn>:<port> などのサーバー名/ポート情報を含めることができます。ポート番号がない場合、HTTP はポート 80 を使用し、LDAP はポート 443 を使用します。現在、構成できる URL は 1 つだけです。バックアップ URL 構成のサポートは利用できません。

    5. 証明書の要求を CA 管理者に直接送信する電子メール アドレスを指定します。

      メモ:

      証明書要求の送信先に CA 管理者の電子メール アドレスを指定すると、システムは証明書要求ファイルから電子メールを作成し、指定された電子メール アドレスに転送します。電子メールの状態通知が管理者に送信されます。

      メモ:

      証明書の要求は、帯域外方式を使用して CA に送信できます。

    6. 設定をコミットします。

    7. キーペア要求を生成します。

      CA プロファイルを構成したら、次のステップは、Junos OS デバイス上でキー ペアを生成することです。秘密キーと公開キーのペアを生成するには:

      PKCS10 証明書要求が生成され、保留中の証明書または証明書要求としてシステムに保管されます。CA の管理者 (この例では certadmin@labdomain.com) に電子メール通知が送信されます。

      メモ:

      現在、Junos OSはRSAアルゴリズムのみをサポートしており、デジタル署名アルゴリズム(DSA)はサポートしていません。証明書 ID と呼ばれる一意の ID を使用して、生成されたキーペアに名前を付けます。この ID は、証明書の登録コマンドと要求コマンドで、適切なキー ペアを取得するためにも使用されます。生成されたキー ペアは、証明書 ID と同じ名前のファイル内の証明書ストアに保存されます。ファイル サイズは、512、1024、または 2048 ビットです。

      メモ:

      既定の (フォールバック) プロファイルは、中間 CA がデバイスにプレインストールされていない場合は作成できます。デフォルトのプロファイル値は、特別に設定された CA プロファイルがない場合に使用されます。

      CDP の場合は、次の順序に従います。

      • CA プロファイルごと

      • CA 証明書に埋め込まれた CDP

      • デフォルトの CA プロファイル

      既定のプロファイルではなく、特定の CA プロファイルを使用することをお勧めします。

  7. ローカル・デジタル証明書要求を PKCS-10 形式で生成します。

    メモ:

    PKCS10 証明書のサンプルでは、要求は "BEGIN CERTIFICATE REQUEST" 行で始まり、"END CERTIFICATE REQUEST" 行で終わり、"END CERTIFICATE REQUEST" 行を含みます。この部分は、登録のために CA にコピーして貼り付けることができます。必要に応じて、"ms-cert-req" ファイルをオフロードして CA に送信することもできます。

    CA に送信する PKCS10 証明書要求を生成します。

    使用可能なオプションは次のとおりです。

    • certificate-id — ローカル・デジタル証明書および公開鍵と秘密鍵のペアの名前。これにより、適切なキーペアが証明書要求に使用され、最終的にはローカル証明書に使用されるようになります。

    • subject — 共通名、部門、会社名、都道府県、国を含む識別名形式:

      • CN — 共通名

      • OU — 部署

      • O — 会社名

      • L — 地域

      • ST — 状態

      • C — 国

      • CN — 電話

      • DC — ドメイン コンポーネント

        メモ:

        すべてのサブジェクト名のコンポーネントを入力する必要はありません。また、各タイプの複数の値を入力できることにも注意してください。

    • domain-name — FQDN。FQDN は、IKE ネゴシエーションの証明書所有者の ID を提供し、サブジェクト名の代替名を提供します。

    • filename (path | terminal) — (オプション) 証明書要求を配置する場所、またはログイン端末。

    • ip-address — (オプション)デバイスのIPアドレス。

    • email — (オプション)CA 管理者の電子メール アドレス。

      メモ:

      ドメイン名、IP アドレス、または電子メール アドレスのいずれかを使用する必要があります。

    ドメイン名、IP アドレス、または電子メール アドレスは、IKE ID の種類を定義します。IKE ID タイプは、ステップ 22 の IKE ゲートウェイ プロファイルで設定します。

    生成された証明書要求は、指定されたファイルの場所に格納されます。証明書要求のローカル コピーは、ローカル証明書ストレージに保存されます。管理者がこのコマンドを再発行すると、証明書要求が再度生成されます。

    PKCS10 証明書要求は、指定されたファイルと場所に保存され、そこからダウンロードして登録のために CA に送信できます。ファイル名または場所を指定していない場合は、CLI のコマンドを使用して PKCS10 証明書要求の詳細 show security pki certificate-request certificate-id <id-name> を取得できます。コマンド出力をコピーして、CA サーバーの Web フロントエンドまたは電子メールに貼り付けることができます。

  8. 証明書要求を CA に送信し、証明書を取得します。

    管理者が証明書要求を CA に送信します。CA 管理者は、証明書要求を確認し、Junos OS デバイス用に新しい証明書を生成します。Junos OSのデバイス管理者が、CA証明書とCRLとともにこれを取得します。

    CA 証明書、デバイスの新しいローカル証明書、および CA からの CRL を取得するプロセスは、CA の構成と使用しているソフトウェア ベンダーによって異なります。

    証明書を取得する方法の詳細については、「 付録 B: 共通証明機関の管理」を参照してください。

    メモ:

    Junos OSは、次のCAベンダーをサポートしています。

    • 委託

    • ベリサイン

    • マイクロソフト

    OpenSSL などの他の CA ソフトウェア サービスを使用して証明書を生成することもできますが、これらの証明書は Junos OS によって検証されません。

    Junos OSは、X.509証明書標準に準拠する他のベンダーにサポートを拡張する場合があります。

  9. ローカル証明書、CA 証明書、および CRL を読み込みます。

    取得した証明書(ローカル証明書、CA 証明書、CRL)は、CLI を使用して FTP 経由で Junos OS デバイスに読み込む必要があります。

    証明書には次の名前があるとします。

    • ローカル証明書 — certnew.cer

    • CA 証明書 — CA-certnew.cer

    • CRL — certcrl.crl

    メモ:

    コマンドを使用して file list、すべてのファイルがアップロードされたことを確認できます。

  10. 指定した外部ファイルからローカル ストレージに証明書を読み込みます。

    また、秘密鍵と公開鍵のペアとの適切なリンケージを維持するために、certificate-ID を指定する必要があります。この手順では、証明書を PKI モジュールの RAM キャッシュ ストレージに読み込み、関連付けられた秘密キーを確認し、署名操作を検証します。

  11. 指定された外部ファイルから CA 証明書を読み込みます。

    CA 証明書を設定されたプロファイルに関連付けるには、CA プロファイルを指定する必要があります。

  12. CRL をローカル ストレージに読み込みます。

    CRL の許容される最大サイズは 5 MB です。コマンドで、関連する CA プロファイルを指定する必要があります。

  13. すべての証明書が読み込まれていることを確認します。

    CLI インターフェイスですべてのローカル証明書の詳細を表示できます。

    メモ:

    コマンド ラインで certificate-ID を指定すると、個々の証明書の詳細を表示できます。また、出力形式を簡潔または詳細のいずれかとして選択できます。

  14. CA 証明書を表示します。

    すべての CA 証明書、または個々の CA プロファイル(指定された)の CA 証明書を表示します。

  15. CRL を表示します。

    ロードされたすべての CRL、または指定した個々の CA プロファイルの CRL を表示します。

    メモ:

    出力形式を簡潔または詳細として選択して、CRL 情報を表示できます。現時点では、どちらのオプションも同じ出力を提供します。

  16. ローカル証明書と CA 証明書の証明書パスを確認します。

  17. IPsec VPN で証明書を使用します。

    メモ:

    証明書を使用してVPNを設定する手順は、事前共有キーを使用してVPNを設定する手順と似ています。唯一の違いは、IKE(フェーズ1)ポリシーに使用される認証方法です。証明書の使用はフェーズ 1 のネゴシエーションの一部であるため、IPsec(フェーズ 2)の設定を変更する必要はありません。

    以下の構成手順では、ポリシーベースの VPN がダイヤルアップ VPN で最も一般的に使用されているため、この VPN を構成する方法について説明します。

    メモ:

    VPN設定の詳細については、『 Junos OS 拡張サービス設定ガイド』を参照してください。

    メモ:

    Junos OS拡張サービスのアプリケーションノートの詳細については、ジュニパーネットワークスのナレッジベースで入手可能なKB10182(https://kb.juniper.net/KB10182)を参照してください。

    手順

    証明書を使用してIPsec VPNを構成するには:

    メモ:

    図 1 に示されているネットワーク を参照して、以下のステップを実行します。

    1. セキュリティ ゾーンを設定し、インターフェイスを適切なゾーンにバインドします。必要なすべてのホストインバウンドサービスがインターフェイスまたはゾーンで有効になっていることを確認します。この例では、インターフェイスまたはuntrust ゾーンでインターネット IKE サービス ge-0/0/3 を有効にします。

    2. トンネルポリシーの各ゾーンのアドレス帳エントリを設定します。

    3. RSA 暗号化を使用するように IKE(フェーズ 1)プロポーザルを設定します。

    4. RSA プロポーザル、ローカル証明書、CA 証明書、および x.509 タイプのピア証明書を指定する IKE ポリシーを設定します。

    5. IKEポリシーを指定するIKEゲートウェイ設定と、ホスト名で識別される動的ピアを設定します。

      この手順は、証明書要求が以前にどのように生成されたかによって異なります。この例では、SSG5 による証明書の要求時に「CN=ssg5.juniper.net」が指定されており、IKE ID タイプがホスト名であることを意味します。

    6. IPsec(フェーズ2)VPN設定を構成します。

      必要に応じて、VPN モニター設定を構成することもできます。この例では、標準プロポーザルセットとPFSグループ2が使用されています。ただし、必要に応じて別のプロポーザルを作成できます。

    7. トンネル ポリシーを設定して、リモート オフィスのトラフィックからホスト LAN へのトラフィックを許可したり、ホスト LAN へのトラフィックを許可したり、その逆のことも許可します。また、インターネット トラフィックの送信元 NAT で、発信方向の "trust" から "untrust" への permit all ポリシーを設定します。トンネル ポリシーが permit-all ポリシーより上にあることを確認します。そうしないと、ポリシー ルックアップがトンネル ポリシーに到達しません。

    8. IPsecトラフィックのTCP最大セグメントサイズ(tcp-mss)を設定して、TCPトラフィックがフラグメント化する可能性を排除します。この手順により、デバイスのリソース使用量が削減されます。

  18. セキュリティ ゾーンを設定し、インターフェイスをゾーンに割り当てます。

    イングレス(受信)およびエグレス(発信)ゾーンは、ルート ルックアップに関係するイングレスおよびエグレス インターフェイスによって決定されます。

    この例では、パケットは で受信 ge-0/0/0され、イングレスゾーンはtrustゾーンです。

    ルート検索に続いて、エグレスインターフェイスは 、エグレスゾーン ge-0/0/3は 、untrustゾーンです。したがって、トンネルポリシーは「ゾーンからの信頼からゾーンの信頼への逆」として設定する必要があります。

  19. ゾーンごとにホストインバウンドサービスを設定します。

    ホストインバウンドサービスは、Junos OSデバイスを宛先とするトラフィック用です。これらの設定には、FTP、HTTP、HTTPS、IKE、PING、RLOGIN、RSH、SNMP、SSH、Telnet、TFTP、traceroute が含まれますが、これらに限定されません。

    この例では、すべてのホスト受信サービスがゾーン信頼から許可される必要があることを前提としています。セキュリティ上の理由から、IKE ネゴシエーションの実行に必要なインターネットに直接接続されたゾーンの信頼されていない場合にのみ IKE を許可します。ただし、管理やトラブルシューティングのサービスなどの他のサービスも、必要に応じて個別に有効にすることができます。

  20. 各ゾーンのアドレス帳エントリを構成します。

    この例では、アドレス帳オブジェクト名local-netとremote-netを使用しています。アドレス帳名でサポートされる文字に関して、いくつかの制限があります。詳細については、Junos OS ドキュメントを参照してください。

  21. RSA 暗号化を使用するように IKE(フェーズ 1)プロポーザルを設定します。

    この例では、3DES 暗号化、SHA1 認証アルゴリズム、および Diffie-Hellman グループ 2 鍵を使用しています。

  22. IKEポリシーを設定します。

    フェーズ1の交換は、メインモードまたはアグレッシブモードのいずれかで実行できます。

    メイン モードは、通常、静的 IP ピアを持つサイト間 VPN に使用されます。アグレッシブ モードは、動的 IP およびダイヤルアップ ピアに使用されます。

    この例では、IKE IDにホスト名(通常は動的トンネルに使用されます)が使用されているにもかかわらず、両側に静的IPアドレスがあるため、メインモードを使用しています。

  23. IKEゲートウェイを構成します。

    リモート IKE ピアは、IP アドレス、FQDN/U-FQDN、または ASN1-DN(PKI 証明書)によって識別できます。

    この例では、ピアは FQDN(ホスト名)によって識別されます。したがって、ゲートウェイIKE IDはリモートピアドメイン名である必要があります。フェーズ 1 のセットアップ中に IKE ゲートウェイを正しく識別するには、正しい外部インターフェイスまたはピア ID を指定する必要があります。

  24. IPsecポリシーを設定します。

    この例では、 および esp-group2- aes128-sha1 プロポーザルを含むesp-group2-3des-sha1標準プロポーザルセットを使用します。ただし、固有のプロポーザルを作成し、必要に応じて IPsec ポリシーで指定することもできます。

  25. IKEゲートウェイとIPsecポリシーを使用してIPsec VPNを構成します。

    この例では、トンネル ポリシーで VPN 名を参照して、 ike-vpn セキュリティ アソシエーションを作成する必要があります。さらに、アイドル時間とプロキシ ID がトンネル ポリシーのアドレスと異なる場合は、必要に応じて指定できます。

  26. VPNトラフィックの双方向トンネルポリシーを設定します。

    この例では、ホスト LAN からリモート オフィス LAN へのトラフィックに、「送信元ゾーン信頼からゾーン信頼なし」トンネル ポリシーが必要です。ただし、リモート LAN からホスト LAN へのセッションを開始する必要がある場合は、反対方向のトンネル ポリシー「from-zone untrust to-zone trust」も必要です。ペアポリシーと反対の方向にポリシーを指定することで、VPNは双方向になります。アクションに加えて permit 、使用するIPsecプロファイルも指定する必要があることにも注意してください。さらに、必要に応じてポリシー上でソースNATを有効にすることができますが、それはこのアプリケーションノートの範囲を超えています。トンネル ポリシーの場合、アクションは常に許可されることに注意してください。実際、アクションが拒否のポリシーを設定している場合、トンネルを指定するオプションは表示されません。

  27. インターネットトラフィックのセキュリティポリシーを設定します。

    ゾーンの信頼からゾーンの信頼へのすべてのトラフィックを許可するには、セキュリティ ポリシーが必要です。

    デバイスは、指定された source-nat interfaceを使用し、送信トラフィックの送信元 IP アドレスとポートを変換し、エグレス インターフェイスの IP アドレスを送信元 IP アドレスとし、送信元ポートにはランダムに上位のポートを使用します。必要に応じて、特定のトラフィックを許可/拒否するためのより詳細なポリシーを作成できます。

  28. ポリシー リストは上から下に読み取られるため、セキュリティ ポリシーは階層内のトンネル ポリシーの下にある必要があることに注意してください。このポリシーがトンネル ポリシーより上にある場合、トラフィックは常にこのポリシーに一致し、次のポリシーに進みません。したがって、ユーザートラフィックは暗号化されません。トンネル ポリシーをポリシーの上に移動する any-permit には、次に示すように コマンドを使用します insert policy

  29. tcp-mssトンネル全体の TCP トラフィックの設定を構成します。

    TCP-MSSは、TCP 3ウェイ ハンドシェイクの一部としてネゴシエートされます。ネットワーク上の最大送信単位(MTU)制限に対応するために、TCPセグメントの最大サイズを制限します。IPsecカプセル化のオーバーヘッドとIPおよびフレームのオーバーヘッドにより、結果のESPパケットが物理インターフェイスのMTUを超え、フラグメント化を引き起こす可能性があるため、これはVPNトラフィックにとって非常に重要です。フラグメント化は帯域幅とデバイス リソースの使用量を増加させるため、常に回避するのが最善です。

    MTUが1500以上のイーサネットベースのネットワークでは、tcp-mssに使用する推奨値は1350です。パス内にMTUの値が小さいデバイスがある場合や、PPP、フレームリレーなどのオーバーヘッドが追加されている場合は、この値の変更が必要になることがあります。一般的なルールとして、最適なパフォーマンスを得るには、さまざまな tcp-mss 値を試す必要がある場合があります。

  30. この手順では、SSG デバイスの構成に関する情報を提供します。この例の焦点はJunos OSの設定とトラブルシューティングであるため、このステップではSSGデバイスの設定について簡単に説明します。

    図1の構成設定を示すために、SSG5デバイスから関連する構成のサンプルが参照用に提供されています。

    ただし、ジュニパーネットワークスのファイアウォール/VPN製品のポリシーベースのVPNの設定に関する概念については、概念と例(C&E)ガイドを参照してください。詳細については、https://www.juniper.net/documentation/software/screenos/ で入手可能な Concepts & Example ScreenOS Reference Guide を参照してください。

    次の例は、SSG5 コンフィギュレーションの関連例です。

検証

IKE と IPsec の検証とトラブルシューティングは、IKE の識別、認証、暗号化の方法に証明書を使用する点を除き、事前共有鍵を使用したサイト間 VPN の場合と同様です。

詳細については、以下を参照してください。

  • ジュニパーネットワークスのナレッジベース (https://kb.juniper.net)

    VPNの設定やトラブルシューティング情報に関連するアプリケーションノートのリストについては、ナレッジベースID:KB10182KB10182を使用してください。

  • コンフィギュレーションガイドは https://www.juniper.net/documentation/ からお読みいただけます。

IKE と IPsec の設定を確認するには、次の手順を実行します。

IKEフェーズ1ステータスの確認

目的

IKE フェーズ 1 セキュリティ アソシエーションのステータスを確認して、VPN ステータスを確認するには。

IPsec トンネルに関連する PKI は、フェーズ 1 の設定中に形成されます。フェーズ 1 の完了は、PKI が成功したことを示します。

アクション

意味

出力は、

  • リモートピア 2.2.2.2 は で、ステータスは であり UP、これはフェーズ1確立の関連付けが成功したことを意味します。

  • リモートピアIKE ID、IKEポリシー、外部インターフェイスはすべて正しい。

  • Index 20 は、IKE セキュリティ アソシエーションごとに一意の値です。この出力の詳細を使用して、各セキュリティ アソシエーションの詳細を取得できます。 個々のセキュリティアソシエーションの詳細の確認を参照してください。

出力が正しくない場合は、次のことを示します。

  • リモート ピアのステータス Downを .

  • IKE セキュリティ アソシエーションはありません。

  • 間違ったモード タイプ(Aggr または Main)、PKI の問題、フェーズ 1 プロポーザル(両方のピアですべて一致する必要がある)などの IKE ポリシー パラメータがあります。詳細については、「 IKE、PKI、および IPsec の問題のトラブルシューティング」を参照してください。

  • IKE パケットを受信するための外部インターフェイスが無効です。設定でPKI関連の問題がないか確認するか、kmdログで他のエラーがないか確認するか、traceoptionsを実行して不一致を見つけます。詳細については、「 IKE、PKI、および IPsec の問題のトラブルシューティング」を参照してください。

個々のセキュリティ アソシエーションの詳細を取得する

目的

個々のIKEセキュリティアソシエーション(SA)の詳細をご覧ください。

アクション

意味

出力には、ロール(イニシエーターまたはレスポンダー)、ステータス、交換タイプ、認証方法、暗号化アルゴリズム、トラフィック統計、フェーズ2ネゴシエーションステータスなど、個々のIKE SAの詳細が表示されます。

出力データを使用すると、次のことができます。

  • IKE SA の役割を理解します。ピアにレスポンダの役割があると、トラブルシューティングが容易になります。

  • トラフィック統計情報を取得して、両方向のトラフィック フローを確認します。

  • 作成済みまたは進行中のIPsecセキュリティアソシエーションの数を取得します。

  • 完了したフェーズ 2 ネゴシエーションのステータスを取得します。

IPsecフェーズ2ステータスの確認

目的

IPsec(フェーズ2)セキュリティアソシエーションを表示します。

フェーズ2は、非証明書ベースのVPNの場合と同じです。

IKE フェーズ 1 が確認されたら、IPsec(フェーズ 2)セキュリティ アソシエーションを表示します。

アクション

意味

出力は、

  • 使用可能な設定済みIPsec SAペアがあります。ポート番号 500 は、標準の IKE ポートが使用されていることを示しています。それ以外の場合は、ネットワーク アドレス変換トラバーサル(NAT-T)、4500、またはランダム ハイ ポートです。

  • SPI(セキュリティ パラメータ インデックス)は、両方向に使用されます。SA の有効期間または使用制限は、秒またはキロバイトで表されます。出力では、 は、フェーズ 2 のライフタイムが 1676 秒で終了するように設定されており、 1676/ unlim ライフタイム サイズが指定されていないことを示しています。

  • この数字は ID 、各IPsec SAの一意のインデックス値を示しています。

  • 列のハイフン(-) Mon は、このSAに対してVPN監視が有効になっていないことを示します。

  • 仮想システム (vsys) はデフォルト値のゼロです。

メモ:

フェーズ2のライフタイムは、VPNが起動した後はフェーズ1に依存しないため、フェーズ1のライフタイムと異なる場合があります。

メモ:

VPN監視の詳細については、 https://www.juniper.net/documentation/ で入手可能なJunos OSの完全なドキュメントを参照してください。

IPsecセキュリティアソシエーションの詳細の表示

目的

インデックス番号で識別される個々の IPsec SA の詳細を表示します。

アクション

意味

出力には、ローカル ID とリモート ID が表示されます。

プロキシIDが一致しないと、フェーズ2の完了に失敗する可能性があります。プロキシー ID は、トンネル ポリシーから取得されます(ポリシーベース VPN の場合)。ローカルアドレスとリモートアドレスはアドレス帳エントリーから派生し、サービスはポリシー用に設定されたアプリケーションから派生します。

プロキシIDの不一致が原因でフェーズ2が失敗した場合は、ポリシーに設定されているアドレス帳エントリを確認し、正しいアドレスが送信されていることを確認します。また、ポートが一致していることも確認します。サービスを再確認して、リモート サーバーとローカル サーバーでポートが一致していることを確認します。

メモ:

送信元アドレス、宛先アドレス、またはアプリケーションのトンネル ポリシーで複数のオブジェクトが設定されている場合、そのパラメータの結果プロキシ ID はゼロに変更されます。

たとえば、トンネル ポリシーで次のシナリオを想定します。

  • 10.10.10.0/24 および 10.10.20.0/24 のローカル アドレス

  • 192.168.168.0/24のリモートアドレス

  • アプリケーション as junos-http

結果のプロキシ ID は、ローカル 0.0.0.0/0、リモート 192.168.168.0/24、サービス 80 です。

結果として得られるプロキシIDは、リモートピアが2番目のサブネット用に設定されていない場合、相互運用性に影響を与える可能性があります。また、サードパーティベンダーのアプリケーションを使用している場合は、照合するプロキシIDを手動で入力する必要があります。

IPsecを完了できない場合は、kmdログを確認するか、traceoptionsを設定します。詳細については、「 IKE、PKI、および IPsec の問題のトラブルシューティング」を参照してください。

IPsec SA統計情報の確認

目的

IPsec SAの統計情報とエラーを確認します。

トラブルシューティングのために、カプセル化セキュリティ ペイロード/認証ヘッダー(ESP/AH)カウンターに特定の IPsec SA のエラーがないか確認します。

アクション

意味

出力のエラー値ゼロは、正常な状態を示します。

このコマンドを複数回実行して、VPN全体でパケット損失の問題を確認することをお勧めします。このコマンドからの出力には、暗号化および復号化されたパケット カウンター、エラー カウンターなどの統計情報も表示されます。

エラーが発生している ESP パケットとその理由を調査するには、セキュリティ フロー トレース オプションを有効にする必要があります。詳細については、「 IKE、PKI、および IPsec の問題のトラブルシューティング」を参照してください。

VPN全体におけるトラフィックフローのテスト

目的

フェーズ 1 とフェーズ 2 が正常に完了したら、VPN 全体でトラフィック フローをテストします。コマンドを使用して、トラフィックフロー ping をテストできます。ローカルホストからリモートホストにpingを実行できます。Junos OSデバイス自体からpingを開始することもできます。

この例では、Junos OSデバイスからリモートホストに対してpingリクエストを開始する方法を示しています。なお、Junos OS デバイスから ping を開始する場合、正しいルート ルックアップが行われ、ポリシー ルックアップで適切なゾーンが参照されるように、ソース インターフェイスを指定する必要があります。

この例では、インターフェイスは ge-0/0/0.0 ローカルホストと同じセキュリティゾーンに存在し、ポリシー検索をゾーン信頼からゾーン不信頼にするために、pingリクエストで指定する必要があります。

アクション

接続の確認

目的

リモート・ホストとローカル・ホスト間の接続を確認します。

アクション

意味

リモートホストからローカルホストへのコマンドを使用して、エンドツーエンドの接続 ping を確認できます。この例では、コマンドはSSG5デバイスから開始されます。

エンドツーエンド接続の失敗は、ルーティング、ポリシー、エンド ホスト、または ESP パケットの暗号化/復号化に問題があることを示している可能性があります。失敗の正確な原因を確認するには:

  • IPsec SA統計の確認で説明されているように、エラーの詳細についてはIPsec統計を確認してください。

  • エンド ホストと同じサブネット上のホストからコマンドを使用して ping 、エンド ホストの接続を確認します。エンド ホストに他のホストから到達可能な場合は、エンド ホストに問題はないと想定できます。

  • ルーティングおよびポリシー関連の問題のトラブルシューティングのためのセキュリティ フロー トレース オプションを有効にします。

    この例では詳細は説明しませんが、 詳細については、https://kb.juniper.net/ から入手できるJunos OSのVPN関連のアプリケーションノートをご覧ください。

IKE、PKI、および IPsec の問題のトラブルシューティング

基本的なトラブルシューティング手順は次のとおりです。

  1. 問題を特定して切り分ける。

  2. 問題をデバッグしています。

トラブルシューティングを開始する一般的なアプローチは、OSI層の最下層を使用し、OSIスタックを上って障害が発生した層を確認することです。IKE、PKI、および IPsec のトラブルシューティングの手順は次のとおりです。

  • 物理リンクおよびデータリンクレベルでインターネットリンクの物理接続を確認します。

  • Junos OSデバイスがインターネットネクストホップに接続でき、リモートIKEピアに接続できることを確認します。

  • IKEフェーズ1の完了を確認します。

  • IKE フェーズ 1 が正常に完了した場合は、IKE フェーズ 2 の完了を確認します。

  • VPN全体のトラフィックフローを確認します(VPNが稼働している場合)。

Junos OSにはtraceoptions機能が搭載されています。この機能を使用すると、traceoption フラグを有効にして、traceoption からログ ファイルにデータを書き込むことができます。ログ ファイルは事前に決定することも、手動で設定してフラッシュ メモリに保存することもできます。これらのトレース ログは、システムの再起動後も保持できます。traceoptionsを実装する前に、使用可能なフラッシュストレージを確認してください。

コンフィギュレーション・モードでtraceoptions機能を有効にし、traceoptions機能を使用するようにコンフィギュレーションをコミットすることができます。同様に、traceoptionsを無効にするには、設定モードでtraceoptionsを非アクティブ化し、設定をコミットする必要があります。

デバイスの空きディスク容量を確認する

問題

デバイスファイルシステムの空きディスク容量に関する統計を確認します。

ソリューション

/dev/ad0s1a オンボードフラッシュメモリを表し、現在35%の容量です。

メモ:

使用可能なシステムストレージは、J-Webインターフェイスのシステムストレージオプションの[ システムストレージ ]で確認できます。

メモ:

traceoptionsを有効にして、指定したファイル名にトレースデータを記録したり、デフォルトのログファイルに記録して、トレース操作の出力を受け取ることができます。

traceoptionsの出力は/var/log/kmdに置かれます。

ログ ファイルを確認してさまざまなシナリオを確認し、ログ ファイルを FTP にアップロードする

問題

ログ ファイルを表示して、セキュリティ IKE デバッグ メッセージ、セキュリティ フロー デバッグ、および syslog へのログ記録の状態を確認します。

ソリューション

メモ:

コマンドを使用して、/var/log ディレクトリ show log 内のすべてのログのリストを表示できます。

ログ ファイルは、コマンドを使用して file copy FTP サーバーにアップロードすることもできます。

ftp://10.10.10.10/kmd.log 100% of 35 kB 12 MBps

IKEトレースオプションを有効にして、IKE上のメッセージを表示します

問題

IKEまたはIPsecの成功または失敗のメッセージを表示するには、 コマンドを使用してキー管理プロセス(kmd)ログ show log kmd を表示します。kmdログにはいくつかの一般的なメッセージが表示されるため、IKEおよびPKIトレースオプションを有効にして詳細を確認すると便利な場合があります。

メモ:

一般的には、レスポンダ ロールを持つピアをトラブルシューティングするのがベスト プラクティスです。失敗の原因を理解するには、イニシエーターとレスポンダーからトレース出力を取得する必要があります。

IKE トレース オプションを設定します。

ソリューション

メモ:

フィールドにファイル名 <filename> を指定しない場合、すべての IKE トレース オプションが kmd ログに書き込まれます。

トレース・データをログに書き込むには、少なくとも 1 つのフラグ・オプションを指定する必要があります。例えば:

  • file size — 各トレース ファイルの最大サイズ(バイト単位)。たとえば、1m または 1000000 は、1 MB の最大ファイル サイズを生成できます。

  • files — 生成され、フラッシュに保存されるトレース ファイルの最大数。

メモ:

トレースを開始するには、設定をコミットする必要があります。

PKI トレース オプションを有効にして、IPsec でメッセージを表示する

問題

PKI トレースオプションを有効にして、IKE の障害が証明書に関連しているのか、PKI 以外の問題に関連しているのかを特定します。

ソリューション

証明書に関する IKE セットアップの問題をトラブルシューティングするための IKE および PKI トレース オプションの設定

問題

IKE および PKI トレースオプションの推奨設定を構成します。

メモ:

IKE トレース オプションと PKI トレース オプションは同じパラメータを使用しますが、PKI 関連トレースのデフォルト ファイル名は pkid ログにあります。

ソリューション

フェーズ 1 成功メッセージの分析

問題

IKEフェーズ1およびフェーズ2の条件が成功したコマンドの出力 show log kmd を理解します。

ソリューション

サンプル出力は、次のことを示しています。

  • 1.1.1.2 — ローカルアドレス。

  • ssg5.juniper.net — リモートピア(FQDN付きホスト名)。

  • udp: 500 — NAT-T がネゴシエートされなかったことを示します。

  • Phase 1 [responder] done — フェーズ1のステータスと役割(イニシエーターまたはレスポンダー)を示します。

  • Phase 2 [responder] done — プロキシID情報とともにフェーズ1ステータスを示します。

    IKEフェーズ1のステータスの確認に記載されている検証コマンドを使用して、IPsec SAステータスを確認することもできます。

フェーズ 1 の失敗メッセージの分析(プロポーザルの不一致)

問題

IKEフェーズ1の条件が失敗であるコマンドの出力 show log kmd を理解します。この手順は、VPN がフェーズ 1 を確立しない理由を特定するのに役立ちます。

ソリューション

サンプル出力は、

  • 1.1.1.2 — はローカルアドレスです。

  • ssg5.juniper.net — リモートピア(FQDN付きホスト名)を示します。

  • udp: 500 — NAT-T がネゴシエートされなかったことを示します。

  • Phase-1 [responder] failed with error (No proposal chosen) — プロポーザルの不一致によるフェーズ1の失敗を示します。

この問題を解決するには、レスポンダとイニシエーターの両方でIKEゲートウェイフェーズ1プロポーザルのパラメーターが一致していることを確認します。また、VPN のトンネル ポリシーが存在することも確認します。

フェーズ 1 失敗メッセージ(認証失敗)の分析

問題

IKEフェーズ1の状態が不合格の場合のコマンド show log kmd の出力を理解します。これは、VPNがフェーズ1を確立しない理由を特定するのに役立ちます。

ソリューション

サンプル出力は、

  • 1.1.1.2 — はローカルアドレスです。

  • 2.2.2.2 — リモートピア

  • Phase 1 [responder] failed with error (Authentication failed) — 有効なゲートウェイ ピアからの着信要求をレスポンダが認識できないため、フェーズ 1 に失敗したことを示します。PKI 証明書を使用する IKE の場合、このエラーは通常、誤った IKE ID タイプが指定または入力されたことを示します。

この問題を解決するには、以下に基づいて、ローカル ピアで正しいピア IKE ID タイプが指定されていることを確認します。

  • リモートピア証明書の生成方法

  • 受信したリモートピア証明書のサブジェクト代替名または DN 情報

フェーズ 1 の失敗メッセージ(タイムアウト エラー)の分析

問題

IKEフェーズ1の状態が不合格の場合のコマンド show log kmd の出力を理解します。

ソリューション

サンプル出力は、次のことを示しています。

  • 1.1.1.2 — はローカルアドレスです。

  • 2.2.2.2 — リモートピア

  • Phase 1 [responder] failed with error(Timeout) — フェーズ1の失敗を示します。

    このエラーは、IKE パケットがリモート ピアへの途中で失われたか、リモート ピアからの応答が遅れているかないことを示します。

このタイムアウト・エラーは PKI デーモンからの応答を待機した結果であるため、PKI トレース・オプションの出力を検討して、PKI に問題があるかどうかを確認する必要があります。

フェーズ 2 の失敗メッセージの分析

問題

IKEフェーズ2の条件が不合格の場合のコマンドの出力 show log kmd を理解します。

ソリューション

サンプル出力は、

  • 1.1.1.2 — はローカル アドレスです。

  • ssg5.juniper.net — リモートピア(IKE IDタイプ、FQDN付きホスト名)です。

  • Phase 1 [responder] done — フェーズ1の成功を示します。

  • Failed to match the peer proxy ids — 誤ったプロキシ ID を受信したことを示します。前のサンプルでは、受信した 2 つのプロキシ ID は 192.168.168.0/24 (リモート) と 10.10.20.0/24 (ローカル) (service=any の場合) です。この例の構成に基づくと、予期されるローカル アドレスは 10.10.10.0/24 です。これは、ローカル ピアの設定の不一致があり、プロキシ ID の一致に失敗していることを示しています。

    この問題を解決するには、アドレス帳のエントリを修正するか、一方のピアで他方のピアと一致するようにプロキシ ID を設定します。

    また、この出力は、失敗の理由が であることも示しています No proposal chosen。ただし、この場合、メッセージ Failed to match the peer proxy idsも表示されます。

フェーズ 2 の失敗メッセージの分析

問題

IKEフェーズ2の条件が不合格の場合のコマンドの出力 show log kmd を理解します。

ソリューション

サンプル出力は、次のことを示しています。

  • 1.1.1.2 — はローカル アドレスです。

  • fqdn(udp:500,[0..15]=ssg5.juniper.net — リモートピアです。

  • Phase 1 [responder] done — フェーズ1の成功を示します。

  • Error = No proposal chosen — フェーズ 2 でプロポーザルが選択されなかったことを示します。この問題は、2 つのピア間のプロポーザルの不一致が原因です。

    この問題を解決するには、フェーズ 2 のプロポーザルが両方のピアで一致することを確認します。

IKE と PKI に関連する一般的な問題

問題

IKE および PKI に関連する一般的な問題のトラブルシューティングを行います。

traceoptions機能を有効にすると、デバッグの問題に関して、通常のログエントリから得られるよりも多くの情報を収集するのに役立ちます。traceoptions ログを使用して、IKE または PKI の失敗の原因を把握できます。

IKEとPKIの問題とtraceoptionsの出力に関する詳細な分析については、ジュニパーネットワークスのJTACサポートにお問い合わせいただくか、 https://www.juniper.net/support のジュニパーネットワークスサポートウェブサイトをご覧ください。

ソリューション

IKE および PKI 関連の問題のトラブルシューティング方法:

  • 時計、日付、タイム ゾーン、および夏時間の設定が正しいことを確認します。NTP を使用して、クロックを正確に保つ。

  • DN の "C=" (国) フィールドに 2 文字の国コードを使用していることを確認します。

    例: "USA" や "米国" ではなく "US" を使用します。一部の CA では、DN の [国] フィールドにデータを入力する必要があり、国コードの値は 2 文字の値でのみ入力できます。

  • ピア証明書が複数の OU= または CN= フィールドを使用している場合は、コンテナー方式で識別名を使用していることを確認します (シーケンスを維持する必要があり、大文字と小文字が区別されます)。

  • 証明書がまだ有効でない場合は、システム クロックを確認し、必要に応じてシステムのタイム ゾーンを調整するか、簡単なテストのために時計に日を追加します。

  • 一致するIKE IDタイプと値が設定されていることを確認します。

  • 失効チェックの失敗により、PKI が失敗する可能性があります。これを確認するには、失効チェックを一時的に無効にし、IKE フェーズ 1 が完了できるかどうかを確認します。

    失効チェックを無効にするには、コンフィギュレーションモードで以下のコマンドを使用します。

    set security pki ca-profile <ca-profile> revocation-check disable