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

O 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 de destino usam para se comunicar (o endereço IP de saída), siga estas etapas:

1. Acesse a página Clusters no console do Google Cloud :

   Acessar os clusters do AlloyDB para PostgreSQL

2. Localize o cluster do AlloyDB para PostgreSQL associado ao job de migração que você está depurando.
3. Os dois endereços IP públicos de saída aparecem nos detalhes da instância principal do cluster.

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 AlloyDB para PostgreSQL.

Cloud Logging

O Database Migration Service e o AlloyDB para PostgreSQL usam o Cloud Logging. Consulte a documentação do Cloud Logging para informações completas.

Como visualizar registros

É possível ver os registros das instâncias do AlloyDB para PostgreSQL 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 AlloyDB para PostgreSQL, faça o seguinte:

Console

1. Acessar a Análise de registros.
2. Selecione o projeto do AlloyDB para PostgreSQL na parte de cima da página.
3. No criador de consultas, adicione o seguinte:
   • Recurso: selecione Instância do AlloyDB para PostgreSQL. Na caixa de diálogo, selecione sua instância do AlloyDB para PostgreSQL.
   • Nomes de registros: vá até a seção do AlloyDB para PostgreSQL e selecione os arquivos de registro correspondentes à instância. Exemplo:
     • alloydb.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/alloydb.googleapis.com%2Fpostgres.log" --limit=10

Endereços IP particulares

As conexões com um cluster do AlloyDB para PostgreSQL usando um endereço IP privado são autorizadas para intervalos de endereços RFC 1918. Se a rede usa intervalos de endereços não RFC 1918, é necessário atualizar o peering de rede para exportar rotas que não sejam RFC 1918. Por exemplo: gcloud compute networks peerings update servicenetworking-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 conexões de qualquer endereço IP dentro desse intervalo para clusters do AlloyDB para PostgreSQL que usam um endereço IP particular vão falhar.

Solução de problemas de VPN

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

Resolver problemas de proxy TCP

A forma como o proxy TCP é configurado também pode causar erros. Para resolver problemas de um erro de proxy TCP, confira os seguintes exemplos de problemas e como eles podem ser resolvidos:

Falha ao iniciar a máquina virtual (VM)

A seguinte mensagem é exibida ao iniciar a instância de VM no Compute Engine:

You do not currently have an active account selected.

O que você pode tentar fazer

Execute um dos seguintes comandos para configurar uma conta ativa:

• Para receber novas credenciais, execute o seguinte comando:

  gcloud auth login
  

• Para selecionar uma conta já autenticada, execute o seguinte comando:

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

  Substitua ACCOUNT pelo nome da conta que você quer configurar.

Falha ao se conectar à instância do banco de dados de origem

Você verá a seguinte mensagem de erro ao testar o job de migração:

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

O que você pode tentar fazer

Siga as etapas abaixo para entender onde pode estar o problema:

1. Verifique se a VM que hospeda o contêiner de proxy TCP está em execução:
   1. No console do Google Cloud , acesse a página Instâncias de VM do Compute Engine.

      Acessar instâncias de VM

   2. Pesquise a VM que foi criada como parte do processo de configuração do proxy. Se ele não estiver listado ou não estiver em execução, configure o proxy TCP do zero e atualize as configurações do perfil de conexão de origem no job de migração com o endereço IP correto.
2. Se a VM estiver em execução, verifique se não houve erro ao fazer o download da imagem do contêiner do proxy TCP:
   1. Selecione a VM que foi criada como parte do processo de configuração do proxy TCP. Em Registros, clique em Porta serial 1 (console).
   2. Se você não conseguir ver a entrada Launching user container 'gcr.io/dms-images/tcp-proxy' nos registros, talvez o problema seja que sua instância não conseguiu extrair a imagem do Container Registry. Para verificar se esse é o caso, conecte-se à VM e tente extrair manualmente a imagem do Container Registry usando o seguinte comando:

      docker pull gcr.io/dms-images/tcp-proxy

      Se você receber o erro Error response from daemon: Get "https://gcr.io/v2/": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers), significa que a VM não conseguiu se conectar ao Container Registry. Se a VM tiver apenas um endereço IP particular, será necessário ativar o Acesso privado do Google na sub-rede de que o endereço IP faz parte. Caso contrário, a VM não terá acesso às APIs do Google Enterprise, como o Container Registry.

