Weitere Informationen im Fehlerprotokoll anzeigen lassen

Um detaillierte Fehlermeldungen anzuzeigen, verbinden Sie sich mit SSH mit Ihrem Ubuntu-Host und verwenden Sie tail oder less, um die Datei /home/vSRX/precheck.log zu untersuchen.

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

Details zu Verbindungsfehlern abrufen

Wenn die verfügbaren Informationen zu Konnektivitätsfehlern nicht ausreichen, können Sie die detaillierte Diagnoseausgabe überprüfen, die auf den Hypervisoren vSRX Ubuntu generiert wird. Die Datei precheck.log enthält ausführliche Diagnosen zu den Bereitschaftsvalidierungsprüfungen. Überprüfen Sie diese Informationen, um die Konnektivitätsfehler weiter zu analysieren und festzustellen, ob zusätzliche Konfigurationsänderungen erforderlich sind.

1. Melden Sie sich bei dem Ubuntu Hypervisor an, auf den in der Fehlermeldung zur Bereitschaftsprüfung verwiesen wird. Der Name des Hypervisors wird während der Bereitschaftsprüfung in den Fehlerdetails angezeigt.
2. Zum Verzeichnis vSRX wechseln.

   cd /home/vSRX
   

3. Überprüfen Sie die Protokolldatei der Bereitschaftsprüfung precheck.log.

   tail -f precheck.log
   

Konnektivitätsfehler beheben

Bei der Durchführung von Bereitschaftsprüfungen können die folgenden zwei Kategorien von Verbindungsfehlern auftreten:

• Fehler für die SSH-Konnektivität des Hosts (Ubuntu)
• Fehler für die Konnektivität des Gateways (vSRX)

Viele dieser Fehler treten auf, weil die Prüfungen Root-SSH-Zugriff auf die private IP-Adresse entweder des Host-Betriebssystems ( Ubuntu ) oder des Gateways vSRX erfordern. In dem Fall, dass eine SSH-Konnektivitätsprüfung fehlschlägt, kann die Aktion nicht fortgesetzt werden.

Weitere Informationen zum Herstellen einer SSH-Sitzung finden Sie unter Zugriff auf das Gerät über SSH. Beachten Sie, dass das Beispiel für Schritt 3 mit dem Benutzer admin gegeben wird. Ersetzen Sie bei einer Bereitschaftsprüfung den Benutzer root sowohl für die vSRX-Instanz als auch die Hardware (Host). Achten Sie außerdem darauf, bei diesem Verfahren Ihre private und nicht Ihre öffentliche IP-Adresse zu verwenden.

Um die Konnektivität zu überprüfen, öffnen Sie eine SSH-Sitzung entweder zur öffentlichen IP-Adresse des Ubuntu-Hosts oder zur privaten IP-Adresse von vSRX's. Verwenden Sie dazu die Root-Anmeldedaten, die im Abschnitt Hardware (für einen Ubuntu-Host) oder im Abschnitt vSRX (für das Gateway) auf der Detailseite Gateway Appliance aufgeführt sind. Vergewissern Sie sich, dass die SSH-Sitzung aufgebaut werden kann.

Falls die Sitzung nicht aufgebaut werden kann, führen Sie eine Überprüfung auf die folgenden potenziellen Probleme durch.

Bei SSH-Konnektivitätsfehlern für den Host (Ubuntu):

• Blockiert die Ubuntu-Firewall den SSH-Zugriff auf die private IP-Adresse? Die Firewallregeln müssen den SSH-Zugriff auf das private Teilnetz 10.0.0.0/8 zulassen. Weitere Informationen hierzu enthält der Abschnitt der IBM Cloud-IP-Bereiche für das Servicenetz.
• Ist das Rootkennwort, das auf der Seite 'Details zu Gateway-Appliances' angegeben ist, für den Rootbenutzer korrekt? Sollte dies nicht der Fall sein, klicken Sie im Abschnitt Hardware auf den Link für die Einheit und navigieren Sie zu Kennwörter. Wählen Sie Aktionen > Anmeldedaten bearbeiten und ändern Sie das Passwort so, dass es mit dem tatsächlichen Root-Passwort auf dem Ubuntu-Host übereinstimmt.
• Ist die Rootanmeldung für den SSH-Server inaktiviert?
• Wurde der SSH-Server inaktiviert oder gestoppt?
• Wurde das Rootbenutzerkonto auf dem Ubuntu-Host inaktiviert?

Bei SSH-Konnektivitätsfehlern für das Gateway (vSRX):

• Blockiert die vSRX-Firewall den SSH-Zugriff auf die private IP-Adresse? Die Firewallregeln müssen den SSH-Zugriff auf das private Teilnetz 10.0.0.0/8 zulassen. Weitere Informationen hierzu enthält der Abschnitt der IBM Cloud-IP-Bereiche für das Servicenetz.
• Ist das Rootkennwort, das auf der Seite 'Details zu Gateway-Appliances' angegeben ist, für den Rootbenutzer korrekt? Ist dies nicht der Fall, klicken Sie auf das Symbol Bearbeiten neben dem Rootkennwort und ändern Sie das Kennwort so, dass es dem tatsächlichen Rootkennwort für vSRX entspricht.
• Wurde das Rootbenutzerkonto für den Zugriff auf die vSRX-Instanz inaktiviert?

