Debug della connettività
Hai configurato la connettività tra i database di origine e di destinazione, ma come fai a sapere se 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 in cambio un ICMP Echo Reply. Se ping non va a buon fine, non esiste una route dall'origine alla destinazione. Tuttavia, il successo non significa che i pacchetti possano passare, ma solo che in generale l'host remoto è raggiungibile.
Sebbene ping possa indicare se un host è attivo e risponde, non è garantito che sia affidabile. Alcuni fornitori di rete bloccano ICMP come misura di sicurezza, il che può rendere più difficile il debug della connettività.
Traceroute
Traceroute testa la route completa dei pacchetti di rete da un host a un altro. Mostra tutti i passaggi ("hop") che il pacchetto esegue lungo il percorso e la durata di ogni passaggio. Se il pacchetto non raggiunge la 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ò andare in timeout. Può anche non essere completato se un gateway lungo il percorso non è configurato correttamente per passare il pacchetto all'hop successivo.
Se traceroute non viene completato, potresti essere in grado di capire dove si è interrotto. Trova l'ultimo indirizzo IP elencato nell'output di 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.
Individuare l'indirizzo IP locale
Se non conosci l'indirizzo locale dell'host, esegui il comando ip -br address show. Su Linux, questo comando mostra 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 interfacce di rete.
Individuare 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:
Vai alla pagina Istanze SQL in the Google Cloud console.
Fai clic sul nome dell'istanza associata al job di migrazione di cui stai eseguendo il debug.
Scorri verso il basso fino a visualizzare il riquadro Connettiti a questa istanza. In questo riquadro viene visualizzato l'indirizzo IP in uscita.
Aprire le porte locali
Per verificare che l'host sia in ascolto sulle porte che ritieni, esegui il comando ss -tunlp4. Questo comando indica quali porte sono aperte e in ascolto.
Ad esempio, se è in esecuzione un database PostgreSQL, la porta 5432 deve essere attiva e in ascolto. Per SSH, dovresti vedere la porta 22.
Tutte le attività delle porte locali
Utilizza il comando netstat per visualizzare tutte le attività delle porte locali. Ad esempio, netstat -lt mostra tutte le porte attualmente attive.
Connettersi all'host remoto utilizzando telnet
Per verificare di poterti connettere all'host remoto utilizzando TCP, esegui il comando telnet. Telnet tenta di connettersi all'indirizzo IP e alla porta che gli fornisci.
telnet 35.193.198.159 5432.
Se l'operazione va a buon fine, viene visualizzato il seguente messaggio:
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 sull'host).
Assicurati che la sezione delle connessioni di replica del file pg_hba.conf sul database di origine sia aggiornata in modo da accettare connessioni dall'intervallo di indirizzi IP del VPC di Cloud SQL.
Cloud Logging
Database Migration Service e Cloud SQL utilizzano Cloud Logging. Per informazioni complete, consulta la documentazione di Cloud Logging e le query di esempio di Cloud SQL.Visualizzare i log
Puoi visualizzare i log per le istanze Cloud SQL e altri Google Cloud progetti come le istanze Cloud VPN o Compute Engine. Per visualizzare le voci di log dell'istanza Cloud SQL:Console
- Vai a Esplora log
- Seleziona un progetto Cloud SQL esistente nella parte superiore della pagina.
- In Query Builder, aggiungi quanto segue:
- Risorsa: seleziona Database Cloud SQL. Nella finestra di dialogo, seleziona un' istanza Cloud SQL.
- Nomi log: scorri fino alla sezione Cloud SQL e seleziona
file di log appropriati per la tua istanza. Ad esempio:
- cloudsql.googleapis.com/postgres.log
- Gravità: seleziona un livello di log.
- Intervallo di tempo: seleziona un intervallo predefinito o creane uno personalizzato.
gcloud
Utilizza il gcloud logging
comando per visualizzare le voci di log. Nell'esempio seguente, sostituisci PROJECT_ID.
Il limit
flag è un parametro facoltativo che indica il numero massimo di voci da
restituire.
gcloud logging read "projects/[PROJECT_ID]/logs/cloudsql.googleapis.com/postgres.log" --limit=10
Indirizzi IP privati
Le connessioni a un'istanza Cloud SQL che utilizza un indirizzo IP privato vengono
autorizzate automaticamente per gli intervalli di indirizzi RFC 1918
. Gli intervalli di indirizzi non RFC 1918 devono essere configurati
in Cloud SQL come reti
autorizzate. Devi anche aggiornare il peering di rete a Cloud SQL per esportare eventuali route non RFC 1918. Ad esempio:
gcloud compute networks peerings update cloudsql-postgres-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 istanze Cloud SQL create con un indirizzo IP in questo intervallo non saranno raggiungibili. Le connessioni da qualsiasi indirizzo IP all'interno di questo intervallo alle istanze Cloud SQL che utilizzano un indirizzo IP privato non andranno a buon fine.
Risoluzione dei problemi relativi alla VPN
Consulta la Google Cloud pagina Risoluzione dei problemi di Cloud VPN.
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, ma mantenendo la rete di destinazione come quella che avvia la connessione del tunnel. Questa funzionalità è utile quando non vuoi aprire una porta nella tua rete per motivi di sicurezza.
L'obiettivo è configurare quanto segue: Cloud SQL DB ---> Compute Engine VM bastion ---> tunnel ---> source network bastion ---> source DB
Si presuppone che:
Il Compute Engine VM bastion possa accedere al Cloud SQL DB.
Il source network bastion possa accedere al source DB (questo risultato si ottiene eseguendo il peering della rete Cloud SQL con la rete VM Compute Engine).
Configura quindi un tunnel SSH dal source network bastion al Compute Engine VM bastion, che instrada tutte le connessioni in entrata a una porta sul Compute Engine VM bastion tramite il tunnel al source DB.
Ogni link nello scenario precedente può essere configurato in modo errato e impedire il funzionamento dell'intero flusso. Risolvi i problemi di ogni link, uno alla volta:
source network bastion ---> source DB
- Connettiti al source network bastion utilizzando SSH o dal terminale se si tratta della macchina locale.
- Verifica la connettività al database di origine utilizzando uno dei seguenti metodi:
telnet [source_db_host_or_ip] [source_db_port]- dovresti visualizzare le stringhe di connessione telnet, che terminano conConnected to x.x.x.x.[db_client] -h[source_db_host_or_ip] -P[source_db_port]- dovresti visualizzare l'accesso negato
Se l'operazione non va a buon fine, devi verificare di aver abilitato l'accesso da questo bastion al database di origine.
Compute Engine VM bastion ---> source DB
- Accedi tramite SSH al Compute Engine VM bastion (utilizzando
gcloud compute ssh VM_INSTANCE_NAME) - Verifica la connettività al database di origine utilizzando uno dei seguenti metodi:
telnet 127.0.0.1 [tunnel_port]- dovresti visualizzare le stringhe di connessione telnet, che terminano conConnected to x.x.x.x.[db_client] -h127.0.0.1 -P[tunnel_port]- dovresti visualizzare l'accesso negato
Se l'operazione non va a buon fine, devi verificare che il tunnel sia attivo e in esecuzione correttamente.
L'esecuzione di sudo netstat -tupln mostra tutti i processi in ascolto su
questa VM e dovresti vedere sshd listening on the tunnel_port.
Cloud SQL DB ---> source DB
Il modo migliore per testare questa funzionalità è testing the migration job da Database Migration Service.
Se l'operazione non va a buon fine, significa che si è verificato un problema con il peering VPC o il routing
tra la rete Cloud SQL e la Compute Engine VM bastion
rete.
Il firewall del server del database di origine deve essere configurato per consentire l'intero intervallo IP interno allocato per la connessione ai servizi privati della rete VPC che l'istanza di destinazione Cloud SQL utilizzerà come campo privateNetwork delle impostazioni ipConfiguration.
Per trovare l'intervallo IP interno nella console:
Vai alla pagina Reti VPC nella Google Cloud console.
Seleziona la rete VPC che vuoi utilizzare.
Seleziona Accesso privato ai servizi > Intervalli IP allocati per i servizi.
Trova l'intervallo IP interno associato alla connessione creata da servicenetworking-googleapis-com.
Puoi anche visualizzare il traffico tra l'istanza Cloud SQL e l'istanza VM Compute Engine in
the Cloud Logging console in the
Cloud VPN gateway project. Nei log VM Compute Engine, cerca il traffico proveniente dall'istanza Cloud SQL. Nei log dell'istanza Cloud SQL, cerca il traffico proveniente dalla VM Compute Engine.