3. Verifique se o contêiner pode se conectar à instância de origem:
   1. Selecione a VM que foi criada como parte do processo de configuração do proxy. Em Registros, clique em Cloud Logging.
   2. Se você receber a seguinte mensagem: Connection refused, please verify that the machine you are using to run the script can connect to the source database at, isso significa que o contêiner do proxy TCP não conseguiu se conectar à instância do banco de dados de origem. Isso pode acontecer por vários motivos:
      • O endereço IP da instância de origem está incorreto.
      • Há uma política de firewall que recusa conexões do proxy TCP com a instância de origem.
      • A instância de origem está em uma rede de nuvem privada virtual (VPC) diferente da VM que hospeda o proxy TCP.

   É possível depurar o problema de conectividade usando os testes de conectividade do Google Cloud para garantir que haja conectividade entre a VM que hospeda o proxy TCP e o banco de dados de origem:

   1. No console do Google Cloud , acesse a página Testes de conectividade.

      Testes de conectividade

   2. Clique em Criar testes de conectividade.
   3. Insira um nome para o teste.
   4. Selecione TCP como o protocolo.
   5. Selecione Endereço IP na lista Endpoint de origem. Insira o endereço IP público do proxy TCP recém-criado se o banco de dados de origem puder ser acessado usando um endereço IP público. Caso contrário, insira o endereço IP particular do proxy TCP.
   6. Selecione Endereço IP na lista Endpoint de destino e insira o endereço IP do banco de dados de origem.
   7. No campo Porta de destino, insira o número da porta usado para se conectar ao banco de dados de origem.
   8. Clique em Criar.

   Execute o teste de conectividade e resolva os problemas que surgirem. Depois de corrigir o problema de conectividade, verifique se o proxy TCP pode se conectar à instância de origem:

   1. Acesse Instâncias de VM no Compute Engine.

      Acessar instâncias de VM

   2. Selecione a VM que foi criada como parte do processo de configuração do proxy. Em Registros, clique em Cloud Logging.
   3. Se você encontrar a entrada de registro Connection to source DB verified, isso significa que o proxy TCP agora pode se conectar à instância de origem.
4. Verifique se o teste de migração não está falhando devido a problemas de conexão.

Falha ao se conectar ao cluster do banco de dados de destino

Se o contêiner de proxy TCP puder se conectar à instância de origem, mas o teste de migração ainda estiver falhando devido a problemas de conexão, o problema pode ser a conectividade entre o cluster de destino do AlloyDB para PostgreSQL e a VM que hospeda o contêiner de proxy TCP.

Depurar o problema

Para depurar o problema, use os Google Cloud Testes de conectividade para garantir que haja conectividade entre o cluster de destino do AlloyDB para PostgreSQL e a VM que hospeda o proxy TCP:

1. No console do Google Cloud , acesse a página Testes de conectividade.

   Testes de conectividade

2. Clique em Criar testes de conectividade.
3. Defina os seguintes parâmetros para o teste:
   1. Insira um nome para o teste.
   2. Selecione TCP como o protocolo.
   3. Selecione Endereço IP na lista Endpoint de origem e insira o endereço IP do cluster do AlloyDB para PostgreSQL recém-criado.
   4. Selecione Endereço IP na lista Endpoint de destino e insira o endereço IP particular do proxy TCP.
   5. Insira 5432 no campo Porta de destino.
4. Clique em Criar.
5. Execute o teste de conectividade e resolva os problemas que surgirem.

Causas possíveis

Há uma regra de firewall que nega a comunicação entre o cluster de destino e a VM de proxy TCP.

O que você pode tentar fazer

Adicione uma regra de firewall que permita que o cluster de destino se comunique com o proxy TCP usando a porta 5432.

Causas possíveis

Há uma incompatibilidade de VPC entre o cluster de destino e a VM que executa o contêiner de proxy TCP.

O que você pode tentar fazer

Selecione a mesma VPC para o cluster de destino.

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, mantendo 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:

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

Observação: embora o Database Migration Service migre dados de uma origem para um destino, é necessário ativar a conectividade do destino para a origem.

Presume-se que:

• O AlloyDB for PostgreSQL cluster pode acessar o Compute Engine VM bastion (isso é feito por meio do peering da rede do AlloyDB para PostgreSQL com a rede da VM do Compute Engine).

• O source network bastion pode acessar o source DB.

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, 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, 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.

AlloyDB for PostgreSQL cluster ---> 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 AlloyDB para PostgreSQL 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 cluster de destino do AlloyDB para PostgreSQL usa.

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 o cluster do AlloyDB para PostgreSQL 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 do cluster do AlloyDB para PostgreSQL. Nos registros do cluster do AlloyDB para PostgreSQL, procure o tráfego da VM do Compute Engine.