Korrektur des Fehlers 1119

Die vSRX hat möglicherweise eine Konfiguration, die den lokalen Konsolenzugriff über Telnet blockiert. Überprüfen Sie die folgende Konfiguration und entfernen Sie sie, bevor Sie die Vorabprüfung erneut durchführen:

set system ports console disable set system ports console insecure

Ein anderes Problem könnte ein falsches vSRX Passwort sein.

Manchmal kann der Bereitschaftsprüfungsfehler 1119 auch dann auftreten, wenn die Konfiguration von vSRX gültig zu sein scheint und die erwarteten Konsoleneinstellungen (set system ports console disable oder insecure) nicht konfiguriert sind. Dieses Problem kann aufgrund einer unvollständigen oder falsch konfigurierten /etc/hosts-Datei auf dem Ubuntu-Host auftreten, was eine erfolgreiche Auflösung von localhost während des Telnet-Tests verhindern kann. Stellen Sie sicher, dass localhost explizit auf die IP-Adresse 127.0.0.1 abgebildet wird. Eine fehlende oder falsche Zuordnung kann verhindern, dass das Bereitschaftsskript eine Verbindung mit dem Konsolenanschluss vSRX herstellt.

Die folgenden Befehle veranschaulichen, wie Sie die Datei etc/hosts korrekt konfigurieren und auf Ihren lokalen Host zuordnen.

Bevor Sie den localhost zuordnen, sieht die Datei /etc/hosts wie im folgenden Befehl gezeigt aus, wobei die IP-Adresse 127.0.0.1 nur dem Namen des Hostsystems zugeordnet ist.

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

Nachdem Sie den localhost korrekt zugeordnet haben, sieht die Datei /etc/hosts wie im folgenden Befehl gezeigt aus und der localhost ist korrekt der IP-Adresse 127.0.0.1 zugeordnet.

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

Wenn Sie die Datei /etc/hosts auf dem Hostsystem mit diesen Änderungen aktualisieren und den Befehl telnet localhost (port-number) ausführen, gelingt die Telnet-Verbindung zu Ihrem localhost, und der Pre-Check-Fehler wird behoben.

Um die Anschlussnummer für die Telnet-Verbindung zu ermitteln, führen Sie auf dem Hostsystem den Befehl virsh dumpxml (VM-Instance-Name) | grep service aus und verwenden Sie den Wert, der für den Dienst angezeigt wird. Um den VM-Instanznamen zu ermitteln, verwenden Sie den Befehl virsh list.

Fehler 1124 beheben

vSRX 18.4R1-S1 hat eine Inkompatibilität eingeführt, die in diesem Juniper-Problemberichtdokumentiert ist. Um auf diesen Bericht zugreifen zu können, benötigen Sie ein Juniper-Konto.

Wenn eine redundante Ethernet-Schnittstelle (reth-Schnittstelle) VLAN-Tagging (vlan-tagging) enthält, was dem Standard entspricht, muss die Schnittstelle auch den Tag für die VLAN-ID (vlan-id) beinhalten. Bei 18.4R1-S1 war es möglich, eine Konfiguration ohne den Tag vlan-id festzuschreiben. Neuere Versionen, wie zum Beispiel 19.4R2-S3, lassen eine solche Konfiguration nicht mehr zu.

Beispielkonfiguration ohne 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

Die Ausgabe für diese Konfiguration sieht folgendermaßen aus:

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

Um diesen Fehler zu beheben, fügen Sie den Tag vlan-id zur Konfiguration hinzu und wiederholen Sie die Bereitschaftsprüfung:

set interfaces reth2 unit 2058 vlan-id 2058

Fehler 1125 beheben

Mit vSRX 18.4R1-S1 wurde eine Inkompatibilität eingeführt, bei der die Konfiguration für Systemprotokolle (Syslog-Konfiguration) sowohl die Bezeichnung structure-data als auch die Bezeichnung explicit-priority enthalten konnte. In den Versionen 19.4R2-S3 und später sind diese Bezeichnungen nicht mehr zulässig.

