作動可能エラーおよび警告の修正

作動可能エラーおよび警告により、作動可能検査を正常に完了できない場合があります。このトピックでは、さまざまなタイプのエラーと警告の修正に関する情報を提供します。

エラーログの詳細情報を見る

詳細なエラーメッセージを見るには、SSHで Ubuntu ホストに接続し、 tail または less を使って /home/vSRX/precheck.log ファイルを調べる。

root@vsrx:~# tail -f /home/vSRX/precheck.log
br1.         8000.f6fb18672503  no       bond1
virbr0       8000.5254009fc6e7  yes
[2025-08-11 11:10:27.909405] The remote node control link is down
[2025-08-11 11:10:27.909501] Error: the control link of other node is down
=========================
Host: vsrx FAILURE - Return code:1126

接続エラーに関する詳細情報の取得

接続エラーに関する利用可能な情報が不十分な場合、 vSRX および Ubuntu ハイパーバイザーで生成される詳細な診断出力を確認できます。この precheck.log ファイルは、準備状態検証チェックに関する詳細な診断情報を提供します。この情報を確認し、接続エラーをさらに分析して、追加の設定変更が必要かどうかを判断してください。

準備チェックのエラーメッセージで参照されている Ubuntu ハイパーバイザーにログインしてください。ハイパーバイザー名は、準備状態チェック操作中のエラー詳細に表示されます。
vSRX ディレクトリに移動してください。
```
cd /home/vSRX
```
準備チェックのログファイルを確認してください precheck.log。
```
tail -f precheck.log
```

接続エラーの修正

準備完了チェックを行う際に、以下の2種類の接続性エラーに遭遇する可能性がある：

ホスト (Ubuntu) SSH 接続エラー
ゲートウェイ (vSRX) SSH 接続エラー

これらのエラーの多くは、チェックがホストOS（ Ubuntu ）または vSRX ゲートウェイのプライベートIPアドレスへのroot SSHアクセスを必要とするために発生する。 SSH 接続検査が失敗すると、アクションを続行することはできません。

SSH セッションの確立に関する詳細については、「 SSH を使用したデバイスへのアクセス」を参照してください。ステップ3では、 admin。作動可能検査の場合は、vSRX およびハードウェア (ホスト) の両方で、代わりに root ユーザーを使用してください。また、この手順では必ずパブリック IP ではなく、プライベート IP を使用してください。

Ubuntu vSRX's 接続を確認するには、「 ハードウェア 」セクション（ Ubuntu ホストの場合）または vSRX セクション（ゲートウェイの場合）に記載されているroot認証情報を使用して、 Gateway Appliance ホストまたはのプライベートIPのいずれかに対してSSHセッションを開きます。 SSH セッションを確立できることを確認します。

セッションを確立できない場合は、次の潜在的な問題がないか確認します。

ホスト (Ubuntu) SSH 接続エラーの場合:

Ubuntu のファイアウォールがプライベート IP への SSH アクセスをブロックしていませんか? ファイアウォール・ルールはプライベートの 10.0.0.0/8 サブネットへの SSH アクセスを許可しなければなりません。サービス・ネットワークについて詳しくは、IBM Cloud IP の範囲を参照してください。
「ゲートウェイ・アプライアンスの詳細 (Gateway Appliance Details)」ページにリストされている root のパスワードは、root ユーザーの正しいパスワードですか? 違っている場合は、**「ハードウェア」 セクションにあるデバイス・リンクをクリックして「パスワード」**にナビゲートします。 [ アクション] > [認証情報の編集] を選択し、 Ubuntu ホストの実際のrootパスワードに合わせてパスワードを変更してください。
SSH サーバーの root ログインが使用不可になっていませんか?
SSH サーバーが使用不可または停止していませんか?
Ubuntu ホストで root ユーザーのアカウントが使用不可になっていませんか?

ゲートウェイ (vSRX) SSH 接続エラーの場合:

vSRX のファイアウォールがプライベート IP への SSH アクセスをブロックしていませんか? ファイアウォール・ルールはプライベートの 10.0.0.0/8 サブネットへの SSH アクセスを許可しなければなりません。サービス・ネットワークについて詳しくは、IBM Cloud IP の範囲を参照してください。
「ゲートウェイ・アプライアンスの詳細 (Gateway Appliance Details)」ページにリストされている root のパスワードは、root ユーザーの正しいパスワードですか? そうでない場合は、ルート・パスワードの横にある編集アイコンをクリックし、vSRX の実際のルート・パスワードと一致するようにパスワードを変更します。
root ユーザー・アカウントで SRX への SSH アクセスが使用不可になっていませんか?

