Afficher plus d'informations dans le journal des erreurs

Pour afficher les messages d'erreur détaillés, connectez-vous à votre hôte Ubuntu avec SSH et utilisez tail ou less pour examiner le fichier /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

Obtenir des détails sur les erreurs de connectivité

Si les informations disponibles concernant les erreurs de connectivité ne sont pas suffisantes, vous pouvez consulter les résultats détaillés du diagnostic générés sur les hyperviseurs vSRX Ubuntu. Le precheck.log fichier fournit des diagnostics détaillés sur les vérifications de validation de l'état de préparation. Examinez ces informations afin d'analyser plus en détail les erreurs de connectivité et de déterminer si des modifications supplémentaires de la configuration sont nécessaires.

1. Connectez-vous à l'hyperviseur Ubuntu mentionné dans le message d'erreur de vérification de l'état de préparation. Le nom de l'hyperviseur s'affiche dans les détails de l'erreur pendant l'opération de vérification de l'état de préparation.
2. Accéder au répertoire vSRX.

   cd /home/vSRX
   

3. Consultez le fichier journal de vérification precheck.log de l'état de préparation.

   tail -f precheck.log
   

Correction des erreurs de connectivité

Vous pouvez rencontrer les deux catégories d'erreurs de connectivité suivantes lorsque vous effectuez des contrôles de l'état de préparation :

• Des erreurs de connectivité SSH sur un hôte (Ubuntu)
• Des erreurs de connectivité SSH sur une passerelle (vSRX)

Bon nombre de ces erreurs surviennent parce que les contrôles nécessitent un accès SSH root à l'adresse IP privée du système d'exploitation hôte ( Ubuntu ) ou de la passerelle vSRX. Si une vérification de la connectivité SSH échoue, l'action ne peut pas être exécutée.

Pour plus d'informations sur l'établissement d'une session SSH, consultez la section Accéder à l'appareil à l'aide de SSH. Gardez à l'esprit que pour l'étape 3, l'exemple donné est celui de l'utilisateur admin. Pour une vérification de l'état de préparation, remplacez l'utilisateur root à la fois pour le vSRX et pour le matériel (hôte). Veillez également à utiliser votre adresse IP privée lors de cette procédure, et non votre adresse IP publique.

Pour vérifier la connectivité, ouvrez une session SSH vers l'adresse IP publique de l'hôte Ubuntu ou vers l'adresse IP privée vSRX's à l'aide des identifiants root indiqués dans la section Matériel (pour un hôte Ubuntu ) ou dans la section vSRX (pour la passerelle) de la page Détails de Gateway Appliance. Vérifiez que la session SSH peut être établie.

Si la session ne peut être établie, vérifiez s'il s'agit d'un des problèmes décrits ci-après.

Erreurs de connectivité SSH de l'hôte (Ubuntu) :

• Le pare-feu Ubuntu bloque-t-il l'accès SSH à l'IP privée ? Les règles du pare-feu doivent autoriser l'accès SSH au sous-réseau privé 10.0.0.0/8. Pour plus d'informations, voir Plages d'adresses IP IBM Cloud pour le réseau de service.
• Le mot de passe root indiqué sur la page Détails du dispositif de passerelle est-il le mot de passe correct pour l'utilisateur root ? Si ce n'est pas le cas, cliquez sur le lien du dispositif dans la section Matériel et accédez à Mots de passe. Sélectionnez Actions > Modifier les identifiants, puis modifiez le mot de passe pour qu'il corresponde au mot de passe root réel de l'hôte Ubuntu.
• La connexion root est-elle désactivée pour le serveur SSH ?
• Le serveur SSH est-il désactivé ou arrêté ?
• Le compte de l'utilisateur root est-il désactivé sur l'hôte Ubuntu ?

Erreurs de connectivité SSH de la passerelle (vSRX) :

