Debug della connettività

Esegui il debug della connettività

Hai configurato la connettività tra i database di origine e di destinazione, ma come fai a sapere che sono connessi? Quando le comunicazioni tra loro non vanno a buon fine, come puoi scoprire cosa è andato storto e dove?

Gli strumenti più basilari sono ping e traceroute.

Dindin

Ping esegue un test di base per determinare se la destinazione ("host remoto") è disponibile dall'origine. Ping invia un pacchetto ICMP Echo Request a un host remoto e si aspetta un pacchetto ICMP Echo Reply in risposta. Se ping non riesce, significa che non esiste una route dall'origine alla destinazione. Tuttavia, l'esito positivo non significa che i pacchetti possono passare, ma solo che, in generale, l'host remoto può essere raggiunto.

Sebbene ping possa stabilire se un host è attivo e risponde, non è garantito che sia affidabile. Alcuni provider di rete bloccano ICMP come misura di sicurezza, il che può rendere più difficile il debug della connettività.

Traceroute

Traceroute testa il percorso completo dei pacchetti di rete da un host all'altro. Mostra tutti i passaggi ("hop") eseguiti dal pacchetto lungo il percorso e il tempo impiegato per ogni passaggio. Se il pacchetto non arriva fino alla destinazione, traceroute non viene completato, ma termina con una serie di asterischi. In questo caso, cerca l'ultimo indirizzo IP raggiunto correttamente lungo il percorso. È qui che la connettività si è interrotta.

Traceroute può scadere. Inoltre, l'operazione potrebbe non essere completata se un gateway lungo il percorso non è configurato correttamente per passare il pacchetto all'hop successivo.

Quando traceroute non viene completato, potresti essere in grado di capire dove si è interrotto. Trova l'ultimo indirizzo IP elencato nell'output traceroute ed esegui una ricerca nel browser per who owns [IP_ADDRESS]. I risultati potrebbero mostrare o meno il proprietario dell'indirizzo, ma vale la pena provare.

mtr

Lo strumento mtr è una forma di traceroute che rimane attiva e viene aggiornata continuamente, in modo simile al funzionamento del comando top per i processi locali.

Individua il tuo indirizzo IP locale

Se non conosci l'indirizzo locale del tuo host, esegui il comando ip -br address show. Su Linux, vengono visualizzati l'interfaccia di rete, lo stato dell'interfaccia, l'IP locale e gli indirizzi MAC. Ad esempio: eth0 UP 10.128.0.7/32 fe80::4001:aff:fe80:7/64.

In alternativa, puoi eseguire ipconfig o ifconfig per visualizzare lo stato delle tue interfacce di rete.

Individua l'indirizzo IP in uscita

Se non conosci l'indirizzo IP utilizzato dai database di origine e di destinazione per comunicare tra loro (l'indirizzo IP in uscita), completa i seguenti passaggi:

  1. Vai alla pagina Cluster nella console Google Cloud :

    Vai ai cluster AlloyDB per PostgreSQL

  2. Individua il cluster AlloyDB per PostgreSQL associato al job di migrazione di cui stai eseguendo il debug.
  3. Entrambi gli indirizzi IP pubblici in uscita vengono visualizzati nei dettagli dell'istanza principale del cluster.

Apri porte locali

Per verificare che l'host sia in ascolto sulle porte che pensi, esegui il comando ss -tunlp4. In questo modo puoi vedere quali porte sono aperte e in ascolto.

Ad esempio, se hai un database PostgreSQL in esecuzione, la porta 5432 deve essere attiva e in ascolto. Per SSH, dovresti vedere la porta 22.

Tutte le attività della porta locale

Utilizza il comando netstat per visualizzare tutta l'attività della porta locale. Ad esempio, netstat -lt mostra tutte le porte attualmente attive.

Connettiti all'host remoto utilizzando telnet

Per verificare che puoi connetterti all'host remoto utilizzando TCP, esegui il comando telnet. Telnet tenta di connettersi all'indirizzo IP e alla porta che hai specificato.

Ad esempio, se l'host remoto esegue un database PostgreSQL, dovresti essere in grado di connetterti tramite telnet sulla porta 5432: telnet 35.193.198.159 5432.

In caso di esito positivo, viene visualizzato quanto segue: 

Trying 35.193.198.159...
Connected to 35.193.198.159.

In caso di errore, telnet smette di rispondere finché non forzi la chiusura del tentativo: 

Trying 35.193.198.159...
^C

Autenticazione client

L'autenticazione client è controllata da un file di configurazione denominato pg_hba.conf (HBA sta per autenticazione basata su host).