エラー訂正 1119

vSRX、telnetによるローカル・コンソール・アクセスをブロックする設定になっている可能性がある。プレチェック作業を再試行する前に、以下の構成をチェックし、それを削除する：

set system ports console disable set system ports console insecure

その他の問題としては、 vSRX のパスワードが間違っている場合がある。

場合によっては、 vSRX の設定が有効に見え、期待されるコンソール設定（set system ports console disableまたはinsecure）が設定されていない場合でも、準備チェックエラー1119が発生することがあります。この問題は、 Ubuntu/etc/hosts ホスト上のファイルが不完全または不適切に構成されているために発生する可能性があり、telnetテスト中にlocalhostの正常な解決を妨げる場合があります。 localhostがIPアドレス 127.0.0.1 に明示的にマッピングされていることを確認してください。マッピングの欠落または誤りが原因で、準備スクリプトが vSRX コンソールポートに接続できなくなる可能性があります。

以下のコマンドは、 etc/hosts ファイルを正しく設定し、ローカルホストにマップする方法を示しています。

localhostをマップする前、 /etc/hosts ファイルは以下のコマンドのようになる。ここで、IPアドレス 127.0.0.1 はホストシステム名のみにマップされる。

root@test:~# cat /etc/hosts
127.0.0.1 test
127.0.1.1 ubuntu

localhostを正しくマッピングすると、 /etc/hosts ファイルは以下のコマンドのようになり、localhostはIPアドレス 127.0.0.1 に正しくマッピングされます。

root@test:~# cat /etc/hosts
127.0.0.1 test localhost
127.0.1.1 ubuntu

ホスト・システム上の /etc/hosts ファイルをこれらの変更で更新し、コマンド telnet localhost (port-number) を実行すると、ローカルホストへのtelnet接続が成功し、事前チェック・エラーが解消される。

telnet接続のポート番号を特定するには、ホスト・システム上でコマンド virsh dumpxml (VM-Instance-Name) | grep service を実行し、サービスに表示される値を使用する。 VM の「-Instance-Name」を確認するには、 virsh list というコマンドを実行してください。

エラー 1124 の修正

vSRX 18.4R1-S1 では、この Juniper 問題レポートに記載されている非互換性が導入されました。この報告にアクセスするには Juniper アカウントが必要です。

冗長イーサネット (reth) インターフェースに vlan-tagging (デフォルト) が含まれている場合、そのインターフェースには vlan-id タグも含まれています。 18.4R1-S1 では、vlan-id タグがなくても構成をコミットすることができました。それより新しいバージョン (19.4R2-S3 など) では、この構成は許可されなくなりました。

vlan-id がない構成の例を以下に示します。

set interfaces reth2 vlan-tagging
set interfaces reth2 mtu 9000
set interfaces reth2 redundant-ether-options redundancy-group 1
set interfaces reth2 unit 2058 family inet address xx.xx.xxx.1/26
commit check

この構成の出力は次のようになります。

root@vSRX-Node0# commit check
[edit interfaces reth2]
 ‘unit 2058’
   VLAN-ID must be specified on tagged ethernet interfaces
error: configuration check-out failed

このエラーに対処するには、以下のようにして vlan-id タグを構成に追加し、作動可能検査を再試行してください。

set interfaces reth2 unit 2058 vlan-id 2058

エラー 1125 の修正

vSRX 18.4R1-S1 では、syslog 構成に structure-data ラベルと explicit-priority ラベルの両方を含むことが許可される非互換性が導入されました。 19.4R2-S3 以降のバージョンでは、これらのラベルは使用できなくなった。

例えば、以下の syslog 構成には両方のラベル (set system syslog file messages structured-data および set system syslog file default-log-messages explicit-priority) が含まれています。

set system syslog file messages any info
set system syslog file messages authorization warning
set system syslog file messages archive size 10m
set system syslog file messages archive files 10
set system syslog file messages archive world-readable
set system syslog file messages structured-data
set system syslog file interactive-commands interactive-commands info
set system syslog file interactive-commands archive size 1m
set system syslog file interactive-commands archive files 10
set system syslog file interactive-commands archive world-readable
set system syslog file interactive-commands structured-data
set system syslog file default-log-messages any warning
set system syslog file default-log-messages authorization info
set system syslog file default-log-messages user info
set system syslog file default-log-messages firewall any
set system syslog file default-log-messages interactive-commands info
set system syslog file default-log-messages explicit-priority
set system syslog file default-log-messages structured-data
set system syslog file kmd-logs daemon info
commit check