Die folgende Syslog-Konfiguration enthält zum Beispiel beide Bezeichnungen (set system syslog file messages structured-data und 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

Die Ausgabe für diese Konfiguration sieht folgendermaßen aus:

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

Um dieses Problem zu beheben, entfernen Sie eine der Syslog-Bezeichnungen aus der Konfiguration und wiederholen Sie die Bereitschaftsprüfung.

Nicht unterstützte vSRX-Konfigurationsbefehle korrigieren

Juniper vSRX enthält nicht dokumentierte oder ausgeblendete CLI-Befehle. Die Konfiguration vSRX unterstützt einige dieser Befehle nicht, obwohl sie in manchen Versionen ausgeführt werden können. Manchmal kann sich das Verhalten zwischen Releaseversionen unerwartet ändern. Die folgenden Informationen beschreiben einige bekannte, nicht unterstützte Konfigurationsbefehle, die beim Upgrade von einer älteren Version des vSRX auftreten können. Es ist äußerst wichtig, dass Sie nicht unterstützte oder versteckte Befehle aus der Konfiguration von vSRX entfernen, bevor Sie ein Upgrade auf eine neuere Version durchführen. Führen Sie diesen Vorgang auch bei Befehlen durch, die von der Bereitschaftsprüfung nicht erkannt werden.

Fehler 1145 korrigieren

Zum Entfernen der Richtlinien und Konfigurationen im Zusammenhang mit dem Identitätsprovider. Führen Sie die folgenden Befehle aus, um alle Abhängigkeiten zusammenzustellen:

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

Löschen Sie anschließend die Konfigurationszeilengruppe für jede dieser Abhängigkeiten.

Beispiel:

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

Fehler 1147 korrigieren

Ähnlich wie im vorherigen Abschnitt kann eine Änderung in der Art und Weise, wie Junos die Konfiguration im Sicherheitsabschnitt analysiert, zu Fehlern wie den folgenden führen:

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

Beispiele für diese Konfiguration sind:

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

Die Verwendung von * als abschließendes Zeichen und Präfix ist nicht mehr gültig. Eine alternative Konfiguration ist:

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

Um dieses Problem zu beheben, ändern Sie die vSRX-Konfiguration nach Bedarf, schreiben Sie die Bereitschaftsprüfung fest und wiederholen Sie sie.

[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

Warnung 1176 beheben

Es wurde eine VPN-Konfiguration gefunden, bei der für establish-tunnels nicht der Wert immediately festgelegt war. Nach einem Upgrade ist das IKE möglicherweise nicht sofort aktiv, abhängig von den Verhandlungen mit dem entfernten Peer-Gateway und davon, ob Datenverkehr aktiv stattfindet. Ohne die Angabe von establish-tunnels immediately wird der Tunnel mit der Einstellung on-traffic erstellt. Bei Verwendung der Anweisung establish-tunnels immediately wird der Tunnel sofort erstellt, nachdem die Konfiguration festgeschrieben worden ist. Allerdings kann establish-tunnels immediately zu einem unerwünschten Ergebnis führen, wenn diese Konfiguration an beiden Enden des Tunnels verwendet wird.

Weitere Informationen finden Sie im Juniper Knowledge Base-Artikel (SRX)IPsec funktioniert, wenn SRX-A der Initiator ist, schlägt jedoch fehl, wenn SRX-A zum Responder wird. Siehe VPN(Sicherheit) für weitere Einzelheiten zu diesen Einstellungen.

Warnung 1177 beheben

Es wurden eine oder mehrere Richtlinienregeln für Sicherheitszonen mit der folgenden Konfiguration dynamic-application any erkannt. Wenn vSRX nicht mit der CSB-Lizenz (CSB: Content Security Bundle) und Datenbank für Anwendungssignaturen installiert ist, kann diese Konfiguration aufgrund von Änderungen in neueren vSRX-Versionen (wie 19.4R2-S3) zu Störungen des Datenverkehrs führen.

Sie folgende Sicherheitsrichtlinienkonfiguration enthält zum Beispiel die Bezeichnung 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

Wenn Sie eine ähnliche Konfiguration verwenden, wird empfohlen, dass Sie entweder die CSB-Lizenz und die Datenbank für Anwendungssignaturen installieren oder aber die Regel dynamic-application any entfernen.

Warnung 1179 korrigieren

Die auf dem Gateway ausgeführte Version von vSRX ist nicht auf IBM Cloud zertifiziert und wird nicht unterstützt. Vorgänge wie OS Reload und Rebuild Cluster überschreiben die aktuelle, nicht unterstützte Version von vSRX durch die Version, die auf der Seite Gateway-Details aufgeführt ist. Da die Version vSRX auf IBM Cloud nicht zertifiziert ist, wird empfohlen, sich an den IBM-Support zu wenden, um auf die zertifizierte Version zu migrieren, die Sie hier finden: IBM Cloud Juniper vSRX supported versions.

Warnung 1180 korrigieren

Die auf dem Gateway vorhandene vSRX-Lizenz wurde nicht über IBM Cloud erworben und wird nicht unterstützt. Vorgänge wie OS Reload und Rebuild Cluster überschreiben die aktuelle Lizenz mit der Version, die auf der Seite Gateway-Details aufgeführt ist. Unterstützte vSRX-Lizenzen finden Sie hier.: vSRX-Lizenzen anzeigen und ändern. Falls die Lizenz nicht über IBM Cloud erworben wurde, wenden Sie sich für Support an den jeweiligen Anbieter. Andernfalls wenden Sie sich an den IBM Support, um auf eine unterstützte vSRX Lizenz zu migrieren.

Warnung 1181 korrigieren

Die vSRX-Lizenz und -Version auf dem Gateway werden nicht unterstützt. Hilfe zum Beheben dieser Warnungen finden Sie unter Correcting warning 1179 und Correcting warning 1180.