• Le pare-feu du vSRX bloque-t-il l'accès SSH à l'IP privée ? Les règles du pare-feu doivent autoriser l'accès SSH au sous-réseau privé 10.0.0.0/8. Pour plus d'informations, voir Plages d'adresses IP IBM Cloud pour le réseau de service.
• Le mot de passe root indiqué sur la page Détails du dispositif de passerelle est-il le mot de passe correct pour l'utilisateur root ? Si ce n'est pas le cas, cliquez sur l'icône Editer en regard du mot de passe root et changez le mot de passe pour qu'il corresponde au mot de passe root réel de vSRX.
• Le compte de l'utilisateur root est-il désactivé pour l'accès SSH au vSRX ?

Correction de l'erreur 1119

Le site vSRX peut avoir une configuration qui bloque l'accès à la console locale par telnet. Vérifiez la configuration suivante et supprimez-la avant de réessayer l'opération de vérification préalable :

set system ports console disable set system ports console insecure

D'autres problèmes peuvent être liés à un mot de passe incorrect sur le site vSRX.

Parfois, l'erreur 1119 de vérification de l'état de préparation peut se produire même lorsque la configuration de l' vSRX semble valide et que les paramètres attendus de la console (set system ports console disable ou insecure) ne sont pas configurés. Ce problème peut survenir en raison d'un fichier incomplet ou /etc/hosts mal configuré sur l'hôte Ubuntu, ce qui peut empêcher la résolution réussie de localhost pendant le test telnet. Assurez-vous que localhost est explicitement mappé à l'adresse IP 127.0.0.1. Un mappage manquant ou incorrect peut empêcher le script de préparation de se connecter au port de la console d' vSRX.

Les commandes suivantes illustrent comment configurer correctement le fichier etc/hosts et le faire correspondre à votre hôte local.

Avant de mapper l'hôte local, le fichier /etc/hosts se présente comme indiqué dans la commande suivante, où l'adresse IP 127.0.0.1 est mappée uniquement avec le nom du système hôte.

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

Après avoir correctement mappé le localhost, le fichier /etc/hosts se présente comme indiqué dans la commande suivante et le localhost est correctement mappé à l'adresse IP 127.0.0.1.

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

Lorsque vous mettez à jour le fichier /etc/hosts sur le système hôte avec ces modifications et que vous exécutez la commande telnet localhost (port-number), la connexion telnet à votre hôte local réussit et l'erreur de précontrôle est résolue.

Pour identifier le numéro de port de la connexion telnet, exécutez la commande virsh dumpxml (VM-Instance-Name) | grep service sur le système hôte et utilisez la valeur indiquée pour le service. Pour identifier l' VM-Instance-Name, utilisez la commande virsh list.

Correction de l'erreur 1124

vSRX 18.4R1-S1 a introduit une incompatibilité documentée dans ce rapport d'incident Juniper. Vous avez besoin d'un compte Juniper pour accéder à ce rapport.

Si une interface Ethernet redondante inclut vlan-tagging (valeur par défaut), doit également inclure la balise vlan-id. Dans la version 18.4R1-S1, il était possible de valider une configuration sans la balise vlan-id. Les versions plus récentes, telles que la version 19.4R2-S3, ne permettent pas cette configuration.

Exemple de configuration sans 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

La sortie de cette configuration est la suivante :

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

Pour corriger cette erreur, ajoutez la balise vlan-id à la configuration et relancez la vérification de l'état de préparation :

set interfaces reth2 unit 2058 vlan-id 2058

Correction de l'erreur 1125

vSRX 18.4R1-S1 a introduit une incompatibilité permettant à la configuration syslog de contenir à la fois les libellés structure-data et explicit-priority. Dans les versions 19.4R2-S3 et ultérieures, ces étiquettes ne sont plus autorisées.