この構成の出力は次のようになります。

[Stage 3 - Build_vSRX][2021-01-11 15:38:00.623323] Commit check failed: CommitError(edit_path: [edit system syslog file default-log-messages], bad_element: explicit-priority, message: error: ‘explicit-priority’ cannot be configured if ‘structured-data’ is configured
error: configuration check-out failed: (statements constraint check failed))

この問題を修正するには、構成からいずれかの syslog ラベルを削除し、作動可能検査を再試行してください。

サポートされない vSRX 構成コマンドの修正

Juniper vSRX には、文書化されていない、または非表示の CLI コマンドが含まれています。 vSRX の設定では、これらのコマンドの一部がサポートされていません。ただし、一部のリリースでは、それらをコミットできる場合もあります。リリース・バージョン間で動作が予期せず変更されることがあります。以下の情報は、以前のバージョンの vSRX からアップグレードする際に、サポート対象外であることが判明している設定コマンドについて詳しく説明したものです。バージョンをアップグレードする前に、 vSRX の設定から、サポート対象外または非表示のコマンドを削除することが極めて重要です。レディネスチェックで検出されないコマンドについても、この手順を実行してください。

エラー 1145 の訂正

IDP 関連のポリシーおよび構成を削除します。以下のコマンドを実行して、すべての依存関係を収集します。

show security policies | match idp | display set
show system scripts | display set
show security idp | display set

次に、これらの各依存関係の構成スタンザを削除します。

次に例を示します。

delete security policies from-zone <$zone1> to-zone <$zone2> policy
<$policy> then permit application-services idp
delete system scripts commit file templates.xsl
delete security idp

エラー 1147 の修正

前のセクションと同様に、セキュリティー・セクションで Junos が構成を解析する方法を変更すると、以下のようなエラーが発生する可能性があります。

error: Bad url pattern: *.googleapis.com/(*)

この構成の例としては、次のようなものがあります：