Assicurati che la sezione delle connessioni di replica del file pg_hba.conf nel database di origine sia aggiornata in modo da accettare connessioni dall'intervallo di indirizzi IP del VPC di AlloyDB per PostgreSQL.

Cloud Logging

Database Migration Service e AlloyDB per PostgreSQL utilizzano Cloud Logging. Per informazioni complete, consulta la documentazione di Cloud Logging.

Visualizza i log

Puoi visualizzare i log per le istanze AlloyDB per PostgreSQL e altri progetti Google Cloud, come le istanze Cloud VPN o Compute Engine. Per visualizzare i log per le voci di log dell'istanza AlloyDB per PostgreSQL:

Console

  1. Vai a Esplora log
  2. Seleziona il progetto AlloyDB per PostgreSQL nella parte superiore della pagina.
  3. In Query Builder, aggiungi quanto segue:
    • Risorsa: seleziona Istanza AlloyDB per PostgreSQL. Nella finestra di dialogo, seleziona l'istanza AlloyDB per PostgreSQL.
    • Nomi dei log: scorri fino alla sezione AlloyDB per PostgreSQL e seleziona i file di log appropriati per la tua istanza. Ad esempio:
      • alloydb.googleapis.com/postgres.log
    • Gravità: seleziona un livello di log.
    • Intervallo di tempo: seleziona un intervallo preimpostato o creane uno personalizzato.

gcloud

Utilizza il comando gcloud logging per visualizzare le voci di log. Nell'esempio seguente, sostituisci PROJECT_ID. Il flag limit è un parametro facoltativo che indica il numero massimo di voci da restituire.

gcloud logging read "projects/PROJECT_ID/logs/alloydb.googleapis.com%2Fpostgres.log" --limit=10

Indirizzi IP privati

Le connessioni a un cluster AlloyDB per PostgreSQL che utilizzano un indirizzo IP privato sono autorizzate per gli intervalli di indirizzi RFC 1918. Se la tua rete utilizza intervalli di indirizzi non RFC 1918, devi aggiornare il peering di rete per esportare le route non RFC 1918. Ad esempio: gcloud compute networks peerings update servicenetworking-googleapis-com --network=NETWORK --export-subnet-routes-with-public-ip --project=PROJECT

L'intervallo IP 172.17.0.0/16 è riservato alla rete bridge Docker. Le connessioni da qualsiasi indirizzo IP all'interno di questo intervallo ai cluster AlloyDB per PostgreSQL che utilizzano un indirizzo IP privato non riusciranno.

Risoluzione dei problemi relativi alla VPN

Consulta la pagina Risoluzione dei problemi di Cloud VPNGoogle Cloud .

Risolvi gli errori del proxy TCP

Anche la configurazione del proxy TCP potrebbe causare errori. Per risolvere i problemi di un errore del proxy TCP, consulta i seguenti esempi di problemi e come risolverli:

Errore di avvio della macchina virtuale (VM)

Quando avvii l'istanza VM in Compute Engine, viene visualizzato il seguente messaggio:

You do not currently have an active account selected.

Da provare

Esegui uno dei seguenti comandi per configurare un account attivo:

  • Per ottenere nuove credenziali, esegui questo comando:

    gcloud auth login

  • Per selezionare un account già autenticato, esegui questo comando:

    gcloud config set account <var>ACCOUNT</var>

    Sostituisci ACCOUNT con il nome dell'account che vuoi configurare.

Connessione all'istanza del database di origine non riuscita

Durante il test del job di migrazione viene visualizzato il seguente messaggio di errore:

Failure connecting to the source database. Make sure the connectivity information on the connection profile is correct and the source database is reachable.

Da provare

