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 a comunicação entre eles falha, como você pode descobrir o que deu errado e onde?
As ferramentas mais básicas são ping e traceroute .
Pingar
Ping realiza um teste básico para determinar se o destino ("host remoto") está disponível na origem. Ping envia um pacote ICMP Echo Request para um host remoto e espera uma ICMP Echo Reply em troca. Se ping não for bem-sucedido, não haverá rota da origem até o destino. Sucesso, entretanto, não significa que seus pacotes possam 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 há garantia de que seja confiável. Alguns provedores de rede bloqueiam ICMP como medida de segurança, o que pode dificultar a depuração da conectividade.
Trace rota
Traceroute testa a rota completa que os pacotes de rede levam de um host para outro. Ele mostra todas as etapas ("saltos") que o pacote percorre ao longo do caminho e quanto tempo leva cada etapa. Se o pacote não percorrer todo o caminho até o destino, traceroute não será concluído, mas terminará com uma série de asteriscos. Neste caso, procure o último endereço IP que foi alcançado com sucesso ao longo do caminho. Foi aqui que a conectividade foi interrompida.
Traceroute pode expirar. Ele também pode falhar na conclusão se um gateway ao longo do caminho não estiver configurado corretamente para passar o pacote para o próximo salto.
Quando traceroute não for concluído, você poderá descobrir onde ele parou. Encontre o último endereço IP listado na saída traceroute e faça uma pesquisa no navegador para saber who owns [IP_ADDRESS] . Os resultados podem ou não mostrar o proprietário do endereço, mas vale a pena tentar.
metrô
A ferramenta mtr é uma forma de traceroute que permanece ativa e continuamente atualizada, semelhante à forma como o comando top funciona para processos locais.
Localize seu endereço IP local
Se você não souber o endereço local do seu host, execute o comando ip -br address show . No Linux, 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 .
Alternativamente, você pode executar ipconfig ou ifconfig para ver o status de suas interfaces de rede.
Localize 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 comunicarem entre si (o endereço IP de saída), conclua as etapas a seguir:
Vá para a página Instâncias SQL no Google Cloud console.
Clique no nome da instância associada ao trabalho de migração que você está depurando.
Role para baixo até que o painel Conectar a esta instância seja exibido. Neste painel, o endereço IP de saída aparece.
Abra portas locais
Para verificar se o seu host está escutando nas portas que você pensa, execute o comando ss -tunlp4 . Isso informa quais portas estão abertas e escutando. Por exemplo, se você tiver um banco de dados PostgreSQL em execução, a porta 5432 deverá estar ativa e escutando. Para SSH, você deverá ver a porta 22.
Todas as atividades portuárias locais
Use o comando netstat para ver toda a atividade da porta local. Por exemplo, netstat -lt mostra todas as portas atualmente ativas.
Conecte-se ao host remoto usando telnet
Para verificar se você pode se conectar ao host remoto usando TCP , execute o comando telnet . O Telnet tenta se conectar ao endereço IP e à porta que você forneceu.
telnet 35.193.198.159 5432 .Em caso de sucesso, você verá o seguinte: Trying 35.193.198.159...
Conectado a 35.193.198.159. .
Em caso de falha, você verá que telnet para de responder até você forçar o fechamento da tentativa: Trying 35.193.198.159...
^ C. .
Autenticação de cliente
A autenticação do cliente é controlada por um arquivo de configuração denominado 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.
Registro em nuvem
O serviço de migração de banco de dados e o Cloud SQL usam o Cloud Logging. Consulte a documentação do Cloud Logging para obter informações completas e revise os exemplos de consultas do Cloud SQL .Ver registros
Você pode visualizar registros de instâncias do Cloud SQL e outros Google Cloudprojetos como instâncias do Cloud VPN ou do Compute Engine. Para visualizar os registros das entradas de registro da instância do Cloud SQL:Console
- Acesse o Explorador de registros
- Selecione um projeto existente do Cloud SQL na parte superior da página.
- No construtor de consultas, adicione o seguinte:
- Recurso: selecione banco de dados Cloud SQL . Na caixa de diálogo, selecione uma instância do Cloud SQL.
- Nomes de log: role até a seção Cloud SQL e selecione os arquivos de log apropriados para sua instância. Por exemplo:
- cloudsql.googleapis.com/postgres.log
- Gravidade: selecione um nível de log.
- Intervalo de tempo: selecione uma predefinição ou crie um intervalo personalizado.
gcloud
Use o comando gcloud logging para visualizar entradas de registro. No exemplo abaixo, substitua PROJECT_ID . O sinalizador limit é um parâmetro opcional que indica o número máximo de entradas a serem retornadas.
gcloud logging read "projects/[PROJECT_ID]/logs/cloudsql.googleapis.com/postgres.log" --limit=10
Endereços IP privados
As conexões com uma instância do Cloud SQL usando um endereço IP privado são automaticamente autorizadas 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 . Você também precisa atualizar o peering de rede para o Cloud SQL para exportar rotas não RFC 1918. Por 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 está reservado para a rede Docker Bridge. Qualquer instância do Cloud SQL criada com um endereço IP nesse intervalo ficará inacessível. As conexões de qualquer endereço IP nesse intervalo com instâncias do Cloud SQL que usam endereços IP privados falharão.
Solução de problemas de VPN
Veja oGoogle Cloud Página de solução de problemas do Cloud VPN .
Solução de problemas de túnel SSH reverso
O tunelamento SSH é um método para encaminhar alguma comunicação sobre uma conexão SSH. O tunelamento SSH reverso permite configurar um túnel SSH, mas mantendo que a rede de destino é aquela que inicia a conexão do túnel. Isto é útil quando você não deseja abrir uma porta em sua própria rede por motivos de segurança.
O que você está tentando alcançar é configurar o seguinte: Cloud SQL DB ---> Compute Engine VM bastion ---> tunnel ---> source network bastion ---> source DB
Supõe-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, você configura um túnel SSH do source network bastion para o Compute Engine VM bastion , que roteia todas as conexões de entrada para alguma porta no Compute Engine VM bastion através do túnel até o source DB .
Cada link no cenário acima pode ser configurado incorretamente e impedir o funcionamento de todo o fluxo. Solucione problemas de cada link, um por um:
source network bastion ---> source DB
- Conecte-se ao source network bastion usando SSH ou a partir do terminal, se for a máquina local.
- 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]- espere ver as strings de conexão telnet, terminando comConnected to xxxx. -
[db_client] -h[source_db_host_or_ip] -P[source_db_port]- espere ver o acesso negado
-
Se isso falhar, será necessário verificar se você ativou o acesso deste bastião ao banco de dados de origem.
Compute Engine VM bastion ---> source DB
- SSH para o Compute Engine VM bastion (usando
gcloud compute ssh VM_INSTANCE_NAME) - Teste a conectividade com o banco de dados de origem usando um dos seguintes métodos:
-
telnet 127.0.0.1 [tunnel_port]- espere ver as strings de conexão telnet, terminando comConnected to xxxx. -
[db_client] -h127.0.0.1 -P[tunnel_port]- espere ver o acesso negado
-
Se isso falhar, será necessário verificar se o túnel está funcionando corretamente. A execução sudo netstat -tupln mostra todos os processos de escuta nesta VM e você deverá ver sshd listening on the tunnel_port .
Cloud SQL DB ---> source DB
Isso é melhor testado testing the migration job do Database Migration Service. Se isso falhar, significa que há algum problema com peering ou roteamento de VPC entre a rede do Cloud SQL e a rede Compute Engine VM bastion .
O firewall do servidor de banco de dados de origem deve ser configurado para permitir todo o intervalo de IP interno alocado para a conexão de serviço privado da rede VPC que a instância de destino do Cloud SQL usará como o campo privateNetwork de suas configurações ipConfiguration .
Para encontrar o intervalo de IP interno no console:
Acesse a página de redes VPC no Google Cloud console.
Selecione a rede VPC que você deseja usar.
Selecione a guia CONEXÃO DE SERVIÇO PRIVADO .
Você também pode visualizar 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 proveniente da instância do Cloud SQL. Nos registros da instância do Cloud SQL, procure o tráfego da VM do Compute Engine.
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 a comunicação entre eles falha, como você pode descobrir o que deu errado e onde?
As ferramentas mais básicas são ping e traceroute .
Pingar
Ping realiza um teste básico para determinar se o destino ("host remoto") está disponível na origem. Ping envia um pacote ICMP Echo Request para um host remoto e espera uma ICMP Echo Reply em troca. Se ping não for bem-sucedido, não haverá rota da origem até o destino. Sucesso, entretanto, não significa que seus pacotes possam 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 há garantia de que seja confiável. Alguns provedores de rede bloqueiam ICMP como medida de segurança, o que pode dificultar a depuração da conectividade.
Trace rota
Traceroute testa a rota completa que os pacotes de rede levam de um host para outro. Ele mostra todas as etapas ("saltos") que o pacote percorre ao longo do caminho e quanto tempo leva cada etapa. Se o pacote não percorrer todo o caminho até o destino, traceroute não será concluído, mas terminará com uma série de asteriscos. Neste caso, procure o último endereço IP que foi alcançado com sucesso ao longo do caminho. Foi aqui que a conectividade foi interrompida.
Traceroute pode expirar. Ele também pode falhar na conclusão se um gateway ao longo do caminho não estiver configurado corretamente para passar o pacote para o próximo salto.
Quando traceroute não for concluído, você poderá descobrir onde ele parou. Encontre o último endereço IP listado na saída traceroute e faça uma pesquisa no navegador para saber who owns [IP_ADDRESS] . Os resultados podem ou não mostrar o proprietário do endereço, mas vale a pena tentar.
metrô
A ferramenta mtr é uma forma de traceroute que permanece ativa e continuamente atualizada, semelhante à forma como o comando top funciona para processos locais.
Localize seu endereço IP local
Se você não souber o endereço local do seu host, execute o comando ip -br address show . No Linux, 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 .
Alternativamente, você pode executar ipconfig ou ifconfig para ver o status de suas interfaces de rede.
Localize 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 comunicarem entre si (o endereço IP de saída), conclua as etapas a seguir:
Vá para a página Instâncias SQL no Google Cloud console.
Clique no nome da instância associada ao trabalho de migração que você está depurando.
Role para baixo até que o painel Conectar a esta instância seja exibido. Neste painel, o endereço IP de saída aparece.
Abra portas locais
Para verificar se o seu host está escutando nas portas que você pensa, execute o comando ss -tunlp4 . Isso informa quais portas estão abertas e escutando. Por exemplo, se você tiver um banco de dados PostgreSQL em execução, a porta 5432 deverá estar ativa e escutando. Para SSH, você deverá ver a porta 22.
Todas as atividades portuárias locais
Use o comando netstat para ver toda a atividade da porta local. Por exemplo, netstat -lt mostra todas as portas atualmente ativas.
Conecte-se ao host remoto usando telnet
Para verificar se você pode se conectar ao host remoto usando TCP , execute o comando telnet . O Telnet tenta se conectar ao endereço IP e à porta que você forneceu.
telnet 35.193.198.159 5432 .Em caso de sucesso, você verá o seguinte: Trying 35.193.198.159...
Conectado a 35.193.198.159. .
Em caso de falha, você verá que telnet para de responder até você forçar o fechamento da tentativa: Trying 35.193.198.159...
^ C. .
Autenticação de cliente
A autenticação do cliente é controlada por um arquivo de configuração denominado 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.
Registro em nuvem
O serviço de migração de banco de dados e o Cloud SQL usam o Cloud Logging. Consulte a documentação do Cloud Logging para obter informações completas e revise os exemplos de consultas do Cloud SQL .Ver registros
Você pode visualizar registros de instâncias do Cloud SQL e outros Google Cloudprojetos como instâncias do Cloud VPN ou do Compute Engine. Para visualizar os registros das entradas de registro da instância do Cloud SQL:Console
- Acesse o Explorador de registros
- Selecione um projeto existente do Cloud SQL na parte superior da página.
- No construtor de consultas, adicione o seguinte:
- Recurso: selecione banco de dados Cloud SQL . Na caixa de diálogo, selecione uma instância do Cloud SQL.
- Nomes de log: vá até a seção Cloud SQL e selecione os arquivos de log apropriados para sua instância. Por exemplo:
- cloudsql.googleapis.com/postgres.log
- Gravidade: selecione um nível de log.
- Intervalo de tempo: selecione uma predefinição ou crie um intervalo personalizado.
gcloud
Use o comando gcloud logging para visualizar entradas de registro. No exemplo abaixo, substitua PROJECT_ID . O sinalizador limit é um parâmetro opcional que indica o número máximo de entradas a serem retornadas.
gcloud logging read "projects/[PROJECT_ID]/logs/cloudsql.googleapis.com/postgres.log" --limit=10
Endereços IP privados
As conexões com uma instância do Cloud SQL usando um endereço IP privado são automaticamente autorizadas 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 . Você também precisa atualizar o peering de rede para o Cloud SQL para exportar rotas não RFC 1918. Por 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 está reservado para a rede Docker Bridge. Qualquer instância do Cloud SQL criada com um endereço IP nesse intervalo ficará inacessível. As conexões de qualquer endereço IP nesse intervalo com instâncias do Cloud SQL que usam endereços IP privados falharão.
Solução de problemas de VPN
Veja oGoogle Cloud Página de solução de problemas do Cloud VPN .
Solução de problemas de túnel SSH reverso
O tunelamento SSH é um método para encaminhar alguma comunicação sobre uma conexão SSH. O tunelamento SSH reverso permite configurar um túnel SSH, mas mantendo que a rede de destino é aquela que inicia a conexão do túnel. Isto é útil quando você não deseja abrir uma porta em sua própria rede por motivos de segurança.
O que você está tentando alcançar é configurar o seguinte: Cloud SQL DB ---> Compute Engine VM bastion ---> tunnel ---> source network bastion ---> source DB
Supõe-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, você configura um túnel SSH do source network bastion para o Compute Engine VM bastion , que roteia todas as conexões de entrada para alguma porta no Compute Engine VM bastion através do túnel até o source DB .
Cada link no cenário acima pode ser configurado incorretamente e impedir o funcionamento de todo o fluxo. Solucione problemas de cada link, um por um:
source network bastion ---> source DB
- Conecte-se ao source network bastion usando SSH ou a partir do terminal, se for a máquina local.
- 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]- espere ver as strings de conexão telnet, terminando comConnected to xxxx. -
[db_client] -h[source_db_host_or_ip] -P[source_db_port]- espere ver o acesso negado
-
Se isso falhar, será necessário verificar se você ativou o acesso deste bastião ao banco de dados de origem.
Compute Engine VM bastion ---> source DB
- SSH para o Compute Engine VM bastion (usando
gcloud compute ssh VM_INSTANCE_NAME) - Teste a conectividade com o banco de dados de origem usando um dos seguintes métodos:
-
telnet 127.0.0.1 [tunnel_port]- espere ver as strings de conexão telnet, terminando comConnected to xxxx. -
[db_client] -h127.0.0.1 -P[tunnel_port]- espere ver o acesso negado
-
Se isso falhar, será necessário verificar se o túnel está funcionando corretamente. A execução sudo netstat -tupln mostra todos os processos de escuta nesta VM e você deverá ver sshd listening on the tunnel_port .
Cloud SQL DB ---> source DB
Isso é melhor testado testing the migration job do Database Migration Service. Se isso falhar, significa que há algum problema com peering ou roteamento de VPC entre a rede do Cloud SQL e a rede Compute Engine VM bastion .
O firewall do servidor de banco de dados de origem deve ser configurado para permitir todo o intervalo de IP interno alocado para a conexão de serviço privado da rede VPC que a instância de destino do Cloud SQL usará como o campo privateNetwork de suas configurações ipConfiguration .
Para encontrar o intervalo de IP interno no console:
Acesse a página de redes VPC no Google Cloud console.
Selecione a rede VPC que você deseja usar.
Selecione a guia CONEXÃO DE SERVIÇO PRIVADO .
Você também pode visualizar 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 proveniente da instância do Cloud SQL. Nos registros da instância do Cloud SQL, procure o tráfego da VM do Compute Engine.
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 a comunicação entre eles falha, como você pode descobrir o que deu errado e onde?
As ferramentas mais básicas são ping e traceroute .
Pingar
Ping realiza um teste básico para determinar se o destino ("host remoto") está disponível na origem. Ping envia um pacote ICMP Echo Request para um host remoto e espera uma ICMP Echo Reply em troca. Se ping não for bem-sucedido, não haverá rota da origem até o destino. Sucesso, entretanto, não significa que seus pacotes possam 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 há garantia de que seja confiável. Alguns provedores de rede bloqueiam ICMP como medida de segurança, o que pode dificultar a depuração da conectividade.
Trace rota
Traceroute testa a rota completa que os pacotes de rede levam de um host para outro. Ele mostra todas as etapas ("saltos") que o pacote percorre ao longo do caminho e quanto tempo leva cada etapa. Se o pacote não percorrer todo o caminho até o destino, traceroute não será concluído, mas terminará com uma série de asteriscos. Neste caso, procure o último endereço IP que foi alcançado com sucesso ao longo do caminho. Foi aqui que a conectividade foi interrompida.
Traceroute pode expirar. Ele também pode falhar na conclusão se um gateway ao longo do caminho não estiver configurado corretamente para passar o pacote para o próximo salto.
Quando traceroute não for concluído, você poderá descobrir onde ele parou. Encontre o último endereço IP listado na saída traceroute e faça uma pesquisa no navegador para saber who owns [IP_ADDRESS] . Os resultados podem ou não mostrar o proprietário do endereço, mas vale a pena tentar.
metrô
A ferramenta mtr é uma forma de traceroute que permanece ativa e continuamente atualizada, semelhante à forma como o comando top funciona para processos locais.
Localize seu endereço IP local
Se você não souber o endereço local do seu host, execute o comando ip -br address show . No Linux, 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 .
Alternativamente, você pode executar ipconfig ou ifconfig para ver o status de suas interfaces de rede.
Localize 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 comunicarem entre si (o endereço IP de saída), conclua as etapas a seguir:
Vá para a página Instâncias SQL no Google Cloud console.
Clique no nome da instância associada ao trabalho de migração que você está depurando.
Role para baixo até que o painel Conectar a esta instância seja exibido. Neste painel, o endereço IP de saída aparece.
Abra portas locais
Para verificar se o seu host está escutando nas portas que você pensa, execute o comando ss -tunlp4 . Isso informa quais portas estão abertas e escutando. Por exemplo, se você tiver um banco de dados PostgreSQL em execução, a porta 5432 deverá estar ativa e escutando. Para SSH, você deverá ver a porta 22.
Todas as atividades portuárias locais
Use o comando netstat para ver toda a atividade da porta local. Por exemplo, netstat -lt mostra todas as portas atualmente ativas.
Conecte-se ao host remoto usando telnet
Para verificar se você pode se conectar ao host remoto usando TCP , execute o comando telnet . O Telnet tenta se conectar ao endereço IP e à porta que você forneceu.
telnet 35.193.198.159 5432 .Em caso de sucesso, você verá o seguinte: Trying 35.193.198.159...
Conectado a 35.193.198.159. .
Em caso de falha, você verá que telnet para de responder até você forçar o fechamento da tentativa: Trying 35.193.198.159...
^ C. .
Autenticação de cliente
A autenticação do cliente é controlada por um arquivo de configuração denominado 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.
Registro em nuvem
O serviço de migração de banco de dados e o Cloud SQL usam o Cloud Logging. Consulte a documentação do Cloud Logging para obter informações completas e revise os exemplos de consultas do Cloud SQL .Ver registros
Você pode visualizar registros de instâncias do Cloud SQL e outros Google Cloudprojetos como instâncias do Cloud VPN ou do Compute Engine. Para visualizar os registros das entradas de registro da instância do Cloud SQL:Console
- Acesse o Explorador de registros
- Selecione um projeto existente do Cloud SQL na parte superior da página.
- No construtor de consultas, adicione o seguinte:
- Recurso: selecione banco de dados Cloud SQL . Na caixa de diálogo, selecione uma instância do Cloud SQL.
- Nomes de log: vá até a seção Cloud SQL e selecione os arquivos de log apropriados para sua instância. Por exemplo:
- cloudsql.googleapis.com/postgres.log
- Gravidade: selecione um nível de log.
- Intervalo de tempo: selecione uma predefinição ou crie um intervalo personalizado.
gcloud
Use o comando gcloud logging para visualizar entradas de registro. No exemplo abaixo, substitua PROJECT_ID . O sinalizador limit é um parâmetro opcional que indica o número máximo de entradas a serem retornadas.
gcloud logging read "projects/[PROJECT_ID]/logs/cloudsql.googleapis.com/postgres.log" --limit=10
Endereços IP privados
As conexões com uma instância do Cloud SQL usando um endereço IP privado são automaticamente autorizadas 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 . Você também precisa atualizar o peering de rede para o Cloud SQL para exportar rotas não RFC 1918. Por 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 está reservado para a rede Docker Bridge. Qualquer instância do Cloud SQL criada com um endereço IP nesse intervalo ficará inacessível. As conexões de qualquer endereço IP nesse intervalo com instâncias do Cloud SQL que usam endereços IP privados falharão.
Solução de problemas de VPN
Veja oGoogle Cloud Página de solução de problemas do Cloud VPN .
Solução de problemas de túnel SSH reverso
O tunelamento SSH é um método para encaminhar alguma comunicação sobre uma conexão SSH. O tunelamento SSH reverso permite configurar um túnel SSH, mas mantendo que a rede de destino é aquela que inicia a conexão do túnel. Isto é útil quando você não deseja abrir uma porta em sua própria rede por motivos de segurança.
O que você está tentando alcançar é configurar o seguinte: Cloud SQL DB ---> Compute Engine VM bastion ---> tunnel ---> source network bastion ---> source DB
Supõe-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, você configura um túnel SSH do source network bastion para o Compute Engine VM bastion , que roteia todas as conexões de entrada para alguma porta no Compute Engine VM bastion através do túnel até o source DB .
Cada link no cenário acima pode ser configurado incorretamente e impedir o funcionamento de todo o fluxo. Solucione problemas de cada link, um por um:
source network bastion ---> source DB
- Conecte-se ao source network bastion usando SSH ou a partir do terminal, se for a máquina local.
- 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]- espere ver as strings de conexão telnet, terminando comConnected to xxxx. -
[db_client] -h[source_db_host_or_ip] -P[source_db_port]- espere ver o acesso negado
-
Se isso falhar, será necessário verificar se você ativou o acesso deste bastião ao banco de dados de origem.
Compute Engine VM bastion ---> source DB
- SSH para o Compute Engine VM bastion (usando
gcloud compute ssh VM_INSTANCE_NAME) - Teste a conectividade com o banco de dados de origem usando um dos seguintes métodos:
-
telnet 127.0.0.1 [tunnel_port]- espere ver as strings de conexão telnet, terminando comConnected to xxxx. -
[db_client] -h127.0.0.1 -P[tunnel_port]- espere ver o acesso negado
-
Se isso falhar, será necessário verificar se o túnel está funcionando corretamente. A execução sudo netstat -tupln mostra todos os processos de escuta nesta VM e você deverá ver sshd listening on the tunnel_port .
Cloud SQL DB ---> source DB
Isso é melhor testado testing the migration job do Database Migration Service. Se isso falhar, significa que há algum problema com peering ou roteamento de VPC entre a rede do Cloud SQL e a rede Compute Engine VM bastion .
O firewall do servidor de banco de dados de origem deve ser configurado para permitir todo o intervalo de IP interno alocado para a conexão de serviço privado da rede VPC que a instância de destino do Cloud SQL usará como o campo privateNetwork de suas configurações ipConfiguration .
Para encontrar o intervalo de IP interno no console:
Acesse a página de redes VPC no Google Cloud console.
Selecione a rede VPC que você deseja usar.
Selecione a guia CONEXÃO DE SERVIÇO PRIVADO .
Você também pode visualizar 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 proveniente da instância do Cloud SQL. Nos registros da instância do Cloud SQL, procure o tráfego da VM do Compute Engine.
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 a comunicação entre eles falha, como você pode descobrir o que deu errado e onde?
As ferramentas mais básicas são ping e traceroute .
Pingar
Ping realiza um teste básico para determinar se o destino ("host remoto") está disponível na origem. Ping envia um pacote ICMP Echo Request para um host remoto e espera uma ICMP Echo Reply em troca. Se ping não for bem-sucedido, não haverá rota da origem até o destino. Sucesso, entretanto, não significa que seus pacotes possam 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 há garantia de que seja confiável. Alguns provedores de rede bloqueiam ICMP como medida de segurança, o que pode dificultar a depuração da conectividade.
Trace rota
Traceroute testa a rota completa que os pacotes de rede levam de um host para outro. Ele mostra todas as etapas ("saltos") que o pacote percorre ao longo do caminho e quanto tempo leva cada etapa. Se o pacote não percorrer todo o caminho até o destino, traceroute não será concluído, mas terminará com uma série de asteriscos. Neste caso, procure o último endereço IP que foi alcançado com sucesso ao longo do caminho. Foi aqui que a conectividade foi interrompida.
Traceroute pode expirar. Ele também pode falhar na conclusão se um gateway ao longo do caminho não estiver configurado corretamente para passar o pacote para o próximo salto.
Quando traceroute não for concluído, você poderá descobrir onde ele parou. Encontre o último endereço IP listado na saída traceroute e faça uma pesquisa no navegador para saber who owns [IP_ADDRESS] . Os resultados podem ou não mostrar o proprietário do endereço, mas vale a pena tentar.
metrô
A ferramenta mtr é uma forma de traceroute que permanece ativa e continuamente atualizada, semelhante à forma como o comando top funciona para processos locais.
Localize seu endereço IP local
Se você não souber o endereço local do seu host, execute o comando ip -br address show . No Linux, 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 .
Alternativamente, você pode executar ipconfig ou ifconfig para ver o status de suas interfaces de rede.
Localize 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 comunicarem entre si (o endereço IP de saída), conclua as etapas a seguir:
Vá para a página Instâncias SQL no Google Cloud console.
Clique no nome da instância associada ao trabalho de migração que você está depurando.
Role para baixo até que o painel Conectar a esta instância seja exibido. Neste painel, o endereço IP de saída aparece.
Abra portas locais
Para verificar se o seu host está escutando nas portas que você pensa, execute o comando ss -tunlp4 . Isso informa quais portas estão abertas e escutando. Por exemplo, se você tiver um banco de dados PostgreSQL em execução, a porta 5432 deverá estar ativa e escutando. Para SSH, você deverá ver a porta 22.
Todas as atividades portuárias locais
Use o comando netstat para ver toda a atividade da porta local. Por exemplo, netstat -lt mostra todas as portas atualmente ativas.
Conecte-se ao host remoto usando telnet
Para verificar se você pode se conectar ao host remoto usando TCP , execute o comando telnet . O Telnet tenta se conectar ao endereço IP e à porta que você forneceu.
telnet 35.193.198.159 5432 .No sucesso, você vê o seguinte: Tentando 35.193.198.159 ...
Conectado a 35.193.198.159. .
No fracasso, você vê telnet para de responder até que você feche a tentativa: tentando 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 Conexões de replicação do arquivo pg_hba.conf no banco de dados de origem está atualizada para aceitar conexões a partir do intervalo de endereço IP da Cloud SQL VPC.
Registro em nuvem
Serviço de migração de banco de dados e SQL em nuvem use o log de nuvem. Consulte a documentação do log de nuvem para obter informações completas e revise as consultas de amostra do Cloud SQL .Ver registros
Você pode visualizar logs para instâncias de SQL em nuvem e outros Google CloudProjetos como VPN em nuvem ou instâncias do mecanismo de computação. Para visualizar os logs para as entradas de log da sua nuvem SQL Instância:Console
- Vá para o explorador de logs
- Selecione um projeto SQL em nuvem existente na parte superior da página.
- No construtor de consultas, adicione o seguinte:
- Recurso: selecione Cloud SQL Database . Na caixa de diálogo, selecione uma instância do Cloud SQL.
- Nomes de log: role para a seção SQL em nuvem e selecione Arquivos de log apropriados para sua instância. Por exemplo:
- cloudsql.googleapis.com/postgres.log
- Gravidade: selecione um nível de log.
- Intervalo de tempo: selecione uma predefinição ou crie um intervalo personalizado.
gcloud
Use o comando gcloud logging para visualizar as entradas de log. No exemplo abaixo, substitua PROJECT_ID . O sinalizador limit é um parâmetro opcional que indica o número máximo de entradas para retornar.
gcloud logging read "projects/[PROJECT_ID]/logs/cloudsql.googleapis.com/postgres.log" --limit=10
Endereços IP privados
As conexões com uma instância de SQL em nuvem usando um endereço IP privado são automaticamente autorizadas para intervalos de endereço RFC 1918 . As faixas de endereço não-RFC 1918 devem ser configuradas no Cloud SQL como redes autorizadas . Você também precisa atualizar o Peering de rede para o Cloud SQL para exportar quaisquer rotas não RFC 1918. Por 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 Docker Bridge. Quaisquer instâncias SQL em nuvem criadas com um endereço IP nesse intervalo serão inacessíveis. As conexões de qualquer endereço IP dentro desse intervalo para as instâncias SQL em nuvem usando o endereço IP privado falharão.
Solução de problemas da VPN
Veja oGoogle Cloud Página de solução de problemas de VPN em nuvem .
Problemas de solução de problemas de túnel SSH reverso
O SSH Tunneling é um método para encaminhar alguma comunicação sobre uma conexão SSH. O tunelamento SSH reverso permite a configuração de um túnel SSH, mas mantendo que a rede de destino é a que inicia a conexão do túnel. Isso é útil quando você não deseja abrir uma porta em sua própria rede para fins de segurança.
source DB que você está tentando alcançar é configurar o seguinte: Cloud SQL DB ---> Compute Engine VM bastion source network bastion --- tunnel
Supõe -se que:
O Compute Engine VM bastion pode acessar o Cloud SQL DB .
O source network bastion pode acessar o source DB (isso é alcançado ao espiar a rede SQL da nuvem para a rede VM do mecanismo de computação).
Em seguida, você configura um túnel SSH do source network bastion para o Compute Engine VM bastion , que direciona quaisquer conexõ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 de forma inadequada e impedir que todo o fluxo funcione. Solucionar problemas de cada link, um por um:
source network bastion ---> source DB
- Conecte -se ao source network bastion usando SSH ou do terminal, se for a máquina local.
- 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]- Espere ver as cadeias de conexão Telnet, terminando comConnected to xxxx. -
[db_client] -h[source_db_host_or_ip] -P[source_db_port]-Espere ver o acesso negado
-
Se isso falhar, você precisará verificar se você permitiu o acesso deste bastião no banco de dados de origem.
Compute Engine VM bastion ---> source DB
- Ssh para o Compute Engine VM bastion (usando
gcloud compute ssh VM_INSTANCE_NAME) - Teste a conectividade com o banco de dados de origem usando um dos seguintes métodos:
-
telnet 127.0.0.1 [tunnel_port]- Espere ver as cadeias de conexão Telnet, terminando comConnected to xxxx. -
[db_client] -h127.0.0.1 -P[tunnel_port]-Espere ver o acesso negado
-
Se isso falhar, você precisará verificar se o túnel está em funcionamento corretamente. A execução sudo netstat -tupln mostra todos os processos de escuta nesta VM, e você deve ver sshd listening on the tunnel_port .
Cloud SQL DB ---> source DB
Isso é melhor testado testing the migration job do serviço de migração de banco de dados. Se isso falhar, significa que há algum problema com o peering vpc ou o roteamento entre a rede SQL da nuvem e a rede Compute Engine VM bastion .
O firewall do servidor de banco de dados de origem deve ser configurado para permitir que todo o intervalo de IP interno alocado para a conexão de serviço privado da rede VPC que a instância de destino da nuvem SQL usará como o campo PrivateNetwork de suas configurações de configuração ipconfiguration .
Para encontrar o intervalo de IP interno no console:
Vá para a página de redes VPC no Google Cloud console.
Selecione a rede VPC que você deseja usar.
Selecione a guia Connection de serviço privado .
Você também pode visualizar o tráfego entre a instância do Cloud SQL e a instância da VM do mecanismo de computação no console de log de nuvem no projeto Cloud VPN gateway . Nos logs da VM do mecanismo de computação, procure tráfego proveniente da instância do SQL em nuvem. Nos logs da Cloud SQL Instância, procure o tráfego da VM do mecanismo de computação.
Exceto em caso de indicação contrária, o conteúdo desta página é licenciado de acordo com a Licença de atribuição 4.0 do Creative Commons, e as amostras de código são licenciadas de acordo com a Licença Apache 2.0. Para mais detalhes, consulte as políticas do site do Google Developers. Java é uma marca registrada da Oracle e/ou afiliadas.
Última atualização 2025-05-15 UTC.