Eseguire il debug della connettività
Hai configurato la connettività tra i database di origine e di destinazione, ma come fai a sapere che sono collegati? Quando le comunicazioni tra i due dispositivi non vanno a buon fine, come puoi scoprire cosa non va e dove?
Gli strumenti di base 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 ICMP Echo Reply in risposta. Se ping non va a buon fine,
non esiste un percorso dall'origine alla destinazione. Tuttavia, il successo non significa che i pacchetti possono passare, ma solo che in generale l'host remoto può essere raggiunto.
Sebbene ping possa indicare se un host è attivo e risponde, non è garantito che sia affidabile. Alcuni fornitori di servizi 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
a un altro. Mostra tutti i passaggi ("hop") che il pacchetto compie nel percorso e la durata di 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 si è interrotta la connettività.
Traceroute può scadere. Inoltre, la procedura potrebbe non essere completata se un gateway lungo il percorso non è configurato correttamente per trasmettere il pacchetto all'hop successivo.
Quando traceroute non riesce a completare l'operazione, potresti riuscire a capire dove si è interrotta. Individua l'ultimo indirizzo IP elencato nell'traceroute
output e cerca who owns [IP_ADDRESS] nel browser. Nei risultati potrebbe o meno essere visualizzato il proprietario dell'indirizzo, ma vale la pena provare.
mtr
Lo strumento mtr è una forma di traceroute che rimane attiva e 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 del tuo host, esegui il comandoip -br address show. Su Linux vengono mostrati 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.
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), svolgi i seguenti passaggi:
Vai alla pagina Istanze SQL nella console Google Cloud.
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 Connetti a questa istanza. In questo riquadro viene visualizzato l'indirizzo IP in uscita.
Aprire le porte locali
Per verificare che l'host ascolti sulle porte che ritieni, esegui il comando ss -tunlp4. Questo ti dice quali porte sono aperte e in ascolto.
Ad esempio, se hai un database MySQL in esecuzione, la porta 3306 deve essere attiva e in ascolto. Per SSH, dovresti vedere la porta 22.
Tutta l'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 di poter connetterti all'host remoto utilizzando TCP, esegui il comando telnet. Telnet tenta di connettersi all'indirizzo IP e alla porta che specifichi.
telnet 35.193.198.159 3306.
In caso di esito positivo, viene visualizzato quanto segue:
Trying 35.193.198.159...
Connected to 35.193.198.159.
.
In caso di errore, viene visualizzato il messaggio telnet smette di rispondere finché non chiudi forzatamente il tentativo:
Trying 35.193.198.159...
^C.
.
Cloud Logging
Database Migration Service e Cloud SQL utilizzano Cloud Logging. Consulta la documentazione di Cloud Logging per informazioni complete e consulta le query di esempio di Cloud SQL.Visualizza i log
Puoi visualizzare i log per le istanze Cloud SQL e per altri progetti Google Cloudcome le istanze Cloud VPN o Compute Engine. Per visualizzare i log per le voci del log della tua 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 dei log: scorri fino alla sezione Cloud SQL e seleziona
i file di log appropriati per la tua istanza. Ad esempio:
- cloudsql.googlapis.com/mysql-general.log
- cloudsql.googleapis.com/mysql.err
- Gravità: seleziona un livello di log.
- Intervallo di tempo: seleziona un'impostazione predefinita o crea un intervallo 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/cloudsql.googleapis.com/mysql-general.log" --limit=10
Indirizzi IP privati
Le connessioni a un'istanza Cloud SQL che utilizzano un indirizzo IP privato sono 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 con Cloud SQL per
esportare eventuali route non RFC 1918. Ad esempio: gcloud compute networks peerings update cloudsql-mysql-googleapis-com --network=NETWORK --export-subnet-routes-with-public-ip --project=PROJECT.
L'intervallo IP 172.17.0.0/16 è riservato alla rete del bridge Docker. Tutte le istanze Cloud SQL create con un indirizzo IP in quell'intervallo non saranno accessibili. Le connessioni da qualsiasi indirizzo IP all'interno di questo intervallo alle istanze Cloud SQL che utilizzano l'indirizzo IP privato non andranno a buon fine.
Risoluzione dei problemi relativi alla VPN
Consulta la pagina Google Cloud Risoluzione dei problemi relativi alla VPN Cloud.
Risolvere i 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. Questa opzione è utile se non vuoi aprire una porta nella tua rete per motivi di sicurezza.
Stai cercando di configurare quanto segue: Cloud SQL DB ---> Compute Engine VM bastion ---> tunnel ---> source network bastion ---> source DB
Si presume che:
Compute Engine VM bastion può accedere a Cloud SQL DB.
source network bastion può accedere a source DB (questo viene ottenuto eseguendo il peering della rete Cloud SQL con la rete della VM Compute Engine).
Poi configuri un tunnel SSH dal source network bastion al Compute Engine VM bastion, che inoltra le connessioni in arrivo a qualche 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 relativi a ogni link, uno alla volta:
source network bastion ---> source DB
- Connettiti a source network bastion tramite 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 vedere il prompt per la password di MySQL (ad es.5.7.12-logPuN0%`D5G??f9nVS'Pmysql_native_passwordConnection).[db_client] -h[source_db_host_or_ip] -P[source_db_port]: dovrebbe essere visualizzato Accesso negato (ad es.ERROR 1045 (28000): Access denied for user...).
Se la verifica non va a buon fine, devi verificare di aver attivato l'accesso da questo bastione al DB di origine.
Compute Engine VM bastion ---> source DB
- Accedi tramite SSH a 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 il prompt per la password mysql (qualcosa come5.7.12-logPuN0%`D5G??f9nVS'Pmysql_native_passwordConnection)[db_client] -h127.0.0.1 -P[tunnel_port]: dovresti visualizzare l'accesso denied (ad es.ERROR 1045 (28000): Access denied for user...)
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 di ascolto su questa VM e dovresti vedere sshd listening on the tunnel_port.
Cloud SQL DB ---> source DB
Questo test è meglio eseguito da testing the migration job di Database Migration Service.
Se l'operazione non va a buon fine, significa che c'è un problema con il peering o il routing VPC tra la rete Cloud SQL 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 al servizio privato 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 console Google Cloud .
Seleziona la rete VPC che vuoi utilizzare.
Seleziona la scheda CONNESSIONE A SERVIZI PRIVATI.
Puoi anche visualizzare il traffico tra l'istanza Cloud SQL e l'istanza VM di Compute Engine nella console Cloud Logging del progetto Cloud VPN gateway. Nei log della 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.