Ripeti i seguenti passaggi per capire dove potrebbe risiedere il problema:

  1. Controlla se la VM che ospita il container del proxy TCP è in esecuzione:
    1. Nella console Google Cloud , vai alla pagina Istanze VM di Compute Engine.

      Vai a Istanze VM

    2. Cerca la VM creata durante il processo di configurazione del proxy. Se non è presente nell'elenco o non è in esecuzione, configura il proxy TCP da zero e aggiorna le impostazioni del profilo di connessione di origine nel job di migrazione con l'indirizzo IP corretto.
  2. Se la VM è in esecuzione, verifica che non si sia verificato alcun errore durante il download dell'immagine container del proxy TCP:
    1. Seleziona la VM creata durante il processo di configurazione del proxy TCP. In Log, fai clic su Porta seriale 1 (console).
    2. Se non riesci a visualizzare la voce Launching user container 'gcr.io/dms-images/tcp-proxy' nei log, il problema potrebbe essere che l'istanza non è riuscita a eseguire il pull dell'immagine da Container Registry. Per verificare se questo è il caso, connettiti alla VM e prova a eseguire manualmente il pull dell'immagine da Container Registry utilizzando il seguente comando: 
      docker pull gcr.io/dms-images/tcp-proxy

      Se visualizzi il seguente errore: Error response from daemon: Get "https://gcr.io/v2/": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers), significa che la VM non è riuscita a connettersi a Container Registry. Se la tua VM ha solo un indirizzo IP privato, devi abilitare l'accesso privato Google nella subnet di cui fa parte l'indirizzo IP; in caso contrario, la VM non avrà accesso alle API Google Enterprise, come Container Registry.

  3. Verifica che il container possa connettersi all'istanza di origine:
    1. Seleziona la VM creata durante il processo di configurazione del proxy. In Log, fai clic su Cloud Logging.
    2. Se visualizzi il messaggio Connection refused, please verify that the machine you are using to run the script can connect to the source database at, significa che il container del proxy TCP non è riuscito a connettersi all'istanza del database di origine. Ciò può accadere per diversi motivi:
      • L'indirizzo IP dell'istanza di origine non è corretto.
      • Esiste una policy del firewall che rifiuta le connessioni dal proxy TCP all'istanza di origine.
      • L'istanza di origine si trova in una rete Virtual Private Cloud (VPC) diversa da quella della VM che ospita il proxy TCP.

    Puoi eseguire il debug del problema di connettività utilizzando i test di connettività di Google Cloudper assicurarti che esista una connessione tra la VM che ospita il proxy TCP e il database di origine:

    1. Nella console Google Cloud , vai alla pagina Test di connettività.

      Connectivity Tests

    2. Fai clic su Crea Connectivity Tests.
    3. Inserisci un nome per il test.
    4. Seleziona TCP come protocollo.
    5. Seleziona Indirizzo IP dall'elenco Endpoint di origine. Inserisci l'indirizzo IP pubblico del proxy TCP appena creato se il database di origine è accessibile utilizzando un indirizzo IP pubblico; altrimenti, inserisci l'indirizzo IP privato del proxy TCP.
    6. Seleziona Indirizzo IP dall'elenco Endpoint di destinazione e inserisci l'indirizzo IP del database di origine.
    7. Inserisci il numero di porta utilizzato per connettersi al database di origine nel campo Porta di destinazione.
    8. Fai clic su Crea.

    Esegui i Connectivity Tests e risolvi eventuali problemi di connettività che si presentano. Dopo aver risolto il problema di connettività, verifica che il proxy TCP possa connettersi all'istanza di origine:

    1. Vai a Istanze VM in Compute Engine.

      Vai a Istanze VM

    2. Seleziona la VM creata durante il processo di configurazione del proxy. In Log, fai clic su Cloud Logging.
    3. Se vedi la voce di log Connection to source DB verified, significa che il proxy TCP ora può connettersi all'istanza di origine.
  4. Verifica che il test di migrazione non presenti errori di connessione.

Connessione al cluster del database di destinazione non riuscita

Se il container del proxy TCP riesce a connettersi all'istanza di origine, ma il test di migrazione continua a non riuscire a causa di problemi di connessione, il problema potrebbe essere la connettività tra il cluster AlloyDB per PostgreSQL di destinazione e la VM che ospita il container del proxy TCP.

Esegui il debug del problema

Per eseguire il debug del problema, puoi utilizzare Google Cloud Connectivity Tests per assicurarti che esista una connessione tra il cluster AlloyDB per PostgreSQL di destinazione e la VM che ospita il proxy TCP:

  1. Nella console Google Cloud , vai alla pagina Test di connettività.

    Connectivity Tests

  2. Fai clic su Crea Connectivity Tests.
  3. Imposta i seguenti parametri per il test:
    1. Inserisci un nome per il test.
    2. Seleziona TCP come protocollo.
    3. Seleziona Indirizzo IP dall'elenco Endpoint di origine e inserisci l'indirizzo IP del cluster AlloyDB per PostgreSQL appena creato.
    4. Seleziona Indirizzo IP dall'elenco Endpoint di destinazione e inserisci l'indirizzo IP privato del proxy TCP.
    5. Inserisci 5432 nel campo Porta di destinazione.
  4. Fai clic su Crea.
  5. Esegui i Connectivity Tests e risolvi eventuali problemi di connettività che si presentano.

Possibili cause

