更正就緒錯誤和警告

就緒性錯誤和警告會抑制您順利完成就緒性檢查的能力。 本主題提供更正不同類型錯誤及警告的相關資訊。

檢視錯誤記錄中的更多資訊

若要檢視詳細的錯誤訊息,請使用 SSH 連線至 Ubuntu 主機,並使用 tailless 檢視 /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 檔案提供關於就緒性驗證檢查的詳細診斷資訊。 請檢視此資訊以進一步分析連線錯誤,並判斷是否需要額外的設定變更。

  1. 登入至準備就緒檢查錯誤訊息中所提及的 Ubuntu 超級監控程式。 在就緒檢查操作期間,虛擬機管理程式名稱會顯示於錯誤詳細資訊中。
  2. 前往 vSRX 目錄。
    cd /home/vSRX
    
  3. 檢視就緒檢查日誌檔案 precheck.log
    tail -f precheck.log
    

更正連線功能錯誤

進行就緒檢查時,您可能會遇到以下兩類連線錯誤:

  • 主機 (Ubuntu) SSH 連線功能錯誤
  • 閘道 (vSRX) SSH 連線功能錯誤

許多錯誤發生的原因是檢查需要 root SSH 存取主機作業系統 ( Ubuntu ) 或 vSRX 閘道的私有 IP 位址。 如果 SSH 連線功能檢查失敗,則動作無法繼續。

如需建立 SSH 會話的詳細資訊,請參閱 使用 SSH 存取裝置。 請記住,在步驟 3 中,所提供的範例是 admin 使用者。 為進行就緒檢查,請將 root 使用者取代為 vSRX 及 硬體(主機)。 此外,請確定您使用專用 IP 搭配此程序,而非公用 IP。

要驗證連接,請使用網關設備詳細資料頁面的硬體部分(對於 Ubuntu 主機)或 vSRX 部分(對於網關)中列出的根 Gateway Appliance 打開到 Ubuntu 主機或 vSRX's 私有 IP 的 SSH 會話。 請確定可以建立 SSH 階段作業。

如果無法建立階段作業,請檢查下列潛在問題。

若為主機 (Ubuntu) SSH 連線功能錯誤:

  • Ubuntu 防火牆是否封鎖對專用 IP 的 SSH 存取? 防火牆規則必須容許 SSH 存取專用 10.0.0.0/8 子網路。 如需相關資訊,請參閱服務網路的 IBM Cloud IP 範圍
  • 「Gateway Appliance 詳細資料」頁面上列出的 root 密碼是否為 root 使用者的正確密碼? 如果沒有,請按一下 硬體 區段中的裝置鏈結,並導覽至 密碼。 選取 動作> 編輯認證,並變更密碼以符合 Ubuntu 主機上的實際 root 密碼。
  • SSH 伺服器是否已停用 root 登入?
  • SSH 伺服器已停用或已停止?
  • 在 Ubuntu 主機上是否已停用 root 使用者帳戶?

對於閘道 (vSRX) SSH 連線功能錯誤:

  • vSRX 防火牆是否阻止 SSH 存取專用 IP? 防火牆規則必須容許 SSH 存取專用 10.0.0.0/8 子網路。 如需相關資訊,請參閱服務網路的 IBM Cloud IP 範圍
  • 「Gateway Appliance 詳細資料」頁面上列出的 root 密碼是否為 root 使用者的正確密碼? 否則,請按一下 root 密碼旁邊的 編輯 圖示 「編輯」圖示,並變更密碼以符合 vSRX的實際 root 密碼。
  • root 使用者帳戶是否已停用 SSH 訪問vSRX?

更正錯誤 1119

vSRX 可能有封鎖透過 telnet 存取本機主控台的設定。 檢查下列組態,並在重試預先檢查作業之前移除該組態:

set system ports console disable set system ports console insecure

其他問題可能包括 vSRX 密碼不正確。

有時,即使 vSRX 設定看似有效,且預期控制台設定(設定系統埠為控制台禁用或不安全模式)未被配置,仍可能發生就緒檢查錯誤1119。 此問題可能源於 Ubuntu 主機上的設定檔不完整 /etc/hosts 或配置不當,導致在telnet測試期間無法成功解析localhost。 請確定 localhost 已明確地對應到 IP 位址 127.0.0.1。 若映射缺失或錯誤,將導致就緒腳本無法連接到 vSRX 控制台埠。

下列指令說明如何正確設定 etc/hosts 檔案,並將其對應到您的 localhost。

在映射 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) 指令時,與 localhost 的 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-dataexplicit-priority 標籤。 在 19.4R2-S3 及以後的版本中,不再允許使用這些標籤。

例如,下列 syslog 配置包含兩個標籤 (set system syslog file messages structured-dataset 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 配置,確定並重試就緒狀態檢查。

指令 set interfaces.. 搭配 tcp-mss

下列未記載配置可能在 20.4R2-S2之前的版本中確定,但在 20.4R2-S2中失敗。 請注意 19.4R3-S2中 show configurationunsupported 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 可能會觸發不想要的結果。

如需相關資訊,請參閱「Juniper 知識庫」中的 (SRX)IPsec 在 SRX-A 是起始者時啟動,但在 SRX-A 變成回應者時失敗。 有關這些設定的詳細資訊,請參閱 VPN(安全性)

更正警告 1177

偵測到一個或多個具有 dynamic-application any 設定的安全區策略規則。 如果 vSRX 未隨「內容安全組合 (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

閘道上執行的 vSRX 版本未經 IBM Cloud 認證,因此不受支援。 OS Reload(重新載入作業系統)和 Rebuild Cluster(重建叢集)等作業會以 Gateway Details(閘道詳細資訊)頁面上列出的版本覆寫目前不支援的 vSRX 版本。 因為vSRX版本未經認證IBM Cloud,建議您聯絡 IBM支援 要遷移到此處找到的認證版本:IBM Cloud Juniper vSRX支援的版本

更正警告 1180

在 Gateway 上找到的 vSRX 授權不是透過 IBM Cloud 來取得,因此不受支援。 OS Reload(重新載入作業系統)和 Rebuild Cluster(重建叢集)等作業會以 Gateway Details(閘道詳細資訊)頁面上列出的版本覆蓋目前的授權。 支援的 vSRX 授權可在這裡找到: 檢視及變更 vSRX 授權。 如果授權是在 IBM Cloud之外採購,請使用該採購來源以取得支援。 否則,請聯絡 IBM 支援,遷移到支援的 vSRX 授權。

更正警告 1181

閘道上的 vSRX 授權及版本都不受支援。 如需解決這些警告的協助,請參閱 更正警告 1179更正警告 1180