Depurar conetividade

MySQL   |  PostgreSQL   |  PostgreSQL para AlloyDB

Depure a conetividade

Configurou a conetividade entre as bases de dados de origem e de destino, mas como sabe se estão associadas? Quando as comunicações entre eles falham, como pode descobrir o que correu mal e onde?

As ferramentas mais básicas são ping e traceroute.

Tchim-tchim

Ping realiza um teste básico para determinar se o destino ("anfitrião remoto") está disponível a partir da origem. Ping envia um pacote ICMP Echo Request para um anfitrião remoto e espera um ICMP Echo Reply em troca. Se ping não tiver êxito, não existe um trajeto da origem para o destino. No entanto, o sucesso não significa que os seus pacotes consigam passar, apenas que, em geral, é possível alcançar o anfitrião remoto.

Embora o ping possa determinar se um anfitrião está ativo e a responder, não é garantido que seja fiável. Alguns fornecedores de rede bloqueiam o ICMP como uma precaução de segurança, o que pode dificultar a depuração da conetividade.

Traceroute

Traceroute testa o percurso completo que os pacotes de rede fazem de um anfitrião para outro. Mostra todos os passos ("saltos") que o pacote dá ao longo do caminho e quanto tempo demora cada passo. Se o pacote não chegar ao destino, o traceroute não é concluído, mas termina com uma série de asteriscos. Neste caso, procure o último endereço IP que foi alcançado com êxito ao longo do caminho. Foi aqui que a conetividade foi interrompida.

Traceroute pode expirar. Também pode falhar se um gateway ao longo do caminho não estiver configurado corretamente para transmitir o pacote ao próximo salto.

Quando a traceroute não é concluída, pode conseguir descobrir onde parou. Encontre o último endereço IP apresentado no resultado traceroute e faça uma pesquisa no navegador por who owns [IP_ADDRESS]. Os resultados podem ou não mostrar o proprietário da morada, mas vale a pena tentar.

mtr

A ferramenta mtr é uma forma de traceroute que permanece ativa e é atualizada continuamente, de forma semelhante ao funcionamento do comando top para processos locais.

Localize o seu endereço IP local

Se não souber o endereço local do seu anfitrião, execute o comando ip -br address show. No Linux, isto mostra a interface de rede, o estado da interface, o IP local e os endereços MAC. Por exemplo: eth0 UP 10.128.0.7/32 fe80::4001:aff:fe80:7/64.

Em alternativa, pode executar ipconfig ou ifconfig para ver o estado das suas interfaces de rede.

Localize o endereço IP de saída

Se não souber o endereço IP que as bases de dados de origem e de destino usam para comunicar entre si (o endereço IP de saída), conclua os seguintes passos:

1. Aceda à página Instâncias de SQL no Google Cloud console.

   Aceda à página Instâncias do Cloud SQL

2. Clique no nome da instância associada à tarefa de migração que está a depurar.

3. Desloque a página para baixo até aparecer o painel Ligar a esta instância. Neste painel, é apresentado o endereço IP de saída.

Abra portas locais

Para verificar se o seu anfitrião está a ouvir nas portas que pensa que está, execute o comando ss -tunlp4. Isto indica que portas estão abertas e a escutar. Por exemplo, se tiver uma base de dados MySQL em execução, a porta 3306 deve estar ativa e a receber pedidos. Para o SSH, deve ver a porta 22.

Toda a atividade da porta local

Use o comando netstat para ver toda a atividade da porta local. Por exemplo, netstat -lt mostra todas as portas atualmente ativas.

Ligue-se ao anfitrião remoto através do telnet

Para verificar se consegue estabelecer ligação ao anfitrião remoto através do TCP, execute o comando telnet. O Telnet tenta estabelecer ligação ao endereço IP e à porta que lhe indicar.

Se o seu anfitrião remoto estiver a executar uma base de dados MySQL, por exemplo, deve conseguir estabelecer ligação através do telnet à porta 3306: telnet 35.193.198.159 3306.

Se tiver êxito, vê o seguinte:

Trying 35.193.198.159...

Connected to 35.193.198.159. .

Em caso de falha, o telnet deixa de responder até forçar o encerramento da tentativa:

Trying 35.193.198.159...

^C. .

Cloud Logging

O Database Migration Service e o Cloud SQL usam o Cloud Logging. Consulte a documentação do Cloud Logging para ver informações completas e reveja as consultas de exemplo do Cloud SQL.

Ver registos

Pode ver registos de instâncias do Cloud SQL e outros Google Cloud projetos, como instâncias do Cloud VPN ou Compute Engine. Para ver os registos das entradas de registo da sua instância do Cloud SQL:

Consola

1. Aceda ao Explorador de registos
2. Selecione um projeto do Cloud SQL existente na parte superior da página.
3. No criador de consultas, adicione o seguinte:
• Recurso: selecione Base de dados do Cloud SQL. Na caixa de diálogo, selecione uma instância do Cloud SQL.
• Nomes dos registos: desloque a página até à secção do Cloud SQL e selecione os ficheiros de registo adequados para a sua instância. Por exemplo:
  • cloudsql.googlapis.com/mysql-general.log
  • cloudsql.googleapis.com/mysql.err
• Gravidade: selecione um nível de registo.
• Intervalo de tempo: selecione uma predefinição ou crie um intervalo personalizado.