Esiste una regola firewall che nega la comunicazione tra il cluster di destinazione e la VM proxy TCP.

Da provare

Aggiungi una regola firewall che consenta al cluster di destinazione di comunicare con il proxy TCP utilizzando la porta 5432.

Possibili cause

Esiste una mancata corrispondenza del VPC tra il cluster di destinazione e la VM che esegue il container del proxy TCP.

Da provare

Seleziona lo stesso VPC per il cluster di destinazione.

Risoluzione dei problemi relativi al tunnel SSH inverso

Il tunneling SSH è un metodo per inoltrare alcune comunicazioni su una connessione SSH. Il tunneling SSH inverso consente di configurare un tunnel SSH, mantenendo la rete di destinazione come quella che avvia la connessione del tunnel. Questo è utile quando non vuoi aprire una porta nella tua rete per motivi di sicurezza.

Il tuo obiettivo è configurare quanto segue:

AlloyDB for PostgreSQL cluster ---> Compute Engine VM bastion ---> tunnel ---> source network bastion ---> source DB

Si presume che:

  • AlloyDB for PostgreSQL cluster può accedere a Compute Engine VM bastion (questo si ottiene eseguendo il peering della rete AlloyDB per PostgreSQL con la rete della VM di Compute Engine).

  • source network bastion può accedere a source DB.

Quindi, configura un tunnel SSH da source network bastion a Compute Engine VM bastion, che instrada tutte le connessioni in entrata a una porta su Compute Engine VM bastion attraverso il tunnel a source DB.

Ogni link nello scenario precedente può essere configurato in modo errato e impedire il funzionamento dell'intero flusso. Risolvi i problemi relativi a ogni link, uno alla volta:

source network bastion ---> source DB

  1. Connettiti a source network bastion utilizzando SSH o dal terminale se si tratta della macchina locale.
  2. Testa la connettività al database di origine utilizzando uno dei seguenti metodi:
    • telnet [source_db_host_or_ip] [source_db_port]: dovresti vedere le stringhe di connessione telnet, che terminano con Connected to x.x.x.x.
    • psql -h [source_db_host_or_ip] -p [source_db_port] -U [username] -d [database_name]: dovresti visualizzare una richiesta di password o un messaggio di accesso negato.

Se l'operazione non riesce, devi verificare di aver abilitato l'accesso da questo bastion al database di origine.

Compute Engine VM bastion ---> source DB

  1. Accedi tramite SSH a Compute Engine VM bastion (utilizzando gcloud compute ssh VM_INSTANCE_NAME).
  2. Testa la connettività al database di origine utilizzando uno dei seguenti metodi:
    • telnet 127.0.0.1 [tunnel_port]: dovresti vedere le stringhe di connessione telnet, che terminano con Connected to x.x.x.x.
    • psql -h 127.0.0.1 -p [tunnel_port] -U [username] -d [database_name]: dovresti visualizzare una richiesta di password o un messaggio di accesso negato.

Se l'operazione non riesce, devi verificare che il tunnel sia attivo e funzioni correttamente. L'esecuzione di sudo netstat -tupln mostra tutti i processi di ascolto su questa VM e dovresti vedere sshd listening on the tunnel_port.

AlloyDB for PostgreSQL cluster ---> source DB

Il modo migliore per testare questa funzionalità è utilizzare testing the migration job di Database Migration Service. Se l'operazione non va a buon fine, significa che si è verificato un problema con il peering o il routing VPC tra la rete AlloyDB per PostgreSQL e la rete Compute Engine VM bastion.

Il firewall del server di database di origine deve essere configurato in modo da consentire l'intero intervallo IP interno allocato per la connessione di servizi privati della rete VPC utilizzata dal cluster di destinazione AlloyDB per PostgreSQL.

Per trovare l'intervallo IP interno nella console:

  1. Vai alla pagina Reti VPC nella console Google Cloud .
  2. Seleziona la rete VPC che vuoi utilizzare.
  3. Seleziona Accesso privato ai servizi > Intervalli IP allocati per i servizi.
  4. Trova l'intervallo IP interno associato alla connessione creata da servicenetworking-googleapis-com.

Puoi anche visualizzare il traffico tra il cluster AlloyDB per PostgreSQL e l'istanza VM di Compute Engine nella console Cloud Logging nel progetto Cloud VPN gateway. Nei log della VM di Compute Engine, cerca il traffico proveniente dal cluster AlloyDB per PostgreSQL. Nei log del cluster AlloyDB per PostgreSQL, cerca il traffico proveniente dalla VM di Compute Engine.