Visualizzazione di ulteriori informazioni nel registro degli errori

Per visualizzare i messaggi di errore dettagliati, collegarsi all'host Ubuntu con SSH e utilizzare tail o less per esaminare il file /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

Ottenere dettagli sugli errori di connettività

Se le informazioni disponibili sugli errori di connettività non sono sufficienti, è possibile esaminare l'output diagnostico dettagliato generato sugli hypervisor vSRX Ubuntu. Il precheck.log file fornisce una diagnostica dettagliata sui controlli di validazione della prontezza. Esamina queste informazioni per analizzare ulteriormente gli errori di connettività e determinare se sono necessarie ulteriori modifiche alla configurazione.

1. Accedere all'hypervisor Ubuntu indicato nel messaggio di errore della verifica di idoneità. Il nome dell'hypervisor viene visualizzato nei dettagli dell'errore durante l'operazione di verifica della disponibilità.
2. Vai alla directory " vSRX ".

   cd /home/vSRX
   

3. Controllare il file di registro della verifica precheck.log della disponibilità.

   tail -f precheck.log
   

Correzione degli errori di connettività

Quando si eseguono i controlli di prontezza, si possono riscontrare le due seguenti categorie di errori di connettività:

• Errori di connessione SSH dell'host (Ubuntu)
• Errori di connettività SSH del gateway (vSRX)

Molti di questi errori si verificano perché i controlli richiedono l'accesso SSH root all'indirizzo IP privato del sistema operativo host ( Ubuntu ) o del gateway vSRX. Se un controllo di connettività SSH ha esito negativo, l'azione non può continuare.

Per ulteriori informazioni sulla creazione di una sessione SSH, vedere Accesso al dispositivo tramite SSH. Tenete presente che per il passo 3, l'esempio fornito è con l'utente admin. Per verificare la disponibilità, sostituire root l'utente sia per l' vSRX e che per l'Hardware (host). Inoltre, assicurati di utilizzare il tuo indirizzo IP privato con questa procedura, non il tuo indirizzo IP pubblico.

Per convalidare la connettività, aprire una sessione SSH all'host Ubuntu o all'IP privato vSRX's utilizzando le credenziali di root elencate nella sezione Hardware (per un host Ubuntu ) o nella sezione vSRX (per il gateway) della pagina Gateway Appliance Dettagli. Assicurarsi che sia possibile stabilire la sessione SSH.

Se la sessione non può essere stabilita, controllare i seguenti potenziali problemi.

Per gli errori di connettività SSH dell'host (Ubuntu):

• Il firewall Ubuntu sta bloccando l'accesso SSH all'IP privato? Le regole del firewall devono consentire l'accesso SSH alla sottorete 10.0.0.0/8 privata. Per ulteriori informazioni, vedi Intervalli IP diIBM Cloud per la rete di servizi.
• La password root elencata nella pagina Dettagli Gateway Appliance è la password corretta per l'utente root? In caso contrario, fai clic sul link del dispositivo nella sezione Hardware e passa a Passwords. Seleziona Azioni> Modifica credenziali e modifica la password in modo che corrisponda alla password root effettiva sull'host Ubuntu.
• L'accesso root è disabilitato per il server SSH?
• Il server SSH è disabilitato o arrestato?
• L'account utente root è disabilitato sull'host Ubuntu ?

Per gli errori di connettività SSH del gateway (vSRX):

• Il firewall vSRX sta bloccando l'accesso SSH all'IP privato? Le regole del firewall devono consentire l'accesso SSH alla sottorete 10.0.0.0/8 privata. Per ulteriori informazioni, vedi Intervalli IP diIBM Cloud per la rete di servizi.
• La password root elencata nella pagina Dettagli Gateway Appliance è la password corretta per l'utente root? In caso contrario, fai clic sull'icona Modifica accanto alla password root e modifica la password in modo che corrisponda alla password root effettiva per vSRX.
• L'account utente root è disabilitato per l'accesso SSH al vSRX?

