

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

# Resolución de problemas
<a name="discovery-tool-troubleshooting"></a>

## Verificación de la conectividad de la herramienta de detección con vCenter
<a name="discovery-tool-vcenter-connectivity"></a>

Cuando se produzcan errores de configuración de los módulos de VMware, siga estos pasos para verificar la conectividad:

**Acceda a la herramienta de descubrimiento VM**
+ Log-in a la máquina virtual de la herramienta de detección, abra Remote Console en vCenter
  + Nombre de usuario: discovery
  + Contraseña: contraseña

**Pruebe la conectividad de vCenter**

1. Pruebe el acceso a la API de vCenter:

   ```
   curl -v --insecure -u <username>:<password> https://<vcenter-ip-or-hostname>:443/mob
   ```

1. Resultado de éxito esperado:

   ```
   [ec2-user@discoverytool ~]$ curl -v --insecure -u <user>:<password> https://vcsa/mob > tmp.txt
     % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                    Dload  Upload   Total   Spent    Left  Speed
     0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 192.168.2.125:443...
   * Connected to vcsa (192.168.2.125) port 443 (#0)
   ...
   </xml>
   * Connection #0 to host vcsa left intact
   ```

**Pruebe el certificado SSL**

1. Ejecute este comando: 

   ```
   openssl s_client -showcerts -servername <hostname> -connect <hostname>:443
   ```

1. Resultado de éxito esperado:
   + Debe mostrar los detalles del certificado de vSphere
   + Verifica la SSL/TLS conectividad en el puerto 443

   ```
   [ec2-user@discoverytool ~]$ openssl s_client -showcerts -servername vcsa -connect vcsa:443
   CONNECTED(00000003)
   depth=0 CN = vcsa.onpremsim.env, C = US
   verify error:num=20:unable to get local issuer certificate
   verify return:1
   depth=0 CN = vcsa.onpremsim.env, C = US
   verify error:num=21:unable to verify the first certificate
   verify return:1
   ---
   Certificate chain
    0 s:/CN=vcsa.onpremsim.env/C=US
      i:/CN=CA/DC=vsphere/DC=local/C=US/ST=California/O=vcsa.onpremsim.env/OU=VMware Engineering
   -----BEGIN CERTIFICATE-----
   ...
   -----END CERTIFICATE-----
   ---
   Server certificate
   subject=/CN=vcsa.onpremsim.env/C=US
   issuer=/CN=CA/DC=vsphere/DC=local/C=US/ST=California/O=vcsa.onpremsim.env/OU=VMware Engineering
   ---
   ```

## Solución de problemas de WinRM
<a name="discovery-tool-winrm-troubleshooting"></a>

Si tienes problemas de conectividad con WinRM, sigue estos pasos para probar la conexión. Estos pasos también se aplican a los problemas de Hyper-V conectividad, ya que la herramienta de detección utiliza WinRM para comunicarse con Hyper-V los hosts.

Pruebe la conectividad WinRM básica mediante los puertos 5985 (HTTP) y 5986 (HTTPS). Debemos asegurarnos de que la conectividad funcione en el puerto 5986 (HTTPS)

```
# Check WinRM listener configuration
winrm enumerate winrm/config/listener

# Note: Replace <HOST> with the target computer's hostname or IP address. Adjust the username and password as needed. 
# Test WinRM connection on port 5985 (HTTP)
$cred = Get-Credential
Test-WSMan -Computer <HOST> -Authentication Negotiate -Credential $cred -Port 5985

# Test WinRM connection on port 5986 (HTTPS)
Test-WSMan -Computer <HOST> -Authentication Negotiate -Credential $cred -Port 5986
```

Si las pruebas anteriores fallan, intente establecer una PowerShell sesión con la validación de certificados deshabilitada:

```
$cred = Get-Credential
$so = New-PsSessionOption -SkipCACheck -SkipCNCheck -SkipRevocationCheck
Enter-PSSession -ComputerName <HOST> -Credential $cred -Port 5985 -SessionOption $so
```

## Solución de problemas de Kerberos
<a name="discovery-tool-kerberos-troubleshooting"></a>

Si se producen errores en la autenticación de Kerberos al recopilar datos de los servidores Windows, utilice las siguientes secciones para diagnosticar y resolver los problemas más comunes.

### Compruebe los requisitos de la red
<a name="kerberos-verify-network"></a>

Antes de solucionar los problemas de autenticación Kerberos, compruebe que la herramienta de detección pueda llegar a los puntos finales de red necesarios.

**Para comprobar los requisitos de red para Kerberos**

1. Compruebe la resolución de DNS en el controlador de dominio. Ejecute el siguiente comando desde la máquina virtual de la herramienta de detección:

   ```
   nslookup dc01.example.com
   ```

   Como alternativa también puede utilizar `dig`.

   ```
   dig dc01.example.com
   ```

   Si se produce un error en la resolución de DNS, compruebe que la máquina virtual de la herramienta de detección esté configurada para usar un servidor DNS que pueda resolver su dominio de Active Directory. Compruebe `/etc/resolv.conf` y confirme que las entradas del servidor de nombres apuntan a los servidores DNS de su dominio.

1. Compruebe la conectividad con el centro de distribución de claves (KDC) en el puerto 88. Use el siguiente comando:

   ```
   nc -zv dc01.example.com 88
   ```

   Resultado previsto:

   ```
   Connection to dc01.example.com 88 port [tcp/kerberos] succeeded!
   ```

   Si se produce un error en la conexión, compruebe que ninguna regla de firewall bloquee el tráfico desde la máquina virtual de la herramienta de detección al controlador de dominio en el puerto 88.

1. Compruebe la conectividad con los servidores Windows de destino en los puertos WinRM. Ejecute los siguientes comandos :

   ```
   nc -zv <windows-server> 5985
   nc -zv <windows-server> 5986
   ```

   Si se produce un error en la conexión, compruebe que WinRM esté activado en el servidor de destino y que las reglas del firewall permitan el tráfico entrante en los puertos 5985 y 5986.

### Problemas comunes de Kerberos
<a name="kerberos-common-issues"></a>

A continuación, se muestran los problemas comunes de Kerberos y sus soluciones.

**Errores de distinción de mayúsculas y**

Síntoma: recibe el error «No se encuentra el servidor en la base de datos de Kerberos» durante la autenticación.

Este error suele producirse cuando el nombre del territorio de Kerberos no está en mayúsculas. Los dominios de Kerberos deben especificarse en mayúsculas en el archivo. `krb5.conf` Por ejemplo, utilice `EXAMPLE.COM` en lugar de `example.com`.

**Prevención del bloqueo de cuentas**

La herramienta de detección utiliza un mecanismo de espera para evitar el bloqueo de cuentas debido a intentos de autenticación fallidos repetidos. Si su cuenta de servicio queda bloqueada, puede restablecer el proceso de recopilación deteniendo e iniciando el módulo de recopilación a través de la interfaz de usuario web de la herramienta de detección en. `https://<discovery-tool-vm-ip>:5000`

**kinit falla desde CLI**

En la siguiente tabla se enumeran `kinit` los errores más comunes y sus soluciones.


