Corrección de errores de conectividad

Es posible que se encuentre con las dos categorías siguientes de errores de conectividad al realizar comprobaciones de disponibilidad:

• Errores de conectividad SSH de host (Ubuntu)
• Errores de conectividad SSH de pasarela (vSRX)

Muchos de estos errores ocurren porque las comprobaciones requieren acceso root SSH a la dirección IP privada para el SO anfitrión ( Ubuntu ), o la pasarela vSRX. Si falla una comprobación de conectividad SSH, la acción no puede continuar.

Para obtener más información sobre cómo establecer una sesión SSH, consulte Acceso al dispositivo mediante SSH. Tenga en cuenta que para el paso 3, el ejemplo que se da es con el usuario admin. Para una comprobación de preparación, sustituya el usuario root por el vSRX y el Hardware (host). Además, debe usar la IP privada con este procedimiento, no la pública.

Para validar la conectividad, abra una sesión SSH en la IP privada del host Ubuntu o vSRX's utilizando las credenciales raíz que aparecen en la sección Hardware (para un host Ubuntu ) o en la sección vSRX (para la puerta de enlace) de la página Gateway Appliance Detalles. Asegúrese de que se puede establecer la sesión SSH.

Si no se puede establecer la sesión, compruebe los posibles problemas siguientes.

Para errores de conectividad SSH de host (Ubuntu):

• ¿El cortafuegos de Ubuntu bloquea el acceso SSH a la IP privada? Las reglas de cortafuegos deben permitir el acceso SSH a la subred privada 10.0.0.0/8. Para obtener más información, consulte Rangos de IP de IBM Cloud para la red de servicio.
• La contraseña de root que se indica en la página Detalles de dispositivo pasarela, ¿es la contraseña correcta para el usuario root? Si no lo es, pulse el enlace del dispositivo situado en la sección Hardware y vaya a Contraseñas. Seleccione Acciones > Editar credenciales y cambie la contraseña para que coincida con la contraseña de root real en el host de Ubuntu.
• ¿Está inhabilitado el inicio de sesión root para el servidor SSH?
• ¿Está inhabilitado o detenido el servidor SSH?
• ¿Está inhabilitada la cuenta de usuario root en el host de Ubuntu?

Para errores de conectividad SSH de pasarela (vSRX):

• ¿El cortafuegos de vSRX bloquea el acceso SSH a la IP privada? Las reglas de cortafuegos deben permitir el acceso SSH a la subred privada 10.0.0.0/8. Para obtener más información, consulte Rangos de IP de IBM Cloud para la red de servicio.
• La contraseña de root que se indica en la página Detalles de dispositivo pasarela, ¿es la contraseña correcta para el usuario root? Si no es así, pulse el icono Editar situado junto a la contraseña de root y cambie la contraseña para que coincida con la contraseña de root real para vSRX.
• ¿Está inhabilitada la cuenta de usuario root para el acceso SSH a vSRX?

Corrección del error 1119

El vSRX podría tener una configuración que bloquea el acceso a la consola local a través de telnet. Compruebe si existe la siguiente configuración y elimínela antes de volver a intentar la operación de comprobación previa:

set system ports console disable set system ports console insecure

Otros problemas pueden ser una contraseña incorrecta en vSRX.

A veces, el error de comprobación de disponibilidad 1119 puede producirse incluso cuando la configuración de vSRX parece ser válida y no se han configurado los ajustes de consola esperados (establecer puertos de sistema de consola desactivados o inseguros). Este problema puede surgir debido a un archivo /etc/hosts incompleto o mal configurado en el host Ubuntu, que puede impedir la resolución correcta de localhost durante la prueba telnet. Asegúrese de que localhost se asigna explícitamente a la dirección IP 127.0.0.1. Una asignación inexistente o incorrecta puede impedir que el script de preparación se conecte al puerto de consola vSRX.

Los siguientes comandos ilustran cómo configurar correctamente el archivo etc/hosts y asignarlo a su localhost.

Antes de mapear el localhost, el archivo /etc/hosts se ve como se muestra en el siguiente comando, donde la dirección IP 127.0.0.1 se mapea sólo al nombre del sistema host.

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

Después de mapear correctamente el localhost, el archivo /etc/hosts se ve como se muestra en el siguiente comando y el localhost está mapeado correctamente a la dirección IP 127.0.0.1.

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

Cuando actualice el archivo /etc/hosts en el sistema anfitrión con estos cambios y ejecute el comando telnet localhost (port-number), la conexión telnet a su host local tendrá éxito y se resolverá el error de comprobación previa.

Para identificar el número de puerto para la conexión telnet, ejecute el comando virsh dumpxml (VM-Instance-Name) | grep service en el sistema host y utilice el valor que se muestra para el servicio. Para identificar la VM-Instance-Name, utilice el comando virsh list.

Corrección del error 1124

vSRX 18.4R1-S1 ha introducido una incompatibilidad que se documenta en este informe de problemas de Juniper. Necesita una cuenta de Juniper para acceder a este informe.