Correzione dell'errore 1119

Il sito vSRX potrebbe avere una configurazione che blocca l'accesso alla console locale tramite telnet. Verificare la presenza della seguente configurazione e rimuoverla prima di riprovare l'operazione di pre-verifica:

set system ports console disable set system ports console insecure

Altri problemi potrebbero essere una password errata di vSRX.

A volte, l'errore 1119 relativo al controllo di disponibilità può verificarsi anche quando la configurazione dell' vSRX e sembra essere valida e le impostazioni previste per la console (porte di sistema impostate su console disabilitata o non sicura) non sono configurate. Questo problema può verificarsi a causa di un file incompleto /etc/hosts o configurato in modo errato sull'host Ubuntu, che può impedire la corretta risoluzione di localhost durante il test telnet. Assicurarsi che localhost sia esplicitamente mappato sull'indirizzo IP 127.0.0.1. Una mappatura mancante o errata può impedire allo script di preparazione di connettersi alla porta della console dell' vSRX.

I comandi seguenti illustrano come configurare correttamente il file etc/hosts e mapparlo sul localhost.

Prima di mappare il localhost, il file /etc/hosts appare come mostrato nel comando seguente, dove l'indirizzo IP 127.0.0.1 è mappato solo sul nome del sistema host.

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

Dopo aver mappato correttamente il localhost, il file /etc/hosts appare come mostrato nel comando seguente e il localhost è mappato correttamente all'indirizzo IP 127.0.0.1.

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

Quando si aggiorna il file /etc/hosts sul sistema host con queste modifiche e si esegue il comando telnet localhost (port-number), la connessione telnet all'host locale riesce e l'errore di pre-verifica viene risolto.

Per identificare il numero di porta per la connessione telnet, eseguire il comando virsh dumpxml (VM-Instance-Name) | grep service sul sistema host e utilizzare il valore indicato per il servizio. Per identificare il nome dell’istanza di VM, utilizzare il comando virsh list.

Correzione dell'errore 1124

vSRX 18.4R1-S1 ha introdotto un'incompatibilità documentata in questo report dei problemi Juniper. È necessario un account Juniper per accedere a questo report.

Se un'interfaccia Ethernet (reth) ridondante include vlan-tagging (che è il valore predefinito), l'interfaccia deve includere anche la tag vlan-id. In 18.4R1-S1, era possibile eseguire il commit di una configurazione senza la tag vlan-id. Le versioni più recenti, come 19.4R2-S3, non consentono questa configurazione.

Una configurazione di esempio senza 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

Il risultato di questa configurazione è:

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

Per risolvere questo errore, aggiungere la tag vlan-id alla configurazione e ripetere il controllo di disponibilità:

set interfaces reth2 unit 2058 vlan-id 2058

Correzione dell'errore 1125

vSRX 18.4R1-S1 ha introdotto un'incompatibilità che ha consentito alla configurazione syslog di contenere sia le etichette structure-data che explicit-priority. Nelle versioni 19.4R2-S3 e successive, queste etichette non sono più consentite.

Ad esempio, la seguente configurazione syslog contiene entrambe le etichette (set system syslog file messages structured-data e 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

Il risultato di questa configurazione è:

[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))

Per risolvere questo problema, rimuovere una delle etichette syslog dalla configurazione e ritentare il controllo di disponibilità.

Correzione dei comandi di configurazione vSRX non supportati

Il Juniper vSRX contiene comandi CLI non documentati o nascosti. La configurazione di vSRX non supporta alcuni di questi comandi, anche se in alcune versioni possono essere impegnati. A volte il comportamento può cambiare inaspettatamente tra le versioni della release. Le seguenti informazioni forniscono dettagli su alcuni comandi di configurazione noti non supportati quando esegui l'upgrade da una versione precedente di vSRX. È fondamentale rimuovere i comandi non supportati o nascosti dalla configurazione di vSRX prima di aggiornare la versione. Eseguite questa procedura anche con i comandi non rilevati dal controllo di prontezza.