| Error | Causa | Solución | 
| --- | --- | --- | 
| No se encuentra el KDC para el dominio | No se puede acceder al nombre de host o la dirección IP del KDC, o el dominio no está configurado en. krb5.conf | Compruebe que el krb5.conf archivo contiene el nombre de host y el dominio correctos del KDC. Confirme la resolución del DNS y la conectividad de red con el KDC en el puerto 88. | 
| Falló la autenticación previa | La contraseña de la cuenta de servicio es incorrecta. | Compruebe la contraseña e inténtelo de nuevo. Si la cuenta está bloqueada, desbloquéela en Active Directory antes de volver a intentarlo. | 
| No se encontró el cliente en la base de datos de Kerberos | El nombre principal no coincide con ninguna cuenta de Active Directory. | Compruebe que el nombre principal coincide exactamente con el nombre de la cuenta, incluidas las mayúsculas y minúsculas. Utilice el formato username@REALM con el dominio en mayúsculas. | 
| No se puede resolver la dirección de red del KDC | El DNS no puede resolver el nombre de host del KDC. | Compruebe la configuración de DNS en. /etc/resolv.conf Confirme que el servidor DNS puede resolver el nombre de host del KDC. Pruebe con nslookup o. dig | 

**La recolección falla a pesar del éxito del kinit**

Si se `kinit` realiza correctamente, pero la recopilación de datos sigue fallando, compruebe lo siguiente:

1. Compruebe que el nombre principal utilizado para la recopilación coincida `kinit` exactamente con el caso utilizado durante la recopilación.

1. Compruebe que la cuenta de servicio tenga los permisos necesarios en los servidores de destino.

1. Compruebe que WinRM esté activado en los servidores de destino.

1. Compruebe que el nombre de host utilizado para la recopilación coincida con el nombre de host registrado en Active Directory.

**Kerberos funciona en algunos servidores, pero no en otros**

Si la autenticación Kerberos se realiza correctamente en algunos servidores pero no en otros, investigue las siguientes áreas:

Si sus servidores abarcan varios dominios de Active Directory, configure una credencial Kerberos independiente para cada dominio. Asegúrese de que el `/etc/krb5.conf` archivo incluya entradas para todos los dominios. Cada dominio requiere su propia credencial con el director correcto`username@REALM`.

Compare la configuración de WinRM en un servidor en funcionamiento con la de un servidor defectuoso. Ejecute el siguiente comando en cada servidor:

```
winrm get winrm/config
```

Pruebe la conectividad con Remote Desktop para aislar el problema. La herramienta de detección usa el formato`username@DOMAIN`, mientras que Remote Desktop usa el formato`DOMAIN\username`.

Compruebe que la cuenta de servicio es miembro del grupo de administradores local del servidor que falla. Ejecute el siguiente comando en el servidor de destino:

```
net localgroup Administrators
```

WMI requiere privilegios de administrador local para acceder a la información del sistema operativo. La recopilación de SQL Server también requiere que la cuenta de servicio tenga acceso de administrador local en el servidor de destino.

### Lista de verificación de configuración de Kerberos
<a name="kerberos-checklist"></a>

Utilice la siguiente lista de comprobación para comprobar la configuración de Kerberos antes de iniciar la recopilación de datos.
+ El `krb5.conf` archivo existe en la máquina virtual de la herramienta de detección.
+ El nombre del dominio está escrito en mayúscula. `krb5.conf`
+ La ejecución `kinit` con la cuenta de servicio se realiza correctamente sin errores.
+ Si se ejecuta, se `klist` muestra un billete válido y no caducado.
+ El nombre principal coincide exactamente con el nombre de la cuenta de Active Directory.
+ La resolución de DNS funciona para el nombre de host del KDC.
+ Se ha confirmado la conectividad de red con el KDC en el puerto 88.
+ Se ha confirmado la conectividad de red con los servidores Windows de destino en los puertos 5985 y 5986.
+ (Multi-domain) Cada dominio de Active Directory tiene su propia credencial configurada en la herramienta de detección `[realms]` y `krb5.conf` contiene `[domain_realm]` entradas para todos los dominios.

## Solución de problemas de bases de datos
<a name="discovery-tool-oracle-troubleshooting"></a>

Para diagnosticar problemas de recopilación de bases de datos Oracle, como datos faltantes o errores, compruebe lo siguiente.

**Conexión rechazada o se ha agotado el tiempo de espera**