Par exemple, la configuration syslog ci-après contient les deux libellés (set system syslog file messages structured-data et 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

La sortie de cette configuration est la suivante :

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

Pour résoudre ce problème, supprimez l'un des libellés syslog de la configuration et relancez la vérification de l'état de préparation.

Correction des commandes de configuration vSRX non prises en charge

Le vSRX Juniper contient des commandes CLI non documentées ou masquées. La configuration d' vSRX ne prend pas en charge certaines de ces commandes, même si, dans certaines versions, elles peuvent être validées. Parfois, le comportement peut changer de manière inattendue d'une version à l'autre. Les informations suivantes détaillent certaines commandes de configuration connues comme n'étant pas prises en charge lors de la mise à niveau à partir d'une ancienne version d' vSRX. Il est essentiel de supprimer les commandes non prises en charge ou masquées de la configuration d’ vSRX e avant de mettre à niveau votre version. Appliquez cette procédure même pour les commandes qui ne sont pas détectées par le contrôle de préparation.

Correction de l'erreur 1145

Pour supprimer les règles et les configurations liées au fournisseur d'identité. Exécutez les commandes suivantes pour regrouper toutes les dépendances.

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

Supprimez ensuite la section de configuration pour chacune de ces dépendances.

Exemple :

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

Correction de l'erreur 1147

A l'instar de la section précédente, une modification de la manière dont Junos analyse la configuration dans la section de sécurité peut entraîner des erreurs telles que les suivantes:

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

Voici quelques exemples de cette configuration :

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

L'utilisation de * comme caractère de fin et préfixe n'est plus valide. Une autre configuration est la suivante:

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

Pour résoudre ce problème, modifiez la configuration de vSRX selon vos besoins, validez et relancez la vérification de l'état de préparation.

[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

Correction de l'avertissement 1176

Une configuration de réseau privé virtuel avec establish-tunnels non définie sur immediately a été détectée. Après une mise à niveau, l’IKE peut ne pas être immédiatement actif, en fonction des négociations avec la passerelle homologue distante et de l’existence ou non d’un trafic de données actif. Sans establish-tunnels immediately, le tunnel est établi avec on-traffic. Avec l'instruction establish-tunnels immediately, le tunnel est établi dès que la configuration est validée. Toutefois, l'instruction establish-tunnels immediately peut déclencher un résultat non souhaitable si elle configurée aux deux extrémités du tunnel.

Pour plus d'informations, consultez l'article (SRX)IPsec fonctionne correctement lorsque SRX-A est l'initiateur, mais échoue lorsque SRX-A devient le répondeur dans la base de connaissances Juniper. Voir VPN(Sécurité) pour plus de détails sur ces paramètres.

Correction de l'avertissement 1177

Une ou plusieurs règles de stratégie de zone de sécurité présentant cette configuration dynamic-application any ont été détectées. Si le vSRX n'est pas installé avec la licence CSB (Content Security Bundle) et la base de données de signatures d'application, cette configuration peut interrompre le trafic en raison des modifications apportées dans les versions plus récentes du vSRX, telles que la version 19.4R2-S3.

Par exemple, la configuration de stratégie de sécurité suivante contient le libellé 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

Si vous utilisez une configuration similaire, il est recommandé d'installer la licence CSB et la base de données de signatures d'application ou de supprimer la règle dynamic-application any.

Correction de l'avertissement 1179

La version d' vSRX qui s'exécute sur la passerelle n'est pas certifiée sur IBM Cloud et n'est pas prise en charge. Les opérations telles que OS Reload (Réinitialisation du système d’exploitation) et Rebuild Cluster (Reconstruction du cluster) remplacent la version actuelle non prise en charge d’ vSRX par la version indiquée sur la page Gateway Details (Détails de la passerelle). La version vSRX n’étant pas certifiée sur IBM Cloud, il est recommandé de contacter le support IBM afin de migrer vers la version certifiée disponible ici : IBM Cloud Juniper vSRX supported versions.

Correction de l'avertissement 1180

La licence vSRX présente sur la passerelle n’a pas été acquise via IBM Cloud et n’est pas prise en charge. Les opérations telles que OS Reload et Rebuild Cluster remplacent la licence actuelle par la version indiquée sur la page Gateway Details. Les licences vSRX prises en charge sont disponibles ici : Affichage et changement de licences vSRX. Si la licence a été acquise en dehors d’ IBM Cloud, adressez-vous à ce fournisseur pour obtenir de l’aide. Sinon, contactez le support IBM pour migrer vers une licence vSRX prise en charge.

Correction de l'avertissement 1181

La licence et la version vSRX sur la passerelle ne sont pas prises en charge. Pour obtenir de l'aide sur la résolution de ces avertissements, voir Correction de l'avertissement 1179 et Correction de l'avertissement 1180.