Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Risoluzione dei problemi ## Verifica della connettività degli strumenti di rilevamento a vCenter Se riscontri errori di configurazione dei moduli VMware, segui questi passaggi per verificare la connettività: **Accedi allo strumento di rilevamento VM** + Log-in allo strumento di rilevamento VM, aprire Remote Console in vCenter + Nome utente: discovery + Password: password **Test della connettività vCenter** 1. Test dell'accesso all'API vCenter: ``` curl -v --insecure -u : https://:443/mob ``` 1. Risultato di successo previsto: ``` [ec2-user@discoverytool ~]$ curl -v --insecure -u : 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) ... * Connection #0 to host vcsa left intact ``` **Certificato SSL di prova** 1. Eseguire il comando: ``` openssl s_client -showcerts -servername -connect :443 ``` 1. Risultato di successo previsto: + Dovrebbe mostrare i dettagli del certificato vSphere + Verifica la SSL/TLS connettività sulla porta 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 --- ``` ## Risoluzione dei problemi WinRM Se riscontri problemi di connettività con WinRM, segui questi passaggi per testare la connessione. Questi passaggi si applicano anche ai problemi di Hyper-V connettività, poiché lo strumento di rilevamento utilizza WinRM per comunicare con gli host. Hyper-V Verifica la connettività WinRM di base utilizzando le porte 5985 (HTTP) e 5986 (HTTPS). Dobbiamo assicurarci che la connettività funzioni sulla porta 5986 (HTTPS) ``` # Check WinRM listener configuration winrm enumerate winrm/config/listener # Note: Replace 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 -Authentication Negotiate -Credential $cred -Port 5985 # Test WinRM connection on port 5986 (HTTPS) Test-WSMan -Computer -Authentication Negotiate -Credential $cred -Port 5986 ``` Se i test precedenti falliscono, prova a stabilire una PowerShell sessione con la convalida dei certificati disabilitata: ``` $cred = Get-Credential $so = New-PsSessionOption -SkipCACheck -SkipCNCheck -SkipRevocationCheck Enter-PSSession -ComputerName -Credential $cred -Port 5985 -SessionOption $so ``` ## Risoluzione dei problemi Kerberos Se riscontri errori di autenticazione Kerberos durante la raccolta di dati dai server Windows, utilizza le seguenti sezioni per diagnosticare e risolvere i problemi più comuni. ### Verifica i requisiti di rete Prima di risolvere i problemi di autenticazione Kerberos, verifica che lo strumento di rilevamento possa raggiungere gli endpoint di rete richiesti. **Per verificare i requisiti di rete per Kerberos** 1. Verifica la risoluzione DNS sul controller di dominio. Esegui il comando seguente dalla macchina virtuale dello strumento di rilevamento: ``` nslookup dc01.example.com ``` In alternativa, è possibile utilizzare `dig`: ``` dig dc01.example.com ``` Se la risoluzione DNS fallisce, verifica che lo strumento di rilevamento VM sia configurato per utilizzare un server DNS in grado di risolvere il dominio Active Directory. Verifica `/etc/resolv.conf` e conferma che le voci del nameserver puntino ai server DNS del tuo dominio. 1. Verifica la connettività al Key Distribution Center (KDC) sulla porta 88. Esegui il comando seguente: ``` nc -zv dc01.example.com 88 ``` Output previsto: ``` Connection to dc01.example.com 88 port [tcp/kerberos] succeeded! ``` Se la connessione fallisce, verifica che nessuna regola del firewall blocchi il traffico dalla macchina virtuale dello strumento di rilevamento al controller di dominio sulla porta 88. 1. Verifica la connettività ai server Windows di destinazione sulle porte WinRM. Esegui i comandi seguenti: ``` nc -zv 5985 nc -zv 5986 ``` Se la connessione fallisce, verifica che WinRM sia abilitato sul server di destinazione e che le regole del firewall consentano il traffico in entrata sulle porte 5985 e 5986. ### Problemi comuni relativi a Kerberos Di seguito sono riportati i problemi comuni di Kerberos e le relative soluzioni. **Errori di distinzione tra mai** Sintomo: durante l'autenticazione viene visualizzato l'errore «Server non trovato nel database Kerberos». Questo errore si verifica in genere quando il nome dell'area di autenticazione Kerberos non è in maiuscolo. I realm Kerberos devono essere specificati in lettere maiuscole nel file. `krb5.conf` Ad esempio, utilizza `EXAMPLE.COM` anziché `example.com`. **Prevenzione del blocco dell'account** Lo strumento di rilevamento utilizza un meccanismo di backoff per impedire il blocco degli account dovuto a ripetuti tentativi di autenticazione falliti. Se il tuo account di servizio viene bloccato, puoi reimpostare il processo di raccolta interrompendo e quindi avviando il modulo di raccolta tramite l'interfaccia utente web dello strumento di rilevamento all'indirizzo. `https://:5000` **kinit fallisce dalla CLI** La tabella seguente elenca gli `kinit` errori più comuni e le relative soluzioni. | Errore | Causa | Soluzione | | --- | --- | --- | | Impossibile trovare KDC for realm | Il nome host o l'indirizzo IP del KDC non sono raggiungibili oppure il realm non è configurato in. krb5.conf | Verifica che il krb5.conf file contenga il nome host e il realm KDC corretti. Conferma la risoluzione DNS e la connettività di rete al KDC sulla porta 88. | | Preautenticazione non riuscita | La password per l'account di servizio non è corretta. | Verifica la password e riprova. Se l'account è bloccato, sbloccalo in Active Directory prima di riprovare. | | Client non trovato nel database Kerberos | Il nome principale non corrisponde a nessun account in Active Directory. | Verifica che il nome principale corrisponda esattamente al nome dell'account, maiuscole e minuscole. Usa il formato username@REALM con il realm in maiuscolo. | | Impossibile risolvere l'indirizzo di rete per KDC | Il DNS non è in grado di risolvere il nome host KDC. | Verifica la configurazione DNS in. /etc/resolv.conf Verifica che il server DNS sia in grado di risolvere il nome host KDC. Esegui il test con o. nslookup dig | **La raccolta fallisce nonostante il successo di kinit** Se `kinit` riesce ma la raccolta dei dati continua a fallire, controlla quanto segue: 1. Verifica che il nome principale utilizzato per la raccolta corrisponda `kinit` esattamente al maiuscolo/minuscolo utilizzato durante. 1. Verificate che l'account di servizio disponga delle autorizzazioni richieste sui server di destinazione. 1. Verificare che WinRM sia abilitato sui server di destinazione. 1. Verifica che il nome host utilizzato per la raccolta corrisponda al nome host registrato in Active Directory. **Kerberos funziona per alcuni server ma non per altri** Se l'autenticazione Kerberos riesce per alcuni server ma fallisce per altri, esamina le seguenti aree: Se i tuoi server si estendono su più domini Active Directory, configura una credenziale Kerberos separata per ogni dominio. Assicurati che il `/etc/krb5.conf` file includa voci per tutti i reami. Ogni dominio richiede la propria credenziale con il principale corretto`username@REALM`. Confronta la configurazione WinRM su un server funzionante con un server guasto. Esegui il comando seguente su ogni server: ``` winrm get winrm/config ``` Verifica la connettività con Remote Desktop per isolare il problema. Lo strumento di rilevamento utilizza il formato`username@DOMAIN`, mentre Remote Desktop utilizza il formato`DOMAIN\username`. Verificate che l'account di servizio sia membro del gruppo Administrators locale sul server in cui si verifica l'errore. Esegui il comando seguente sul server di destinazione: ``` net localgroup Administrators ``` WMI richiede i privilegi di amministratore locale per accedere alle informazioni del sistema operativo. La raccolta SQL Server richiede inoltre che l'account di servizio disponga dell'accesso di amministratore locale sul server di destinazione. ### Elenco di controllo per la configurazione Kerberos Utilizza la seguente lista di controllo per verificare la configurazione di Kerberos prima di iniziare la raccolta dei dati. + Il `krb5.conf` file esiste nella macchina virtuale dello strumento di rilevamento. + Il nome del realm è in maiuscolo in. `krb5.conf` + L'esecuzione `kinit` con l'account del servizio riesce senza errori. + Running `klist` mostra un ticket valido e non scaduto. + Il nome principale corrisponde esattamente al nome dell'account di Active Directory. + La risoluzione DNS funziona per il nome host KDC. + La connettività di rete al KDC sulla porta 88 è confermata. + La connettività di rete ai server Windows di destinazione sulle porte 5985 e 5986 è confermata. + (Multi-domain) Ogni dominio Active Directory ha le proprie credenziali configurate nello strumento di rilevamento `[realms]` e `krb5.conf` contiene `[domain_realm]` voci per tutti i domini. ## Risoluzione dei problemi del database Orac Per diagnosticare problemi di raccolta del database Oracle, come dati mancanti o errori, controlla quanto segue. **Connessione rifiutata o timeout** Sintomo: lo stato della raccolta Oracle mostra un errore di connessione per un server. Per risolvere questo problema, controlla quanto segue: + Verifica che il listener Oracle sia in esecuzione sull'host di destinazione: `lsnrctl status` + Verifica la connettività di rete dallo strumento di rilevamento all'host Oracle sulla porta 1521 (o sulla porta personalizzata): `nc -zv 1521` + Verifica che le regole del firewall consentano le connessioni in entrata sulla porta del listener Oracle. + Verifica il nome del servizio eseguendolo `lsnrctl services` sull'host Oracle. Se il nome del servizio non è corretto, il listener Oracle rifiuta la connessione. **Errori di autenticazione () ORA-01017** Sintomo: la raccolta non riesce a causa di un errore di nome utente o password non validi. Per risolvere questo problema, controlla quanto segue: + Verifica che l'account del servizio Oracle esista e non sia bloccato: `SELECT account_status FROM dba_users WHERE username = 'DISCOVERY_USER';` + Verifica che la password sia corretta collegandoti manualmente: `sqlplus discovery_user/@:1521/` + Se l'account è bloccato, sbloccalo: `ALTER USER discovery_user ACCOUNT UNLOCK;` **Privilegi insufficienti () ORA-01031** Sintomo: la connessione riesce ma la raccolta restituisce dati incompleti. Per risolvere questo problema, controlla quanto segue: + Verifica che SELECT\_CATALOG\_ROLE sia concesso: `SELECT * FROM dba_role_privs WHERE grantee = 'DISCOVERY_USER';` + Concedi il ruolo richiesto se manca: `GRANT SELECT_CATALOG_ROLE TO discovery_user;` **Le credenziali manuali mostrano errori ma la connessione automatica funziona** Quando si aggiunge manualmente una credenziale a un server, lo strumento di rilevamento non ritorna se la connessione fallisce. Verifica che la porta e il nome del servizio configurati sulla credenziale corrispondano al listener Oracle su quel server specifico. Se il server ha una porta o un nome di servizio non standard, aggiorna di conseguenza la configurazione delle credenziali. **OS-level fallback che non rileva Oracle** Se non sono configurate credenziali del database e il OS-level fallback non rileva Oracle: + Verificate che le credenziali del sistema operativo SSH o WinRM siano configurate e funzionanti per il server (controllate lo stato della raccolta delle metriche del sistema operativo). + Per gli host Linux, verifica che `/etc/oratab` esistano o che i processi Oracle process monitor () `pmon` siano in esecuzione. + Per gli host Windows, verifica che esistano voci del registro Oracle `HKLM\SOFTWARE\Oracle` o che `oracle.exe` i processi siano in esecuzione. ## Risoluzione dei problemi SNMP **Accedi allo strumento di rilevamento VM** + Log-in allo strumento di rilevamento VM, aprire Remote Console in vCenter + Nome utente: discovery + Password: password **Installare gli strumenti SNMP (se necessario)** + `sudo yum install net-snmp-utils -y` **Verifica la connessione SNMP ai server Linux** 1. `snmptable -v 2c -c .1.3.6.1.2.1.6.13.1` 1. Esempio: ``` #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 -a MD5 -A 192.168.1.100 .1.3.6.1.2.1.6.13.1 #SNMPv3 (with privacy): snmptable -v 3 -u -a MD5 -A -x DES -X 192.168.1.100 .1.3.6.1.2.1.6.13.1 ``` ## Errori di raccolta in rete ### è necessario un terminale per leggere la password **Errore:** ``` ss command failed on : 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 ``` Il comando ss richiede la password dell'utente. L'utente ssh configurato deve appartenere al gruppo sudoers ed essere configurato con sudo senza password per il comando. ss/netstat Per configurare sudo senza password: 1. Crea un nuovo file sudoers: ``` sudo vi -f /etc/sudoers.d/ ``` 1. Aggiungi la riga: ``` ALL=(ALL) NOPASSWD: /usr/sbin/ss, /usr/bin/netstat ``` 1. Dopo questa modifica, l'esecuzione `sudo ss -tnap` e `sudo netstat -tnap` dovrebbe essere eseguita senza richiedere una password ### La raccolta di rete è stata eseguita senza sudo Se viene visualizzato il seguente avviso nella pagina **Inventario scoperto**: ``` Network collection ran without sudo. Process-level connection data may be missing. ``` Questo avviso indica che l'account utente SSH non dispone dell'accesso sudo sul server di destinazione. Senza sudo, lo strumento di rilevamento può comunque raccogliere i dati delle connessioni di rete, ma non può determinare a quale processo appartiene ciascuna connessione. Per raccogliere dati di connessione completi a livello di processo, assicurati che l'utente SSH disponga dell'accesso sudo sul server di destinazione. ## Errori di raccolta delle metriche del sistema operativo ### UUID del server mancante per i server Linux Se lo strumento di rilevamento non è in grado di raccogliere l'UUID del server (visualizzato come vuoto o mancante) per i server Linux, verifica che le credenziali SSH configurate per tali server abbiano i privilegi sudo. Lo strumento utilizza `dmidecode` per leggere l'UUID del server. Se non `dmidecode` è installato, lo strumento torna alla lettura`/sys/class/dmi/id/product_uuid`, che richiede anche l'accesso sudo. Senza sudo, nessuno dei due metodi può recuperare l'UUID. **Risoluzione:** assicurati che l'account utente SSH fornito allo strumento di rilevamento disponga dell'accesso sudo sui server Linux di destinazione. ## Problemi di accesso nell'inventario Discovered Se viene visualizzato un messaggio nello **stato della raccolta sul server**, ad esempio Credenziali mancanti o Accesso negato: 1. Seleziona il server nella tabella dei server rilevati. 1. Scegli **Gestisci credenziali di accesso** Puoi scegliere di: 1. Seleziona credenziali alternative dal menu a discesa **Seleziona credenziali**. 1. Seleziona **Usa nuove credenziali e fornisci nuove credenziali**. 1. **Save (Salva)**. Lo strumento di rilevamento riprova la connessione dopo aver salvato le modifiche. ## Risoluzione dei problemi di autenticazione tramite chiave SSH **Test della connettività delle chiavi SSH dallo strumento di rilevamento** Se l'autenticazione con chiave SSH fallisce, verifica la connettività dallo strumento di rilevamento al server di destinazione: 1. Accedere allo strumento di rilevamento (tramite console vSphere o SSH sull'host Linux). 1. Verifica la connettività SSH utilizzando la tua chiave privata: ``` ssh -i /path/to/private_key -o StrictHostKeyChecking=no @ ``` 1. Se la connessione riesce, il problema riguarda il modo in cui la chiave è stata caricata nello strumento di rilevamento. Re-upload inserisci la chiave e verifica che il nome utente corrisponda. 1. Se la connessione fallisce, controlla il messaggio di errore nella tabella seguente. | Messaggio di errore | Causa | Risoluzione | | --- | --- | --- | | Permission denied (publickey) | La chiave pubblica non è nel authorized\_keys file del server di destinazione o il nome utente è sbagliato. | Aggiungi la chiave pubblica \~/.ssh/authorized\_keys al server di destinazione per l'utente corretto. Verifica le autorizzazioni dei file:chmod 700 \~/.ssh && chmod 600 \~/.ssh/authorized\_keys. | | Connection timed out after 20s | La porta 22 non è raggiungibile dallo strumento di rilevamento. | Verificate che la porta 22 sia aperta tra lo strumento di rilevamento e il server di destinazione. Controlla i firewall e i gruppi di sicurezza. | | Connection refused | Il servizio SSH non è in esecuzione sul server di destinazione. | Avvia il servizio SSH:. sudo systemctl start sshd | | Invalid SSH key for credential '{{name}}' | Il formato della chiave non è supportato, i dati chiave sono danneggiati o la passphrase è mancante o errata. | Verifica che il formato della chiave sia RSA, ECDSA o Ed25519 in formato PEM, OpenSSH o PKCS \#8. Se la chiave è crittografata, assicurati che la passphrase sia corretta. | ## Risoluzione dei problemi del programma di installazione Linux **La porta 5000 è già in uso** **Sintomo:** il servizio Discovery Tool non si avvia dopo l'installazione. **Risoluzione:** identifica e interrompi il processo utilizzando la porta 5000: ``` sudo ss -tlnp | grep :5000 ``` Interrompi il processo in conflitto, quindi riavvia lo strumento di rilevamento: ``` sudo ./AWS-Transform-discovery-tool.sh start ``` ## Messaggi di errore comuni Questa tabella descrive i messaggi di errore più comuni e le relative spiegazioni: | Messaggio | Location (Ubicazione) | Spiegazione | | --- | --- | --- | | È già stata creata una password | Crea una pagina con password | Condizione di gara in cui due utenti creano password contemporaneamente; aggiorna | | Esportazione non riuscita | Pagina dell'inventario | Riprova o invia i registri | | È già in corso una raccolta su richiesta | Pagina dell'inventario | Condizione di gara quando due utenti avviano le raccolte manuali contemporaneamente; riprova al termine della raccolta manuale corrente | | Command timed out after 60s | Stato della raccolta sul server | Un comando sul server di destinazione non è stato completato entro 60 secondi. Ciò può verificarsi su server con carichi elevati. Riprova la raccolta o esamina il carico del server di destinazione. | | Una o più credenziali contengono UUID sconosciuti | Pagina di accesso al sistema operativo | Condizione valida quando due utenti modificano le credenziali del sistema operativo contemporaneamente; riprova | | Password non valida | Sign-in pagina | Password errata per l'accesso; contatta l'amministratore o contattaci | | La tua sessione è scaduta. Effettua nuovamente il login. | Sign-in pagina | La sessione è scaduta, è necessario effettuare nuovamente il login | | Si è verificato un errore interno | Diverse pagine | Riprova o invia i log |