Síntoma: el estado de recopilación de Oracle muestra un error de conexión para un servidor.

Para solucionar este problema, compruebe lo siguiente:
+ Compruebe que el agente de escucha de Oracle se esté ejecutando en el host de destino: `lsnrctl status`
+ Compruebe la conectividad de red desde la herramienta de detección al host de Oracle en el puerto 1521 (o en su puerto personalizado): `nc -zv <oracle-host> 1521`
+ Compruebe que las reglas del firewall permiten las conexiones entrantes en el puerto de escucha de Oracle.
+ Compruebe el nombre del servicio ejecutándolo `lsnrctl services` en el host de Oracle. Si el nombre del servicio es incorrecto, el agente de escucha de Oracle rechaza la conexión.

**Fallos de autenticación () ORA-01017**

Síntoma: la recopilación falla debido a un error de nombre de usuario o contraseña no válidos.

Para solucionar este problema, compruebe lo siguiente:
+ Compruebe que la cuenta de servicio de Oracle existe y no está bloqueada: `SELECT account_status FROM dba_users WHERE username = 'DISCOVERY_USER';`
+ Compruebe que la contraseña es correcta conectándose manualmente: `sqlplus discovery_user/<password>@<host>:1521/<service_name>`
+ Si la cuenta está bloqueada, desbloquéela: `ALTER USER discovery_user ACCOUNT UNLOCK;`

**Privilegios insuficientes (ORA-01031)**

Síntoma: la conexión se realiza correctamente, pero la recopilación devuelve datos incompletos.

Para solucionar este problema, compruebe lo siguiente:
+ Compruebe que se concede SELECT\_CATALOG\_ROLE: `SELECT * FROM dba_role_privs WHERE grantee = 'DISCOVERY_USER';`
+ Otorgue la función requerida si falta: `GRANT SELECT_CATALOG_ROLE TO discovery_user;`

**La credencial manual muestra un error, pero la conexión automática funciona**

Al fijar una credencial manualmente a un servidor, la herramienta de detección no recurre a ella si se produce un error en la conexión. Compruebe que el nombre del puerto y del servicio que configuró en la credencial coincidan con el agente de escucha de Oracle de ese servidor específico. Si el servidor tiene un nombre de puerto o servicio no estándar, actualice la configuración de credenciales en consecuencia.

**OS-level alternativa: no detecta Oracle**

Si no se ha configurado ninguna credencial de base de datos y la OS-level alternativa no detecta Oracle:
+ Compruebe que las credenciales de los sistemas operativos SSH o WinRM estén configuradas y funcionen para el servidor (compruebe el estado de la recopilación de métricas del sistema operativo).
+ En el caso de los hosts Linux, compruebe que los procesos del monitor de procesos de Oracle (`pmon`) `/etc/oratab` existan o que estén en ejecución.
+ En el caso de los hosts de Windows, compruebe que las entradas de registro de Oracle estén en ejecución `HKLM\SOFTWARE\Oracle` o que `oracle.exe` los procesos se estén ejecutando.

## Solución de problemas de SNMP
<a name="discovery-tool-snmp-troubleshooting"></a>

**Acceda a la herramienta de descubrimiento VM**
+ Log-in a la máquina virtual de la herramienta de detección, abra Remote Console en vCenter
  + Nombre de usuario: discovery
  + Contraseña: contraseña

**Instale las herramientas SNMP (si es necesario)**
+ `sudo yum install net-snmp-utils -y`

**Pruebe la conexión SNMP a los servidores Linux**

1. `snmptable -v 2c -c <COMMUNITY_STRING> <REMOTE_SERVER_IP> .1.3.6.1.2.1.6.13.1`

