Como depurar a conectividade

Depurar conectividade

Você configurou a conectividade entre os bancos de dados de origem e de destino, mas como saber se eles estão conectados? Quando as comunicações entre eles falham, como você pode descobrir o que deu errado e onde?

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

Ping

Ping realiza um teste básico para determinar se o destino ("host remoto") está disponível na origem. O Ping envia um pacote ICMP Echo Request para um host remoto e espera um ICMP Echo Reply em troca. Se ping não tiver êxito, isso significa que não há rota da origem até o destino. No entanto, o sucesso não significa que seus pacotes podem passar, apenas que, em geral, o host remoto pode ser alcançado.

Embora ping possa dizer se um host está ativo e respondendo, não é garantido que ele seja confiável. Alguns provedores de rede bloqueiam ICMP por medida de segurança, o que pode dificultar a depuração da conectividade.

Traceroute

Traceroute testa a rota completa que pacotes de rede usam de um host para outro. Ele mostra todas as etapas ("saltos") que o pacote percorre ao longo do tempo e quanto tempo cada etapa leva. Se o pacote não for até o destino, traceroute não será concluído, mas terminará com uma série de asteriscos. Nesse caso, procure o último endereço IP que foi alcançado ao longo do caminho. Ele será onde a conectividade caiu.

Traceroute pode expirar. Ele também não será concluído se um gateway no caminho não estiver configurado corretamente para transmitir o pacote para o próximo salto.

Quando o traceroute não for concluído, é possível descobrir onde ele parou. Encontre o último endereço IP listado na saída traceroute e faça uma pesquisa por who owns [IP_ADDRESS] com o navegador. Os resultados podem ou não mostrar o proprietário do endereço, mas vale a pena tentar.

mtr

A ferramenta mtr é uma forma de traceroute que permanece ativa e atualizada continuamente, da mesma forma que o comando top funciona para processos locais.

Localizar o endereço IP local

Se você não souber o endereço local do host, execute o comando ip -br address show. No Linux, isso mostra a interface de rede, o status 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.

Se preferir, execute ipconfig ou ifconfig para ver o status das interfaces de rede.

Localizar o endereço IP de saída

Se você não souber o endereço IP que os bancos de dados de origem e destino usam para se comunicar (o endereço IP de saída), siga estas etapas:

  1. Acesse a página "Instâncias do SQL" no console do Google Cloud .

    Acessar a página "Instâncias" do Cloud SQL

  2. Clique no nome da instância associada ao job de migração que você está depurando.
  3. Role para baixo até o painel Conectar-se a esta instância aparecer. Nesse painel, o endereço IP de saída é exibido.

Abrir portas locais

Para verificar se o host está detectando nas portas que você acredita que estejam, execute o comando ss -tunlp4. Isso informa quais portas estão abertas e detectando.

Por exemplo, se você tiver um banco de dados PostgreSQL em execução, a porta 5432 estará ativa e detectando. Para o SSH, será a porta 22.

Atividade de todas as portas locais

Use o comando netstat para ver a atividade de todas as portas locais. Por exemplo, netstat -lt mostra todas as portas ativas no momento.

Conectar-se ao host remoto usando telnet

Para verificar se é possível se conectar ao host remoto usando TCP, execute o comando telnet. O telnet tenta se conectar ao endereço IP e à porta fornecidos por você.

Se o host remoto estiver executando um banco de dados PostgreSQL, por exemplo, será possível usar o telnet nele na porta 5432: telnet 35.193.198.159 5432.

Se o processo for bem-sucedido, você verá o seguinte: 

Trying 35.193.198.159...
Connected to 35.193.198.159.

Em caso de falha, você verá que telnet para de responder até que você force o encerramento da tentativa: 

Trying 35.193.198.159...
^C

Autenticação do cliente

A autenticação do cliente é controlada por um arquivo de configuração, chamado pg_hba.conf (HBA significa autenticação baseada em host).

Verifique se a seção de conexões de replicação do arquivo pg_hba.conf no banco de dados de origem está atualizada para aceitar conexões do intervalo de endereços IP da VPC do Cloud SQL.

Cloud Logging

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

Como visualizar registros

É possível ver os registros das instâncias do Cloud SQL e de outros projetos do Google Cloud, como as instâncias do Cloud VPN ou do Compute Engine. Para ver as entradas de registro da instância do Cloud SQL, faça o seguinte:

Console

  1. Acessar a Análise de registros.
  2. Selecione um projeto do Cloud SQL na parte superior da página.
  3. No criador de consultas, adicione o seguinte:
    • Recurso: selecione Banco de dados do Cloud SQL. Na caixa de diálogo, selecione uma instância do Cloud SQL.
    • Nomes de registros: vá até a seção do Cloud SQL e selecione os arquivos de registro correspondentes à instância. Exemplo:
      • cloudsql.googleapis.com/postgres.log
    • Gravidade: selecione um nível de registro.
    • Período: selecione um valor predefinido ou crie um período personalizado.