gcloud

Use o comando gcloud logging para ver as entradas do registo. No exemplo abaixo, substitua PROJECT_ID. A flag limit é um parâmetro opcional que indica o número máximo de entradas a devolver.

gcloud logging read "projects/[PROJECT_ID]/logs/cloudsql.googleapis.com/mysql-general.log" --limit=10

Endereços IP privados

As ligações a uma instância do Cloud SQL através de um endereço IP privado são autorizadas automaticamente para intervalos de endereços RFC 1918. Os intervalos de endereços não RFC 1918 têm de ser configurados no Cloud SQL como redes autorizadas. Também tem de atualizar a interligação de redes para o Cloud SQL para exportar quaisquer trajetos não RFC 1918. Por exemplo: gcloud compute networks peerings update cloudsql-mysql-googleapis-com --network=NETWORK --export-subnet-routes-with-public-ip --project=PROJECT

O intervalo de IPs 172.17.0.0/16 está reservado para a rede de ponte do Docker. Todas as instâncias do Cloud SQL criadas com um endereço IP nesse intervalo vão ficar inacessíveis. As ligações de qualquer endereço IP nesse intervalo a instâncias do Cloud SQL que usem o endereço IP privado falham.

Resolução de problemas da VPN

Consulte a página de Google Cloud resolução de problemas da VPN na nuvem.

Resolução de problemas de túnel SSH inverso

O túnel SSH é um método para encaminhar algumas comunicações com base numa ligação SSH. Os túneis SSH inversos permitem configurar um túnel SSH, mas mantendo que a rede de destino é a que inicia a ligação do túnel. Isto é útil quando não quer abrir uma porta na sua própria rede para fins de segurança.

O que está a tentar alcançar é configurar o seguinte: Cloud SQL DB ---> Compute Engine VM bastion ---> tunnel ---> source network bastion ---> source DB

Embora o serviço de migração de bases de dados migre dados de uma origem para um destino, deve ativar a conetividade do destino para a origem.

Presume-se que:

• O Compute Engine VM bastion pode aceder ao Cloud SQL DB.

• O source network bastion pode aceder ao source DB (isto é conseguido através do intercâmbio da rede do Cloud SQL com a rede da VM do Compute Engine).

Em seguida, configura um túnel SSH do source network bastion para o Compute Engine VM bastion, que encaminha todas as ligações recebidas para alguma porta no Compute Engine VM bastion através do túnel para o source DB.

Cada link no cenário acima pode ser configurado incorretamente e impedir que todo o fluxo funcione. Resolva os problemas de cada link, um de cada vez:

source network bastion ---> source DB

1. Estabeleça ligação ao source network bastion através de SSH ou a partir do terminal, se for a máquina local.
2. Teste a conetividade à base de dados de origem através de um dos seguintes métodos:
   • telnet [source_db_host_or_ip] [source_db_port] - expect to see the mysql password prompt (something like 5.7.12-logPuN0%`D5G??f9nVS'Pmysql_native_passwordConnection)
   • [db_client] -h[source_db_host_or_ip] -P[source_db_port] - expect to see access denied (something like ERROR 1045 (28000): Access denied for user...)

Se isto falhar, tem de verificar se ativou o acesso a partir deste bastion à base de dados de origem.

Compute Engine VM bastion ---> source DB

1. SSH para o Compute Engine VM bastion (usando gcloud compute ssh VM_INSTANCE_NAME)
2. Teste a conetividade à base de dados de origem através de um dos seguintes métodos:
   • telnet 127.0.0.1 [tunnel_port] – espere ver o pedido de palavra-passe do mysql (algo como 5.7.12-logPuN0%`D5G??f9nVS'Pmysql_native_passwordConnection)
   • [db_client] -h127.0.0.1 -P[tunnel_port] - expect to see access denied (something like ERROR 1045 (28000): Access denied for user...)

Se esta ação falhar, tem de verificar se o túnel está a funcionar corretamente. A execução de sudo netstat -tupln mostra todos os processos de escuta nesta VM e deve ver sshd listening on the tunnel_port.

Cloud SQL DB ---> source DB

A melhor forma de testar esta opção é através da testing the migration job do Database Migration Service. Se isto falhar, significa que existe algum problema com o intercâmbio da VPC ou o encaminhamento entre a rede do Cloud SQL e a rede Compute Engine VM bastion.

A firewall do servidor da base de dados de origem tem de ser configurada para permitir todo o intervalo de IP interno atribuído para a ligação de serviço privado da rede VPC que a instância de destino do Cloud SQL vai usar como o campo privateNetwork das respetivas definições de ipConfiguration.

Para encontrar o intervalo de IPs internos na consola:

1. Aceda à página Redes VPC na Google Cloud consola.

2. Selecione a rede de VPC que quer usar.

3. Selecione Acesso a serviços privados > Intervalos de IP atribuídos para serviços.

4. Encontre o intervalo de IPs internos associado à ligação criada por servicenetworking-googleapis-com.

Também pode ver o tráfego entre a instância do Cloud SQL e a instância de VM do Compute Engine na consola do Cloud Logging no projeto Cloud VPN gateway. Nos registos da VM do Compute Engine, procure tráfego proveniente da instância do Cloud SQL. Nos registos da instância do Cloud SQL, procure tráfego proveniente da VM do Compute Engine.