Si una interfaz de Ethernet (reth) redundante incluye vlan-tagging (que es el valor predeterminado), la interfaz también debe incluir la etiqueta vlan-id. En 18.4R1-S1, se ha podido confirmar una configuración sin la etiqueta vlan-id. Las versiones más recientes, como por ejemplo 19.4R2-S3, no permiten esta configuración.

Una configuración de ejemplo sin 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 salida de esta configuración es:

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

Para solucionar este error, añada la etiqueta vlan-ida la configuración y vuelva a intentar la comprobación de preparación:

set interfaces reth2 unit 2058 vlan-id 2058

Corrección del error 1125

vSRX 18.4R1-S1 ha introducido una incompatibilidad que ha permitido que la configuración de syslog contenga las etiquetas structure-data y explicit-priority. En las versiones 19.4R2-S3 y posteriores, estas etiquetas ya no están permitidas.

Por ejemplo, la siguiente configuración de syslog contiene ambas etiquetas (set system syslog file messages structured-data y 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 salida de esta configuración es:

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

Para solucionar este problema, elimine una de las etiquetas de syslog de la configuración y vuelva a intentar la comprobación de preparación.

Corrección de comandos de configuración vSRX no soportados

Juniper vSRX contiene mandatos de CLI no documentados u ocultos. La configuración de vSRX no admite algunos de estos comandos, aunque en algunas versiones se pueden confirmar. A veces, el comportamiento puede cambiar inesperadamente entre versiones de release. La siguiente información detalla algunos comandos configuración no compatibles conocidos cuando se actualiza desde una versión anterior de vSRX. Es fundamental que elimine los comandos no compatibles u ocultos de la configuración de vSRX antes de actualizar su versión. Realice este proceso incluso con comandos que no hayan sido detectados por la comprobación de preparación.

Corrección del error 1145

Para eliminar las políticas y configuraciones relacionadas con IDP. Ejecute los mandatos siguientes para recopilar todas las dependencias.

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

A continuación, suprima la stanza de configuración para cada una de estas dependencias.

Ejemplo:

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

Corrección del error 1147

Al igual que en la sección anterior, un cambio en la forma en que Junos analiza la configuración en la sección de seguridad puede provocar errores como:

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

Algunos ejemplos de esta configuración son:

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

El uso de * como carácter final y el prefijo ya no son válidos. Una configuración alternativa es:

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

Para solucionar este problema, modifique la configuración de vSRX según sea necesario, confirme y vuelva a intentar la comprobación de preparación.

[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

Corrección de la advertencia 1176

Se ha detectado una configuración de VPN con establish-tunnels no establecida en immediately. Después de una actualización, el IKE puede no estar activo inmediatamente dependiendo de las negociaciones con la pasarela peer remota, y de si el tráfico de datos está fluyendo activamente. Sin establish-tunnels immediately, el túnel se establece con on-traffic. Con la sentencia establish-tunnels immediately, el túnel se establece inmediatamente cuando se confirma la configuración. Sin embargo, establish-tunnels immediately puede desencadenar un resultado no deseado cuando se configura en ambos extremos del túnel.

Para obtener más información, consulte (SRX)IPsec se activa cuando SRX-A es el iniciador, pero falla cuando SRX-A se convierte en el respondedor en la Base de conocimientos de Juniper. Consulte VPN(Seguridad) para obtener más información sobre estos ajustes.

Corrección de la advertencia 1177

Se han detectado una o más reglas de política de zona de seguridad con la configuración dynamic-application any. Si el vSRX no está instalado con la licencia de Content Security Bundle (CSB) y la base de datos de la firma de la aplicación, esta configuración podría provocar una interrupción del tráfico debido a cambios en releases más recientes de vSRX, como por ejemplo 19.4R2-S3.

Por ejemplo, la siguiente configuración de política de seguridad contiene la etiqueta 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 está utilizando una configuración similar, se recomienda que instale la licencia de CSB y la base de datos de la firma de la aplicación o elimine la regla dynamic-application any.

Corrección del aviso 1179

La versión vSRX que se ejecuta en el Gateway no está certificada en IBM Cloud y no es compatible. Operaciones como OS Reload y Rebuild Cluster sobrescriben la versión actual no soportada vSRX con la versión que aparece en la página Gateway Details. Dado que la versión vSRX no está certificada en IBM Cloud, se recomienda ponerse en contacto con el servicio de asistencia IBM para migrar a la versión certificada que se encuentra aquí: IBM Cloud Juniper vSRX versiones compatibles.

Corrección del aviso 1180

La licencia vSRX que se encuentra en el Gateway no se adquirió a través de IBM Cloud y carece de soporte. Operaciones como OS Reload y Rebuild Cluster sobrescriben la licencia actual con la versión que aparece en la página Gateway Details. Las licencias de vSRX soportadas se pueden encontrar aquí: Visualización y cambio de licencias de vSRX. Si la licencia se adquirió fuera de IBM Cloud, trabaje con esa fuente de adquisición para obtener asistencia. En caso contrario, póngase en contacto con el servicio de asistencia de IBM para migrar a una licencia compatible de vSRX.

Corrección del aviso 1181

La licencia y la versión de vSRX en la pasarela no están soportadas. Consulte Corrección del aviso 1179 y Corrección del aviso 1180 para obtener ayuda para resolver estos avisos.