gcloud

Use o comando gcloud logging para visualizar as entradas de registro. No exemplo abaixo, substitua PROJECT_ID. A sinalização limité um parâmetro opcional que indica o número máximo de entradas a seremretornadas.

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

Endereços IP particulares

As conexões com uma instância do Cloud SQL usando 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 precisam ser configurados no Cloud SQL como redes autorizadas. É necessário atualizar o peering de rede para o Cloud SQL exportar rotas que não sejam RFC 1918. Exemplo: gcloud compute networks peerings update cloudsql-postgres-googleapis-com --network=NETWORK --export-subnet-routes-with-public-ip --project=PROJECT

O intervalo de IP 172.17.0.0/16 é reservado para a rede de ponte do Docker. As instâncias do Cloud SQL criadas com um endereço IP nesse intervalo ficarão inacessíveis. As conexões vindas de qualquer endereço IP dentro desse intervalo para instâncias do Cloud SQL que usam endereço IP particular falharão.

Solução de problemas de VPN

Consulte a página Google Cloud Solução de problemas do Cloud VPN.

Solução de problemas de túnel SSH reverso

O tunelamento SSH é um método para encaminhar algumas comunicações por uma conexão SSH. O túnel SSH reverso permite configurar um túnel SSH, mas mantém a rede de destino como aquela que inicia a conexão do túnel. Isso é útil quando você não quer abrir uma porta na sua rede por motivos de segurança.

O que você está tentando fazer é configurar o seguinte:

Cloud SQL DB ---> Compute Engine VM bastion ---> tunnel ---> source network bastion ---> source DB

Presume-se que:

  • O Compute Engine VM bastion pode acessar o Cloud SQL DB.

  • O source network bastion pode acessar o source DB (isso é feito por meio do peering da rede do Cloud SQL com a rede da VM do Compute Engine).

Em seguida, configure um túnel SSH do source network bastion para o Compute Engine VM bastion, que encaminha todas as conexões de entrada para alguma porta no Compute Engine VM bastion pelo 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 por um:

source network bastion ---> source DB

  1. Conecte-se ao source network bastion usando SSH ou pelo terminal, se for a máquina local.
  2. Teste a conectividade com o banco de dados de origem usando um dos seguintes métodos:
    • telnet [source_db_host_or_ip] [source_db_port]: as strings de conexão telnet vão aparecer, terminando com Connected to x.x.x.x.
    • psql -h [source_db_host_or_ip] -p [source_db_port] -U [username] -d [database_name]: você verá uma solicitação de senha ou uma mensagem de acesso negado.

Se isso falhar, verifique se você ativou o acesso desse bastion ao banco de dados de origem.

Compute Engine VM bastion ---> source DB

  1. Conecte-se por SSH ao Compute Engine VM bastion (usando gcloud compute ssh VM_INSTANCE_NAME).
  2. Teste a conectividade com o banco de dados de origem usando um dos seguintes métodos:
    • telnet 127.0.0.1 [tunnel_port]: as strings de conexão telnet vão aparecer, terminando com Connected to x.x.x.x.
    • psql -h 127.0.0.1 -p [tunnel_port] -U [username] -d [database_name]: você verá uma solicitação de senha ou uma mensagem de acesso negado.

Se isso falhar, verifique se o túnel está funcionando corretamente. A execução de sudo netstat -tupln mostra todos os processos de detecção nessa VM, e você verá sshd listening on the tunnel_port.

Cloud SQL DB ---> source DB

A melhor maneira de testar isso é testing the migration job do Database Migration Service. Se isso falhar, significa que há algum problema com o peering de VPC ou o roteamento entre a rede do Cloud SQL e a rede Compute Engine VM bastion.

O firewall do servidor de banco de dados de origem precisa ser configurado para permitir todo o intervalo de IPs interno alocado para a conexão de serviço particular da rede VPC que o destino do Cloud SQL usará como o campo privateNetwork de suas configurações de ipConfiguration.

Para encontrar o intervalo de IP interno no console:

  1. Acesse a página "Redes VPC" no console do Google Cloud .
  2. Selecione a rede VPC que você quer usar.
  3. Selecione Acesso a serviços particulares > Intervalos de IP alocados para serviços.
  4. Encontre o Intervalo de IP interno associado à conexão criada por servicenetworking-googleapis-com.

Também é possível ver o tráfego entre a instância do Cloud SQL e a instância de VM do Compute Engine no console do Cloud Logging no projeto Cloud VPN gateway. Nos registros da VM do Compute Engine, procure o tráfego vindo da instância do Cloud SQL. Nos registros da instância do Cloud SQL, procure o tráfego da VM do Compute Engine.