Correzione dell'errore 1145

Per eliminare le politiche e le configurazioni correlate a IDP. Esegui i comandi seguenti per raccogliere tutte le dipendenze.

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

Quindi, eliminare la stanza di configurazione per ognuna di queste dipendenze.

Esempio:

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

Correzione dell'errore 1147

Simile alla sezione precedente, un cambiamento nel modo in cui Junos analizza la configurazione nella sezione di sicurezza può portare a errori come:

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

Esempi di questa configurazione includono:

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

L'utilizzo di * come carattere finale e prefisso non è più valido. Una configurazione alternativa è:

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

Per risolvere questo problema, modifica la configurazione di vSRX come necessario, esegui il commit e riprova il controllo della disponibilità.

[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;
    }
}

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

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

Correzione dell'avvertenza 1176

È stata rilevata una configurazione VPN con establish-tunnels non impostata su immediately. Dopo un aggiornamento, l'IKE potrebbe non essere immediatamente attivo a seconda delle negoziazioni con il gateway peer remoto e se il traffico di dati sta attivamente fluendo. Senza establish-tunnels immediately, il tunnel viene stabilito con on-traffic. Con l'istruzione establish-tunnels immediately, il tunnel viene stabilito immediatamente quando viene eseguito il commit della configurazione. Tuttavia, establish-tunnels immediately potrebbe attivare un risultato indesiderato quando configurato su entrambe le estremità del tunnel.

Per ulteriori informazioni, consultare (SRX)IPsec diventa UP quando SRX-A è l'iniziatore, ma ha esito negativo quando SRX-A diventa il responder nella Juniper Knowledge Base. Per maggiori dettagli su queste impostazioni, vedere VPN(Sicurezza).

Correzione avvertenza 1177

Sono state rilevate una o più regole dei criteri delle zone di sicurezza con la configurazione dynamic-application any. Se vSRX non è installato con la licenza di Content Security Bundle (CSB) e il database di firma dell'applicazione, questa configurazione potrebbe causare un'interruzione del traffico a causa delle modifiche nelle release più recenti di vSRX, come 19.4R2-S3.

Ad esempio, la configurazione della seguente politica di protezione contiene l'etichetta 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

Se si utilizza una configurazione simile, si consiglia di installare la licenza CSB e il database di firma dell'applicazione o di rimuovere la regola dynamic-application any.

Correzione dell'avvertenza 1179

La versione di vSRX che gira sul Gateway non è certificata su IBM Cloud e non è supportata. Operazioni come OS Reload e Rebuild Cluster sovrascrivono la versione corrente non supportata di vSRX con la versione elencata nella pagina Gateway Details. Poiché la versione vSRX non è certificata su IBM Cloud, si consiglia di contattare il IBM Support per migrare alla versione certificata che si trova qui: IBM Cloud Juniper vSRX versioni supportate.

Correzione dell'avvertenza 1180

La licenza vSRX trovata sul gateway non è stata ottenuta tramite IBM Cloud e non è supportata. Operazioni quali il Ricaricamento del sistema operativo e la Ricostruzione del cluster sovrascrivono la licenza corrente con la versione elencata nella pagina Dettagli del gateway. Le licenze vSRX supportate possono essere trovate qui: Visualizzazione e modifica delle vSRX. Se la licenza è stata procurata al di fuori di IBM Cloud, utilizzare tale fonte di approvvigionamento per il supporto. Altrimenti, contattare l'assistenza IBM per migrare a una licenza vSRX supportata.

Correzione dell'avvertenza 1181

La versione e la licenza vSRX sul gateway non sono entrambe supportate. Fare riferimento a Correzione avvertenza 1179 e Correzione avvertenza 1180 per assistenza nella risoluzione di tali avvertenze.