set security utm custom-objects url-pattern AZURE value *.googleapis.com/*
set security utm custom-objects url-pattern website value *services.site.com

* を末尾の文字および接頭部として使用することは、もはや有効ではありません。代替構成は以下のとおりです。

set security utm custom-objects url-pattern AZURE value *.googleapis.com
set security utm custom-objects url-pattern website value *.services.site.com

この問題を修正するには、必要に応じて vSRX 構成を変更し、作動可能検査をコミットしてから再試行します。

tcp-mss を指定したコマンド `set interfaces..`

以下のドキュメントに記載されていない設定は、 20.4R2-S2 以前のバージョンではコミットされる可能性がありますが、 20.4R2-S2 では失敗します。 19.4R3-S2 の show configuration からの unsupported platform 出力に注意してください。

[edit]
root@asloma-vsrx-sa-sng0102-vsrx-vSRX# set interfaces st0 unit 0 family inet tcp-mss 1372
[edit]
root@asloma-vsrx-sa-sng0102-vsrx-vSRX# commit
commit complete
[edit]
.......
...
root@asloma-vsrx-sa-sng0102-vsrx-vSRX> show configuration interfaces st0
unit 0 {
    family inet {
        ##
        ## Warning: statement ignored: unsupported platform (vsrx)
        ##
        tcp-mss 1372;
    }
}

20.4R2-S2では、同じ構成は許可されず、以下の構文エラーで失敗します。

{primary:node0}[edit]
root@asloma-tc1-10g-csb-ha1-vsrx-vSRX# set interfaces st0 unit 0 family inet tcp-mss
                                                                             ^
syntax error.

この状況では、 pre-20.4R2-S2 のバージョンから 20.4R2-S2 へアップグレードする際に問題が発生します。これは、以前の設定を新しいリリースにコミットできないため、アップグレードも失敗してしまうからです。

コマンド `set security datapath-debug..`

set security datapath-debug 設定コマンドは、アップグレード時にエラーを引き起こすことが知られています。 config からすべての datapath-debug コマンドを削除して、作動可能検査を再試行してください。例えば、以下のようなコマンドを削除します。

set security datapath-debug capture-file pcap001
set security datapath-debug capture-file format pcap
set security datapath-debug capture-file size 10m
set security datapath-debug capture-file files 5
set security datapath-debug maximum-capture-size 1500

警告 1176 の修正

establish-tunnels に設定されていない immediately を持つ VPN 構成が検出されました。アップグレード後、リモート側のゲートウェイとのネゴシエーションの状況や、データトラフィックが実際に流れているかどうかによっては、IKEが直ちに有効にならない場合があります。 establish-tunnels immediately がない場合、トンネルは on-traffic を使用して確立されます。 establish-tunnels immediately ステートメントを使用すると、トンネルは構成のコミット時に即時に確立されます。ただし、establish-tunnels immediately がトンネルの両端で構成されていると、思わしくない出力が発生することがあります。

詳細については、ジュニパー・ナレッジベースの「（SRX）SRX-A がイニシエーターの場合、IPsec は正常に動作するが、SRX-A がレスポンダーになると失敗する」を参照してください。これらの設定の詳細については、 VPN（セキュリティ）を参照してください。

警告 1177 の修正

dynamic-application any の設定が指定されたセキュリティゾーンポリシールールが1つ以上検出されました。 vSRX が、Content Security Bundle (CSB) ライセンスおよびアプリケーション・シグニチャー・データベースを使用してインストールされていない場合は、新しい vSRX (19.4R2-S3 など) での変更によって、この構成が原因でトラフィックの途絶が発生する可能性があります。

例えば、以下のセキュリティー・ポリシー構成には、dynamic-application any ラベルが含まれています。

set security policies from-zone untrust to-zone untrust policy DYNAMIC-APPLICATION-POLICY-LOCAL match dynamic-application any
set security policies from-zone untrust to-zone untrust policy DYNAMIC-APPLICATION-POLICY-LOCAL match source-address SL8
set security policies from-zone untrust to-zone untrust policy DYNAMIC-APPLICATION-POLICY-LOCAL match destination-address SL8
set security policies from-zone untrust to-zone untrust policy DYNAMIC-APPLICATION-POLICY-LOCAL then permit

同様の構成を使用している場合は、CSB ライセンスとアプリケーション・シグニチャー・データベースをインストールするか、dynamic-application any ルールを削除することをお勧めします。

警告 1179 の修正

Gateway上で動作する vSRX のバージョンは、 IBM Cloud では認定されておらず、サポート対象外です。「OSの再インストール」や「クラスタの再構築」などの操作を行うと、現在サポート対象外の vSRX バージョンが、「ゲートウェイの詳細」ページに記載されているバージョンに上書きされます。 vSRX 版は IBM Cloud で認定されていないため、 IBM のサポートに連絡し、こちらのページ（ IBM Cloud Juniper vSRX supported versions ）に記載されている認定版への移行を行うことをお勧めします。

警告 1180 の修正

Gateway にインストールされている「 vSRX 」ライセンスは、 IBM Cloud を通じて取得されたものではなく、サポート対象外です。「OSの再インストール」や「クラスタの再構築」などの操作を行うと、現在のライセンスが「ゲートウェイの詳細」ページに記載されているバージョンで上書きされます。サポートされる vSRX ライセンスは、vSRX ライセンスの表示および変更記されています。 IBM Cloud 以外からライセンスを購入した場合は、その購入元にお問い合わせください。そうでない場合は、 IBM サポートに連絡して、サポートされている vSRX ライセンスに移行してください。

警告 1181 の修正

ゲートウェイの vSRX ライセンスとバージョンの両方がサポートされていません。これらの警告の解決については、警告 1179 の修正および警告 1180 の修正を参照してください。

作動可能エラーおよび警告の修正

作動可能エラーおよび警告の修正

エラーログの詳細情報を見る

接続エラーに関する詳細情報の取得

接続エラーの修正

エラー訂正 1119

エラー 1124 の修正

エラー 1125 の修正

サポートされない vSRX 構成コマンドの修正

エラー 1145 の訂正

エラー 1147 の修正

tcp-mss を指定したコマンド set interfaces..

コマンド set security datapath-debug..

警告 1176 の修正

警告 1177 の修正

警告 1179 の修正

警告 1180 の修正

警告 1181 の修正

tcp-mss を指定したコマンド `set interfaces..`

コマンド `set security datapath-debug..`