1. Ejemplo:

   ```
   #SNMPv2c:
   snmptable -v 2c -c public 192.168.1.100 .1.3.6.1.2.1.6.13.1
   
   #SNMPv3 (with authentication):
   snmptable -v 3 -u <username> -a MD5 -A <auth_password> 192.168.1.100 .1.3.6.1.2.1.6.13.1
   
   #SNMPv3 (with privacy):
   snmptable -v 3 -u <username> -a MD5 -A <auth_password> -x DES -X <priv_password> 192.168.1.100 .1.3.6.1.2.1.6.13.1
   ```

## Errores de recopilación de redes
<a name="discovery-tool-network-collection-errors"></a>

### se necesita un terminal para leer la contraseña
<a name="discovery-tool-terminal-required"></a>

**Error:**

```
ss command failed on <host>: sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper sudo: a password is required
```

El comando ss solicita la contraseña del usuario. El usuario ssh configurado debe estar en el grupo sudoers y estar configurado con sudo sin contraseña para el comando. ss/netstat Para configurar el sudo sin contraseña:

1. Crea un nuevo archivo sudoers:

   ```
   sudo vi -f /etc/sudoers.d/<username>
   ```

1. Añada la línea:

   ```
   <username> ALL=(ALL) NOPASSWD: /usr/sbin/ss, /usr/bin/netstat
   ```

1. Después de este cambio, se ejecuta `sudo ss -tnap` y `sudo netstat -tnap` debería ejecutarse sin solicitar una contraseña

### La recopilación de redes se ejecutó sin sudo
<a name="discovery-tool-non-sudo-warning"></a>

Si ves la siguiente advertencia en la página de **inventario descubierto**:

```
Network collection ran without sudo. Process-level connection data may be missing.
```

Esta advertencia indica que la cuenta de usuario de SSH no tiene acceso de sudo al servidor de destino. Sin sudo, la herramienta de detección aún puede recopilar datos de conexión de red, pero no puede determinar qué proceso es el propietario de cada conexión. Para recopilar datos de conexión completos a nivel de proceso, asegúrese de que el usuario de SSH tenga acceso sudo al servidor de destino.

## Errores de recopilación de métricas del sistema operativo
<a name="discovery-tool-os-metrics-collection-errors"></a>

### Falta el UUID del servidor para los servidores Linux
<a name="discovery-tool-missing-uuid"></a>

Si la herramienta de detección no puede recopilar el UUID del servidor (aparece vacío o falta) para los servidores Linux, compruebe que las credenciales SSH configuradas para esos servidores tengan privilegios de sudo. La herramienta se utiliza `dmidecode` para leer el UUID del servidor. Si no `dmidecode` está instalada, la herramienta vuelve a la lectura`/sys/class/dmi/id/product_uuid`, que también requiere acceso sudo. Sin sudo, ninguno de los métodos puede recuperar el UUID.

**Solución:** asegúrese de que la cuenta de usuario SSH proporcionada a la herramienta de detección tenga acceso sudo en los servidores Linux de destino.

## Problemas de acceso en el inventario descubierto
<a name="discovery-tool-access-issues"></a>

Si aparece un mensaje en el **estado de recopilación del servidor**, como Credenciales faltantes o Acceso denegado:

1. Seleccione el servidor en la tabla de servidores detectados.

1. Elija **Administrar credenciales de acceso**. Puede elegir entre:

   1. Seleccione credenciales alternativas en el menú desplegable **Seleccionar credenciales**. 

   1. Seleccione **Usar credenciales nuevas** y proporcionar credenciales nuevas.

1. **Save (Guardar)**.

La herramienta de detección vuelve a intentar la conexión después de guardar los cambios.

## Solución de problemas de autenticación con clave SSH
<a name="discovery-tool-ssh-key-troubleshooting"></a>

**Probar la conectividad de la clave SSH desde la herramienta de descubrimiento**

Si se produce un error en la autenticación de la clave SSH, compruebe la conectividad de la herramienta de detección con el servidor de destino:

1. Inicie sesión en la herramienta de detección (mediante la consola vSphere o mediante SSH en el host Linux).

1. Pruebe la conectividad SSH con su clave privada:

   ```
   ssh -i /path/to/private_key -o StrictHostKeyChecking=no <username>@<target_ip>
   ```

1. Si la conexión se realiza correctamente, el problema está relacionado con la forma en que se cargó la clave en la herramienta de detección. Re-upload la clave y verifica que el nombre de usuario coincida.

1. Si se produce un error en la conexión, compruebe el mensaje de error de la siguiente tabla.


| Mensaje de error | Causa | Resolución | 
| --- | --- | --- | 
| Permission denied (publickey) | La clave pública no está en el authorized\_keys archivo del servidor de destino o el nombre de usuario es incorrecto. | Agregue la clave pública \~/.ssh/authorized\_keys al servidor de destino para el usuario correcto. Compruebe los permisos de los archivos:chmod 700 \~/.ssh && chmod 600 \~/.ssh/authorized\_keys. | 
| Connection timed out after 20s | No se puede acceder al puerto 22 desde la herramienta de detección. | Compruebe que el puerto 22 esté abierto entre la herramienta de detección y el servidor de destino. Compruebe los firewalls y los grupos de seguridad. | 
| Connection refused | El servicio SSH no se está ejecutando en el servidor de destino. | Inicie el servicio SSH:. sudo systemctl start sshd | 
| Invalid SSH key for credential '{{name}}' | El formato de clave no es compatible, los datos de la clave están dañados, o falta la contraseña o es incorrecta. | Compruebe que el formato de la clave es RSA, ECDSA o Ed25519 en formato PEM, OpenSSH o PKCS \#8. Si la clave está cifrada, asegúrese de que la contraseña sea correcta. | 

## Solución de problemas con el instalador
<a name="discovery-tool-linux-installer-troubleshooting"></a>

**El puerto 5000 ya está en uso**

**Síntoma:** el servicio de la herramienta de detección no se inicia después de la instalación.

**Solución:** identifique y detenga el proceso mediante el puerto 5000:

```
sudo ss -tlnp | grep :5000
```

Detenga el proceso conflictivo y, a continuación, reinicie la herramienta de detección:

```
sudo ./AWS-Transform-discovery-tool.sh start
```

## Mensajes de error comunes
<a name="discovery-tool-ui-messages"></a>

En esta tabla se describen los mensajes de error más comunes y sus explicaciones:


| Mensaje | Ubicación | Explicación | 
| --- | --- | --- | 
| Ya se ha creado una contraseña | Crear página de contraseñas | Condición de carrera cuando dos usuarios crean contraseñas al mismo tiempo; actualice | 
| Falló la exportación | Página de inventario | Vuelva a intentarlo o envíe los registros | 
| Ya hay una recopilación bajo demanda en curso | Página de inventario | Condición de carrera cuando dos usuarios inician la recolección manual al mismo tiempo; inténtelo de nuevo una vez finalizada la recopilación manual actual | 
| Command timed out after 60s | Estado de la recopilación del servidor | Un comando del servidor de destino no se completó en 60 segundos. Esto puede ocurrir en servidores muy cargados. Vuelva a intentar la recopilación o investigue la carga del servidor de destino. | 
| Una o más credenciales contienen UUID desconocidos | Página de acceso al sistema operativo | Condición de carrera cuando dos usuarios editan las credenciales del sistema operativo al mismo tiempo; inténtelo de nuevo | 
| Contraseña no válida | Sign-in página | Contraseña incorrecta para iniciar sesión; ponte en contacto con el administrador o comunícate con | 
| Tu sesión ha caducado. Vuelva a iniciar sesión. | Sign-in página | Se agotó el tiempo de espera de la sesión, es necesario volver a iniciar sesión | 
| Se ha producido un error interno | Varias páginas | Vuelva a intentarlo o envíe los registros | 