Resolver problemas de conectividade interna entre as VMs

Neste documento, apresentamos as etapas de solução de problemas de conectividade entre as VMs do Compute Engine que estão na mesma rede de nuvem privada virtual (VPC, na sigla em inglês) (VPC compartilhada ou independente) ou duas redes VPC conectadas com peering de rede VPC. Ele pressupõe que as VMs estejam se comunicando usando os endereços IP internos dos respectivos controladores de interface de rede virtual (vNICs, na sigla em inglês).

As etapas neste guia se aplicam às VMs do Compute Engine e aos nós do Google Kubernetes Engine.

Para ver outros cenários específicos de solução de problemas, clique no link Enviar feedback na parte inferior da página e nos informe.

As configurações de VM e VPC a seguir são aplicáveis a este guia:

  • conexões VM para VM usando endereços IP internos em uma única rede VPC;
  • conexões VM para VM usando endereços IP internos em uma rede VPC compartilhada;
  • conexões VM para VM usando endereços IP internos em diferentes redes VPC com peering usando peering de rede VPC.

Os comandos usados neste guia estão disponíveis em todas as imagens do SO fornecidas pelo Google. Se você estiver usando sua própria imagem do SO, talvez seja necessário instalar as ferramentas.

Quantificar o problema

Resolver problemas de falha completa de conexão

Veja nas seções a seguir as etapas para resolver problemas de falha completa de conectividade interna entre as VMs. Se você estiver enfrentando maior tempo de latência ou tempo limite de conexão intermitente, pule para Resolver problemas de latência ou perda de rede que causa problemas de capacidade de processamento.

Determinar valores de conexão

Primeiro, colete as seguintes informações:

  • Na página Instância de VM, colete o seguinte em relação às duas VMs:
    • nomes das VMs;
    • zonas das VMs;
    • endereços IP internos dos vNICs que estão se comunicando;
  • Na configuração do software servidor de destino, reúna estas informações:

    • Protocolo de camada 4
    • Porta de destino

    Por exemplo, se o destino for um servidor HTTPS, o protocolo será TCP e a porta geralmente será 443, mas a configuração específica talvez use uma porta diferente.

Se estiver tendo problemas com várias VMs, escolha uma única VM de origem e destino que esteja com problemas e use esses valores. Em geral, a porta de origem da conexão não é necessária.

Quando tiver essas informações, prossiga para Investigar problemas com a rede subjacente do Google.

Investigar problemas com a rede subjacente do Google

Se a configuração for uma configuração existente que não foi alterada recentemente, o problema talvez seja com a rede do Google subjacente. Verifique o Painel de desempenho do Network Intelligence Center em busca de perda de pacotes entre as zonas de VM. Se houver um aumento na perda de pacotes entre as zonas durante o período em que ocorreram tempos limite de rede, isso pode indicar que o problema estava na rede física subjacente à rede virtual. Verifique se há problemas conhecidos no Painel de status do Google Cloud antes de registrar um caso de suporte.

Se o problema não parecer estar na rede subjacente do Google, consulte Verificar se há regras de firewall do Google Cloud configuradas incorretamente.

Verificar se há regras de firewall do Google Cloud configuradas incorretamente

Os Testes de conectividade analisam a configuração do caminho da rede VPC entre duas VMs e mostra se a configuração programada permitirá ou não o tráfego. Se o tráfego não for permitido, os resultados mostrarão se uma regra de firewall de saída ou entrada do Google Cloud está bloqueando o tráfego ou se uma rota não está disponível.

Os Testes de conectividade também podem testar dinamicamente o caminho enviando pacotes entre os hipervisores das VMs. Se esses testes forem realizados, os resultados deles serão exibidos.

Os Testes de conectividade examinam apenas a configuração da rede VPC. Eles não testam o firewall do sistema operacional ou as rotas do sistema operacional ou o software do servidor na VM.

O procedimento a seguir executa os Testes de conectividade no Console do Google Cloud. Para ver outras maneiras de executar testes, consulte Como executar Testes de conectividade.

Use o procedimento a seguir para criar e executar um teste:

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

    Acesse Testes de conectividade

  2. No menu suspenso do projeto, confirme se você está no projeto correto ou especifique o correto.

  3. Clique em Criar teste de conectividade.

  4. Dê um nome ao teste.

  5. Especifique o seguinte:

    1. Protocolo
    2. Endereço IP do endpoint de origem
    3. Projeto de origem e rede VPC
    4. Endereço IP do endpoint de destino
    5. Projeto de destino e rede VPC
    6. Porta de destino
  6. Clique em Criar.

O teste é executado imediatamente. Para ver o diagrama de resultados, clique em Visualizar na coluna Detalhes do resultado.

  • Se os resultados mostrarem que a conexão foi descartada por uma regra de firewall do Google Cloud, determine se a configuração de segurança pretendida permitirá a conexão. Talvez seja necessário solicitar detalhes ao administrador de segurança ou de rede. Se o tráfego for permitido, verifique o seguinte:
  • Se houver uma regra de firewall configurada corretamente que esteja bloqueando esse tráfego, entre em contato com o administrador de segurança ou de rede. Se os requisitos de segurança da organização significam que as VMs não devem se alcançar, talvez seja necessário reformular a configuração.
  • Se os resultados indicarem que não há problemas com o caminho de conectividade da VPC, o problema poderá ser um dos seguintes.
    • Problemas com a configuração do SO convidado, como problemas com o software de firewall.
    • Problemas com os aplicativos cliente ou servidor, como o aplicativo estar congelado ou configurado para detectar na porta errada.

As etapas subsequentes orientam você ao examinar cada uma dessas possibilidades. Continue com Testar a conectividade TCP de dentro da VM.

Testar a conectividade TCP de dentro da VM

Se o Teste de conectividade entre VMs não detectou um problema de configuração da VPC, comece a testar a conectividade entre os SOs. As etapas a seguir ajudam você a determinar:

  • se um servidor TCP está detectando na porta indicada;
  • se o software de firewall do servidor está permitindo conexões com essa porta pela VM cliente;
  • se o software de firewall do lado do cliente está permitindo conexões com essa porta no servidor;
  • se a tabela de rotas do lado do servidor está configurada corretamente para encaminhar pacotes;
  • se a tabela de rotas do lado do cliente está configurada corretamente para encaminhar pacotes.

Você pode testar o handshake TCP usando curl com o Linux ou o Windows 2019 ou usando o comando New-Object System.Net.Sockets.TcpClient com o Windows Powershell. O fluxo de trabalho nesta seção resultará em um dos seguintes resultados: conexão bem-sucedida, tempo limite da conexão ou redefinição da conexão.

  • Bem-sucedida: se o handshake TCP for concluído com sucesso, isso significa que uma regra de firewall do sistema operacional não está bloqueando a conexão, que o sistema operacional está encaminhando pacotes corretamente e que algum tipo de servidor está detectando na porta de destino. Se esse for o caso, o problema pode estar no próprio aplicativo. Consulte Verificar a geração de registros do servidor para mais informações sobre o comportamento do servidor.
  • Tempo limite: se a conexão expirar, geralmente significará um dos seguintes:
    • não há máquina nesse endereço IP;
    • há um firewall em algum lugar descartando os pacotes silenciosamente;
    • o roteamento de pacote do SO está enviando os pacotes para um destino que não pode processá-los ou o roteamento assimétrico está enviando o pacote de retorno para um caminho inválido.
  • Redefinição: se a conexão estiver sendo redefinida, isso significa que o IP de destino está recebendo pacotes, mas um SO ou um aplicativo está rejeitando os pacotes. Isso pode significar uma destas coisas:

    • os pacotes estão chegando à máquina errada e não está configurado para responder a esse protocolo nessa porta;
    • Os pacotes estão chegando à máquina correta, mas nenhum servidor está detectando nessa porta;
    • Os pacotes estão chegando à porta e máquina corretas, mas os protocolos de nível superior (como SSL) não estão concluindo o handshake;
    • um firewall está redefinindo a conexão. Isso é menos provável do que um firewall descartando silenciosamente os pacotes, mas pode acontecer.

Linux

  1. No Console do Google Cloud, acesse a página Firewall.

    Acessar políticas de firewall

  2. Verifique se há uma regra de firewall que permita conexões SSH pelo IAP com a VM ou crie uma nova.

  3. No console do Google Cloud, acesse a página Instâncias de VMs.

    Acessar instâncias de VM

  4. Encontre a VM de origem.

  5. Clique em SSH na coluna Conectar para essa VM.

  6. Na linha de comando da máquina cliente, execute o comando a seguir. Substitua DEST_IP:DEST_PORT pelo endereço IP e pela porta de destino.

    curl -vso /dev/null --connect-timeout 5 DEST_IP:DEST_PORT
    

Windows

  1. No console do Google Cloud, acesse a página Instâncias de VMs.

    Acessar instâncias de VM

  2. Encontre a VM de origem.

  3. Use um dos métodos descritos em Como conectar-se às VMs do Windows para se conectar à VM.

  4. Na linha de comando da máquina cliente, execute:

    • Windows 2019:
      curl -vso /dev/null --connect-timeout 5 DEST_IP:DEST_PORT
      
    • Windows 2012 ou Windows 2016 Powershell:
      PS C:> New-Object System.Net.Sockets.TcpClient('DEST_IP',DEST_PORT)`
      

Conexão bem-sucedida

Os resultados a seguir indicam um handshake de TCP bem-sucedido. Se o handshake de TCP for concluído com sucesso, o problema não estará relacionado ao tempo limite de conexão TCP ou à redefinição. O problema de tempo limite ocorre nas camadas do aplicativo. Se a conexão for bem-sucedida, prossiga para Verificar a geração de registros do servidor para informações sobre o comportamento do servidor.

Linux e Windows 2019

$ curl -vso /dev/null --connect-timeout 5 192.168.0.4:443

A linha "Conectado a" indica um handshake de TCP bem-sucedido.

Expire in 0 ms for 6 (transfer 0x558b3289ffb0)
Expire in 5000 ms for 2 (transfer 0x558b3289ffb0)
  Trying 192.168.0.4...
TCP_NODELAY set
Expire in 200 ms for 4 (transfer 0x558b3289ffb0)
Connected to 192.168.0.4 (192.168.0.4) port 443 (#0)
> GET / HTTP/1.1
> Host: 192.168.0.4:443
> User-Agent: curl/7.64.0
> Accept: */*
>
Empty reply from server
Connection #0 to host 192.168.0.4 left intact

Windows 2012 e 2016

PS C:\> New-Object System.Net.Sockets.TcpClient('DEST_IP_ADDRESS', PORT)

Resultado de conexão bem-sucedida. A linha "Conectado: Verdadeiro" é relevante.

Available           : 0
Client              : System.Net.Sockets.Socket
Connected           : True
ExclusiveAddressUse : False
ReceiveBufferSize   : 131072
SendBufferSize      : 131072
ReceiveTimeout      : 0
SendTimeout         : 0
LingerState         : System.Net.Sockets.LingerOption
NoDelay             : False

Tempo limite de conexão

Os resultados a seguir indicam que a conexão expirou. Se a conexão estiver prestes a expirar, prossiga para Verificar o endereço IP e a porta do servidor.

Linux e Windows 2019

$ curl -vso /dev/null --connect-timeout 5 DEST_IP_ADDRESS:PORT

Resultado de tempo limite da conexão:

Trying 192.168.0.4:443...
Connection timed out after 5000 milliseconds
Closing connection 0

Windows 2012 e 2016

PS C:\> New-Object System.Net.Sockets.TcpClient('DEST_IP_ADDRESS', PORT)

Resultado de tempo limite da conexão:

New-Object: Exception calling ".ctor" with "2" argument(s): "A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. 192.168.0.4:443"

Redefinição de conexão

Redefinição é quando um dispositivo envia um pacote RST para o cliente, informando que a conexão foi encerrada. A conexão pode ser redefinida por um dos seguintes motivos:

  • O servidor de recebimento não foi configurado para aceitar conexões com esse protocolo nessa porta. Isso pode ter ocorrido porque o pacote foi enviado ao servidor ou à porta errada ou porque o software servidor estava configurado incorretamente.
  • O software de firewall rejeitou a tentativa de conexão

Se a conexão tiver sido redefinida, prossiga para Verificar se você está acessando a porta e o endereço IP corretos.

Linux e Windows 2019

$ curl -vso /dev/null --connect-timeout 5 DEST_IP_ADDRESS:PORT

Resultado de redefinição da conexão:

Trying 192.168.0.4:443...
connect to 192.168.0.4 port 443 failed: Connection refused
Failed to connect to 192.168.0.4 port 443: Connection refused
Closing connection 0

Windows 2012 e 2016

PS C:\> New-Object System.Net.Sockets.TcpClientt('DEST_IP_ADDRESS', PORT)

Resultado de redefinição da conexão:

New-Object: Exception calling ".ctor" with "2" argument(s): "No connection could be made because the target machine actively refused it. 192.168.0.4:443"

Verificar o endereço IP e a porta do servidor

Execute um dos seguintes comandos no servidor. Eles indicam se há um servidor detectando na porta necessária.

Linux

$ sudo netstat -ltuvnp

A saída mostra que um servidor TCP está detectando em qualquer endereço IP de destino (0.0.0.0) na porta 22, aceitando conexões de qualquer endereço de origem (0.0.0.0) e qualquer porta de origem (*). A coluna Nome do PID/Programa especifica o limite executável para o soquete.

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      588/sshd
tcp6       0      0 :::22                   :::*                    LISTEN      588/sshd
udp        0      0 0.0.0.0:68              0.0.0.0:*                           334/dhclient
udp        0      0 127.0.0.1:323           0.0.0.0:*                           429/chronyd
udp6       0      0 ::1:323                 :::*                                429/chronyd

Windows

PS C:\> Get-NetTcpConnection -State "LISTEN" -LocalPort DEST_PORT

A saída mostra os resultados da execução do comando com DEST_PORT definido como 443. Esta saída mostra que um servidor TCP está detectando em qualquer endereço (0.0.0.0) na porta 443, aceitando conexões de qualquer endereço de origem (0.0.0.0) e qualquer porta de origem (0). A coluna OwningProcess indica o ID do processo que detecta o soquete.

LocalAddress LocalPort RemoteAddress RemotePort State  AppliedSetting OwningProcess
------------ --------- ------------- ---------- -----  -------------- -------------
::           443       ::            0          Listen                928
0.0.0.0      443       0.0.0.0       0          Listen                928

Se você observar que o servidor não está vinculado à porta ou ao IP correto ou que o prefixo remoto não corresponde ao cliente, consulte a documentação do servidor ou do fornecedor para resolver o problema. O servidor precisa estar vinculado ao endereço IP de uma interface específica ou a 0.0.0.0 e precisa aceitar conexões do prefixo do IP do cliente correto ou 0.0.0.0.

Se o servidor do aplicativo estiver vinculado ao endereço IP e à porta corretos, pode ser que o cliente esteja acessando a porta errada, que um protocolo de nível mais alto (frequentemente TLS) esteja recusando ativamente a conexão ou que há um firewall rejeitando a conexão.

Verifique se o cliente e o servidor estão usando a mesma versão e formação de criptografia TLS.

Verifique se o cliente está acessando a porta correta.

Se as etapas anteriores não resolverem o problema, acesse Verifique se há descarte de pacotes no firewall no cliente e no servidor.

Verificar o firewall no cliente e no servidor em busca de pacotes descartados

Se o servidor estiver inacessível na VM do cliente, mas estiver escutando na porta correta, pode ser que uma das VMs esteja executando o software de firewall que está descartando os pacotes associados à conexão. Verifique o firewall nas VMs do cliente e do servidor usando os comandos a seguir.

Se uma regra estiver bloqueando o tráfego, atualize o software de firewall para permitir o tráfego. Se você atualizar o firewall, continue com cuidado ao preparar e executar os comandos porque um firewall configurado incorretamente pode bloquear o tráfego inesperado. Considere configurar o acesso ao Console serial da VM antes de continuar.

Iptables do Linux

Verifique o número de pacotes processados na contagem de pacotes de cada cadeia e regra de iptables instaladas. Determine quais regras DROP estão sendo comparadas comparando endereços IP e portas de origem e destino com os prefixos e portas especificados pelas regras iptables.

Se uma regra correspondente estiver mostrando o descarte crescente com tempos limite de conexão, consulte a documentação do iptables para aplicar a regra allow correta às conexões apropriadas.

$ sudo iptables -L -n -v -x

Este exemplo de cadeia INPUT mostra que os pacotes de qualquer endereço IP para qualquer endereço IP que use a porta TCP de destino 5000 serão descartados no firewall. A coluna pkts indica que a regra descartou 10.342 pacotes. Como teste, se você criar conexões que são descartadas por essa regra, verá o contador pkts aumentar, confirmando o comportamento.

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts   bytes  target prot opt in  out  source      destination
10342 2078513    DROP  tcp  --  *  *    0.0.0.0/0   0.0.0.0/0 tcp dpt:5000

É possível adicionar uma regra de entrada ou saída ao iptables com os seguintes comandos:

Regra de entrada:

$ sudo iptables -A INPUT -p tcp -s SOURCE_IP_PREFIX --dport SERVER_PORT -j ACCEPT

Regra de saída:

$ sudo iptables -A OUTPUT -p tcp -d DEST_IP_PREFIX --dport DEST_PORT -j ACCEPT

Firewall do Windows

Verifique no Firewall do Windows se a conexão tem permissão para saída do cliente e de entrada do servidor. Se uma regra estiver bloqueando o tráfego, faça as correções necessárias no Firewall do Windows para permitir as conexões. Também é possível ativar o Windows Firewall Logging.

O comportamento DENY padrão do Firewall do Windows é descartar silenciosamente os pacotes negados, resultando em tempos limite.

Esse comando verifica o servidor. Para verificar as regras de saída na VM do cliente, altere o valor -match para Outbound.

PS C:\> Get-NetFirewallPortFilter | `
>>   Where-Object LocalPort -match  "PORT" | `
>>   Get-NetFirewallRule | `
>>   Where-Object {$_.Direction -match "Inbound" -and $_.Profile -match "Any"}
Name                  : {80D79988-C7A5-4391-902D-382369B4E4A3}
DisplayName           : iperf3 udp
Description           :
DisplayGroup          :
Group                 :
Enabled               : True
Profile               : Any
Platform              : {}
Direction             : Inbound
Action                : Allow
EdgeTraversalPolicy   : Block
LooseSourceMapping    : False
LocalOnlyMapping      : False
Owner                 :
PrimaryStatus         : OK
Status                : The rule was parsed successfully from the store. (65536)
EnforcementStatus     : NotApplicable
PolicyStoreSource     : PersistentStore
PolicyStoreSourceType : Local

É possível adicionar uma nova regra de firewall ao Windows com os comandos a seguir.

Regra de saída:

PS C:\> netsh advfirewall firewall add rule name="My Firewall Rule" dir=out action=allow protocol=TCP remoteport=DEST_PORT

Regra de entrada:

PS C:\> netsh advfirewall firewall add rule name="My Firewall Rule" dir=in action=allow protocol=TCP localport=PORT

Software de terceiros

Firewalls de aplicativos de terceiros ou software antivírus também podem descartar ou rejeitar conexões. Consulte a documentação fornecida pelo fornecedor.

Se você encontrar um problema com as regras de firewall e corrigi-lo, teste novamente a conectividade. Se você achar que as regras de firewall não são o problema, prossiga para Verificar a configuração do roteamento do SO

Verificar a configuração de roteamento do SO

Os problemas de roteamento do sistema operacional podem ocorrer em uma das seguintes situações:

  • os problemas de roteamento são mais comuns em VMs com várias interfaces de rede devido à complexidade do roteamento extra;
  • em uma VM criada no Google Cloud com uma única interface de rede, os problemas de roteamento geralmente só acontecem se alguém tiver modificado manualmente a tabela de roteamento padrão;
  • em uma VM migrada do local, a VM pode transportar configurações de roteamento ou MTU que eram necessárias no local, mas que estão causando problemas na rede VPC.

Se você estiver usando uma VM com várias interfaces de rede, será necessário configurar as rotas para a saída para o vNIC e a sub-rede corretos. Por exemplo, uma VM pode ter rotas configuradas para que o tráfego destinado a sub-redes internas seja enviado para um vNIC, mas o gateway padrão (destino 0.0.0.0/0) é configurado em outro vNIC que tenha um endereço IP externo ou acesso ao Cloud NAT.

Revise as rotas verificando rotas individuais uma de cada vez ou checando toda a tabela de roteamento da VM. Se qualquer uma das abordagens revelar problemas com a tabela de roteamento, consulte as etapas em Atualizar tabelas de roteamento se necessário para ver instruções.

Analisar todas as rotas

Liste todas as rotas para entender quais rotas já existem na VM.

Linux

$ ip route show table all
default via 10.3.0.1 dev ens4
10.3.0.1 dev ens4 scope link
local 10.3.0.19 dev ens4 table local proto kernel scope host src 10.3.0.19
broadcast 10.3.0.19 dev ens4 table local proto kernel scope link src 10.3.0.19
broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1
::1 dev lo proto kernel metric 256 pref medium
fe80::/64 dev ens4 proto kernel metric 256 pref medium
local ::1 dev lo table local proto kernel metric 0 pref medium
local fe80::4001:aff:fe03:13 dev ens4 table local proto kernel metric 0 pref medium
multicast ff00::/8 dev ens4 table local proto kernel metric 256 pref medium

Windows

PS C:\> Get-NetRoute
ifIndex DestinationPrefix             NextHop  RouteMetric ifMetric PolicyStore
------- -----------------             -------  ----------- -------- -----------
4       255.255.255.255/32            0.0.0.0          256 5        ActiveStore
1       255.255.255.255/32            0.0.0.0          256 75       ActiveStore
4       224.0.0.0/4                   0.0.0.0          256 5        ActiveStore
1       224.0.0.0/4                   0.0.0.0          256 75       ActiveStore
4       169.254.169.254/32            0.0.0.0            1 5        ActiveStore
1       127.255.255.255/32            0.0.0.0          256 75       ActiveStore
1       127.0.0.1/32                  0.0.0.0          256 75       ActiveStore
1       127.0.0.0/8                   0.0.0.0          256 75       ActiveStore
4       10.3.0.255/32                 0.0.0.0          256 5        ActiveStore
4       10.3.0.31/32                  0.0.0.0          256 5        ActiveStore
4       10.3.0.1/32                   0.0.0.0            1 5        ActiveStore
4       10.3.0.0/24                   0.0.0.0          256 5        ActiveStore
4       0.0.0.0/0                     10.3.0.1           0 5        ActiveStore
4       ff00::/8                      ::               256 5        ActiveStore
1       ff00::/8                      ::               256 75       ActiveStore
4       fe80::b991:6a71:ca62:f23f/128 ::               256 5        ActiveStore
4       fe80::/64                     ::               256 5        ActiveStore
1       ::1/128                       ::               256 75       ActiveStore

Verificar rotas individuais

Se um prefixo de IP específico parecer ser o problema, verifique se há rotas apropriadas para os IPs de origem e destino nas VMs do cliente e do servidor.

Linux

$ ip route get DEST_IP

Resultado bom:

Uma rota válida é exibida. Nesse caso, os pacotes saem da interface ens4.

10.3.0.34 via 10.3.0.1 dev ens4 src 10.3.0.26 uid 1000
   cache

Resultado ruim:

Esse resultado confirma que os pacotes estão sendo descartados porque não há caminho para a rede de destino. Confirme se a tabela de rotas contém um caminho para a interface de saída correta.

**RTNETLINK answers: Network is unreachable

Windows

PS C:\> Find-NetRoute -RemoteIpAddress "DEST_IP"

Resultado bom:

IPAddress         : 192.168.0.2
InterfaceIndex    : 4
InterfaceAlias    : Ethernet
AddressFamily     : IPv4
Type              : Unicast
PrefixLength      : 24
PrefixOrigin      : Dhcp
SuffixOrigin      : Dhcp
AddressState      : Preferred
ValidLifetime     : 12:53:13
PreferredLifetime : 12:53:13
SkipAsSource      : False
PolicyStore       : ActiveStore

Caption            :
Description        :
ElementName        :
InstanceID         : ;:8=8:8:9<>55>55:8:8:8:55;
AdminDistance      :
DestinationAddress :
IsStatic           :
RouteMetric        : 256
TypeOfRoute        : 3
AddressFamily      : IPv4
CompartmentId      : 1
DestinationPrefix  : 192.168.0.0/24
InterfaceAlias     : Ethernet
InterfaceIndex     : 4
InterfaceMetric    : 5
NextHop            : 0.0.0.0
PreferredLifetime  : 10675199.02:48:05.4775807
Protocol           : Local
Publish            : No
State              : Alive
Store              : ActiveStore
ValidLifetime      : 10675199.02:48:05.4775807
PSComputerName     :
ifIndex            : 4

Resultado ruim:


Find-NetRoute : The network location cannot be reached. For information about network troubleshooting, see Windows Help.
At line:1 char:1
+ Find-NetRoute -RemoteIpAddress "192.168.0.4"
+ ----------------------------------------
    + CategoryInfo          : NotSpecified: (MSFT_NetRoute:ROOT/StandardCimv2/MSFT_NetRoute) [Find-NetRoute], CimException
    + FullyQualifiedErrorId : Windows System Error 1231,Find-NetRoute

Esse comando confirma que os pacotes estão sendo descartados porque não há um caminho para o endereço IP de destino. Verifique se você tem um gateway padrão e se o gateway está aplicado ao vNIC e à rede corretos.

Atualizar tabelas de roteamento

Se necessário, adicione uma rota à tabela de rotas do sistema operacional. Antes de executar um comando para atualizar a tabela de roteamento da VM de roteamento, recomendamos que você se familiarize com os comandos e desenvolva uma compreensão das possíveis implicações. O uso inadequado dos comandos de atualização de rota pode causar problemas inesperados ou desconexão da VM. Considere configurar o acesso ao Console serial da VM antes de continuar.

Consulte a documentação do sistema operacional para ver instruções sobre como atualizar rotas.

Se você encontrar um problema com as rotas e corrigi-lo, teste novamente a conectividade. Se rotas não parecem ser o problema, prossiga para Verifique a MTU da interface.

Verificar a MTU

A MTU de interface de uma VM precisa corresponder à MTU da rede VPC a que está anexada. O ideal é que as VMs que se comunicam entre si também tenham MTUs correspondentes. MTUs incompatíveis normalmente não são um problema para TCP, mas podem ser para UDP.

Verifique a MTU da VPC. Se as VMs estiverem em duas redes diferentes, verifique as duas.

gcloud compute networks describe NET_NAME --format="table(name,mtu)"

Verifique a configuração da MTU para as interfaces de rede do cliente e do servidor.

Linux

$ netstat -i

A interface lo (loopback) sempre tem uma MTU de 65.536 e pode ser ignorada nesta etapa.

Kernel Interface table
Iface      MTU    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
ens4      1460  8720854      0      0 0      18270406      0      0      0 BMRU
lo       65536       53      0      0 0            53      0      0      0 LRU

Windows

PS C:\> Get-NetIpInterface

As pseudointerfaces de loopback sempre têm uma MTU de 4294967295 e podem ser ignoradas nesta etapa.

ifIndex InterfaceAlias              Address NlMtu(Bytes) Interface Dhcp     Connection PolicyStore
                                    Family               Metric             State
------- --------------              ------- ------------ --------- ----     ---------- -----------
4       Ethernet                    IPv6            1500         5 Enabled  Connected  ActiveStore
1       Loopback Pseudo-Interface 1 IPv6      4294967295        75 Disabled Connected  ActiveStore
4       Ethernet                    IPv4            1460         5 Enabled  Connected  ActiveStore
1       Loopback Pseudo-Interface 1 IPv4      4294967295        75 Disabled Connected  Active

Se as MTUs da interface e da rede não forem iguais, reconfigure o MTU da interface. Para mais informações, consulte Configurações de VMs e MTU. Se elas forem correspondentes e você tiver seguido as etapas de solução de problemas até aqui, o problema provavelmente está no próprio servidor. Para orientações sobre como solucionar problemas do servidor, prossiga para Verificar a geração de registros do servidor para mais informações sobre o comportamento do servidor.

Verificar a geração de registros do servidor para mais informações sobre o comportamento do servidor

Se as etapas anteriores não resolverem um problema, o aplicativo pode estar causando os tempos limite. Verifique os registros do servidor e do aplicativo para saber o comportamento que explicaria o que você está vendo.

Origens de registro a serem verificadas:

Se os problemas persistirem

Se os problemas persistirem, consulte Como receber suporte para ver as próximas etapas. Se as MTUs da interface e da rede não corresponderem, é possível reconfigurar a MTU da interface.

Resolver problemas de latência de rede ou perda que causam problemas de capacidade de processamento

Problemas de latência de rede ou perda costumam ser causados por esgotamento de recursos ou gargalos em uma VM ou caminho de rede. Ocasionalmente, a perda de rede pode causar tempos limite de conexão intermitentes. Causas como exaustão de vCPU ou saturação de vNIC resultam em maior latência e perda de pacotes, levando a uma redução no desempenho da rede.

As instruções a seguir pressupõem que as conexões não estão atingindo o tempo limite e que há problemas de capacidade ou desempenho limitados. Se você estiver enfrentando perda completa de pacotes, consulte Resolver problemas de falha de conexão completa.

Pequenas variações na latência, como latências que variam em alguns milissegundos, são normais. As latências variam devido à carga da rede ou ao enfileiramento dentro da VM.

Determinar valores de conexão

Primeiro, colete as seguintes informações:

  • Na página Instância de VM, colete o seguinte em relação às duas VMs:
    • nomes das VMs;
    • zonas das VMs;
    • endereços IP internos dos vNICs que estão se comunicando;
  • Na configuração do software servidor de destino, reúna estas informações:
    • Protocolo de camada 4
    • Porta de destino

Se estiver tendo problemas com várias VMs, escolha uma única VM de origem e destino que esteja com problemas e use esses valores. Em geral, a porta de origem da conexão não é necessária.

Quando tiver essas informações, prossiga para Investigar problemas com a rede subjacente do Google.

Investigar problemas com a rede subjacente do Google

Se a configuração for uma configuração existente que não foi alterada recentemente, o problema talvez seja com a rede do Google subjacente. Verifique o Painel de desempenho do Network Intelligence Center em busca de perda de pacotes entre as zonas de VM. Se houver um aumento na perda de pacotes entre as zonas durante o período em que ocorreram tempos limite de rede, isso pode indicar que o problema está na rede física subjacente à rede virtual. Verifique se há problemas conhecidos no Painel de status do Google Cloud antes de registrar um caso de suporte.

Se o problema não parecer estar na rede subjacente do Google, prossiga para Verificar a latência do handshake.

Verificar a latência do handshake

Todos os protocolos baseados em conexão geram alguma latência enquanto fazem o handshake de configuração de conexão. Cada handshake de protocolo aumenta a sobrecarga. Para conexões SSL/TLS, por exemplo, o handshake TCP precisa ser concluído antes que o handshake SSL/TLS possa ser iniciado. Portanto, o handshake TLS precisa ser concluído antes que os dados possam ser transmitidos.

A latência do handshake na mesma zona do Google Cloud geralmente é insignificante, mas os handshakes para locais globalmente distantes podem adicionar maiores atrasos na inicialização da conexão. Se você tiver recursos em regiões distantes, verifique se a latência observada se deve ao handshake de protocolo.

Linux e Windows 2019

$ curl -o /dev/null -Lvs -w 'tcp_handshake: %{time_connect}s, application_handshake: %{time_appconnect}s' DEST_IP:PORT
tcp_handshake: 0.035489s, application_handshake: 0.051321s
  • tcp_handshake é a duração desde o momento em que o cliente envia o pacote SYN inicial até quando o cliente envia a ACK do handshake de TCP;
  • application_handshake é o tempo desde o primeiro pacote SYN do handshake TCP até a conclusão do handshake TLS (normalmente);
  • tempo de handshake adicional = application_handshake - tcp_handshake.

Windows 2012 e 2016

Não disponível com as ferramentas padrão do SO. O tempo de retorno do ICMP pode ser usado como referência se as regras de firewall permitirem.

Se a latência for maior do que os handshakes considerariam, prossiga para Determinar a capacidade máxima do tipo de VM.

Determinar a capacidade máxima do tipo de VM

A capacidade de saída da rede da VM é limitada pela arquitetura da CPU da VM e pela contagem de vCPUs. Determine a potencial largura de banda de saída da VM consultando a página Largura de banda da rede.

Se a VM não for capaz de atender aos requisitos de saída, faça upgrade para uma VM com maior capacidade. Para mais instruções, consulte Como alterar o tipo de máquina de uma instância.

Se o tipo de máquina permitir uma largura de banda de saída suficiente, investigue se o uso do disco permanente está interferindo na saída da rede. As operações do disco permanente podem ocupar até 60% da capacidade total da rede da VM. Para determinar se as operações do disco permanente podem estar interferindo na capacidade da rede, consulte Verificar o desempenho do disco permanente.

A entrada da rede para uma VM não é limitada pela rede VPC ou pelo tipo de instância da VM. Ela é determinada pelo desempenho da fila e do processamento do pacote do sistema operacional ou do aplicativo da VM. Se a largura de banda de saída for adequada, mas você estiver enfrentando problemas de entrada, consulte Verificar a geração de registros do servidor para informações sobre o comportamento do servidor.

Verificar a MTU da interface

A MTU de uma rede VPC é configurável. A MTU da interface na VM deve corresponder ao valor de MTU da rede VPC à qual está anexada. Em uma situação de peering de rede VPC, as VMs em redes diferentes podem ter MTUs diferentes. Neste caso, aplique o valor de MTU menor às interfaces associadas. Incompatibilidades de MTU normalmente não são um problema para TCP, mas podem ser para UDP.

Verifique a MTU da VPC. Se as VMs estiverem em duas redes diferentes, verifique as duas.

gcloud compute networks describe NET_NAME --format="table(name,mtu)"

Verifique a configuração da MTU na interface de rede.

Linux

A interface lo (loopback) sempre tem uma MTU de 65.536 e pode ser ignorada nesta etapa.

$ netstat -i
Kernel Interface table
Iface      MTU    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
ens4      1460  8720854      0      0 0      18270406      0      0      0 BMRU
lo       65536       53      0      0 0            53      0      0      0 LRU

Windows

PS C:\> Get-NetIpInterface

As pseudointerfaces de loopback sempre têm uma MTU de 4294967295 e podem ser ignoradas nesta etapa.

ifIndex InterfaceAlias              Address NlMtu(Bytes) Interface Dhcp     Connection PolicyStore
                                    Family               Metric             State
------- --------------              ------- ------------ --------- ----     ---------- -----------
4       Ethernet                    IPv6            1500         5 Enabled  Connected  ActiveStore
1       Loopback Pseudo-Interface 1 IPv6      4294967295        75 Disabled Connected  ActiveStore
4       Ethernet                    IPv4            1460         5 Enabled  Connected  ActiveStore
1       Loopback Pseudo-Interface 1 IPv4      4294967295        75 Disabled Connected  Active

Se as MTUs da interface e da rede não forem iguais, reconfigure o MTU da interface. Para instruções sobre como atualizar a MTU de VMs do Windows, consulte Configurações de VMs e MTU. Se corresponderem, o problema provavelmente será a disponibilidade do servidor. A próxima etapa é Verificar os registros para ver se uma VM foi reinicializada, interrompida ou migrada em tempo real para ver se algo aconteceu com a VM durante o período relevante.

Verificar os registros para ver se uma VM foi reinicializada, interrompida ou migrada em tempo real

Durante o ciclo de vida de uma VM, ela pode ser reinicializada pelo usuário, migrada em tempo real para manutenção do Google Cloud ou, em raras circunstâncias, uma VM pode ser perdida e recriada se houver uma falha no host que contém a VM. Esses eventos podem causar um aumento breve na latência ou nos tempos limites de conexão. Se alguma dessas situações acontecer com a VM, o evento será registrado.

Para ver os registros da VM:

  1. No Console do Google Cloud, acesse a página Logging.

    Acessar o Logging

  2. Escolha o período de ocorrência da latência.

  3. Use a consulta do Logging a seguir para determinar se ocorreu um evento de VM próximo ao período em que a latência ocorreu:

    resource.labels.instance_id:"INSTANCE_NAME"
    resource.type="gce_instance"
    (
      protoPayload.methodName:"compute.instances.hostError" OR
      protoPayload.methodName:"compute.instances.OnHostMaintenance" OR
      protoPayload.methodName:"compute.instances.migrateOnHostMaintenance" OR
      protoPayload.methodName:"compute.instances.terminateOnHostMaintenance" OR
      protoPayload.methodName:"compute.instances.stop" OR
      protoPayload.methodName:"compute.instances.reset" OR
      protoPayload.methodName:"compute.instances.automaticRestart" OR
      protoPayload.methodName:"compute.instances.guestTerminate" OR
      protoPayload.methodName:"compute.instances.instanceManagerHaltForRestart" OR
      protoPayload.methodName:"compute.instances.preempted"
    )
    

Se as VMs não forem reiniciadas ou migradas durante o período relevante, o problema poderá ser o esgotamento dos recursos. Para verificar, prossiga para Verificar as estatísticas de rede e SO para pacotes descartados devido ao esgotamento de recursos.

Verificar as estatísticas da rede e do SO em busca de pacotes descartados devido ao esgotamento dos recursos

Esgotamento de recursos é um termo geral que significa que alguns recursos na VM, como a largura de banda de saída, estão sendo solicitados para lidar com mais do que conseguem. O esgotamento dos recursos pode resultar em descartes periódicos de pacotes, o que causa latência de conexão ou tempos limite. Esses tempos limite podem não estar visíveis na inicialização do cliente ou do servidor, mas podem aparecer com o tempo à medida que um sistema esgotar recursos.

Veja a seguir uma lista de comandos que exibem contadores e estatísticas de pacotes. Alguns desses comandos duplicam os resultados de outros comandos. Nesses casos, é possível usar o comando que funcionar melhor para você. Consulte as observações em cada seção para entender melhor o resultado pretendido da execução do comando. Pode ser útil executar os comandos em momentos diferentes para ver se descartes ou erros estão ocorrendo ao mesmo tempo que o problema.

Linux

  1. Use o comando netstat para ver estatísticas de rede.

    $ netstat -s
    
    TcpExt:
      341976 packets pruned from receive queue because of socket buffer overrun
      6 ICMP packets dropped because they were out-of-window
      45675 TCP sockets finished time wait in fast timer
      3380 packets rejected in established connections because of timestamp
      50065 delayed acks sent
    

    O comando netstat gera estatísticas de rede que contêm valores de pacotes descartados por protocolo. Os pacotes descartados podem ser resultado do esgotamento de recursos pelo aplicativo ou pela interface da rede. Veja o motivo do contador para indicar por que um contador foi incrementado.

  2. Verifique o kern.log para registros que correspondem a nf_conntrack: table full, dropping packet.

    Debian: cat /var/log/kern.log | grep "dropping packet"

    CentOS: sudo cat /var/log/dmesg | grep "dropping packet"

    Esse registro indica que a tabela de rastreamento de conexão da VM atingiu o máximo de conexões que podem ser rastreadas. Outras conexões de e para essa VM podem atingir o tempo limite. Se o conntrack tiver sido ativado, a contagem máxima de conexões poderá ser encontrada com: sudo sysctl net.netfilter.nf_conntrack_max

    É possível aumentar o valor do máximo de conexões rastreadas modificando o sysctl net.netfilter.nf_conntrack_max ou espalhando uma carga de trabalho de VMs por várias VMs para reduzir a carga.

IU do Windows

Perfmon

  1. Usando o menu do Windows, procure "perfmon" e abra o programa.
  2. No menu à esquerda, selecione Desempenho > Ferramentas de monitoramento > Monitor de desempenho.
  3. Na visualização principal, clique no sinal de adição verde "+" para adicionar contadores de desempenho ao gráfico de monitoramento. Os seguintes contadores são relevantes:
    • Adaptador de rede
      • Tamanho da fila de saída
      • Saída de pacotes descartada
      • Erros de saída de pacotes
      • Pacotes recebidos descartados
      • Erros de pacotes recebidos
      • Pacotes recebidos desconhecidos
    • Interface da rede
      • Tamanho da fila de saída
      • Saída de pacotes descartada
      • Erros de saída de pacotes
      • Pacotes recebidos descartados
      • Erros de pacotes recebidos
      • Pacotes recebidos desconhecidos
    • Atividade da placa de interface da rede por processador
      • Indicações de recebimento de recursos baixas por segundo
      • Poucos pacotes recebidos de recursos por segundo
    • Processador
      • % do tempo de interrupção
      • % de tempo privilegiado
      • % de tempo do processador
      • % do tempo do usuário

O Pefmon permite traçar os contadores anterior em um gráfico de série temporal. Pode ser útil observar isso quando ocorrer um teste ou quando um servidor estiver afetado. Picos em contadores relacionados à CPU, como tempo de interrupção e tempo privilegiado, podem indicar problemas de saturação à medida que a VM atingir as limitações de capacidade da CPU. Erros de descarte e erros de pacotes podem ocorrer quando a CPU estiver saturada, o que força a perda de pacotes antes de serem processados pelos soquetes do cliente ou do servidor. Por fim, o tamanho da fila de saída também aumentará durante a saturação da CPU à medida que mais pacotes forem colocados na fila para processamento.

Windows Powershell

PS C:\> netstat -s
IPv4 Statistics

  Packets Received                   = 56183
  Received Header Errors             = 0
  Received Address Errors            = 0
  Datagrams Forwarded                = 0
  Unknown Protocols Received         = 0
  Received Packets Discarded         = 25
  Received Packets Delivered         = 56297
  Output Requests                    = 47994
  Routing Discards                   = 0
  Discarded Output Packets           = 0
  Output Packet No Route             = 0
  Reassembly Required                = 0
  Reassembly Successful              = 0
  Reassembly Failures                = 0
  Datagrams Successfully Fragmented  = 0
  Datagrams Failing Fragmentation    = 0
  Fragments Created                  = 0

O comando netstat gera estatísticas de rede que contêm valores de pacotes descartados por protocolo. Os pacotes descartados podem ser resultado do esgotamento de recursos pelo aplicativo ou pela interface da rede.

Em caso de esgotamento de recursos, tente espalhar a carga de trabalho em mais instâncias fazendo upgrade da VM para uma com mais recursos, ajustando o sistema operacional ou o aplicativo para necessidades específicas de desempenho, inserindo a mensagem de erro em um mecanismo de pesquisa para procurar soluções possíveis ou solicite ajuda usando um dos métodos descritos em Se os problemas persistirem.

Se o esgotamento de recursos não parecer ser o problema, o problema pode ser com o próprio software servidor. Para orientações sobre como solucionar problemas de software servidor, prossiga para Verificar a geração de registros do servidor para mais informações sobre o comportamento do servidor.

Verificar a geração de registros do servidor para mais informações sobre o comportamento do servidor

Se as etapas anteriores não revelarem um problema, os tempos limite poderão ser causados pelo aplicativo, como interrupções de processamento causadas pelo esgotamento da vCPU. Verifique os registros do servidor e dos aplicativos para ver indicações do comportamento com que está lidando.

Por exemplo, um servidor com latência maior devido a um sistema upstream, como um banco de dados sob carga, pode enfileirar uma quantidade excessiva de solicitações que podem causar maior uso de memória e tempos de espera da CPU. Esses fatores podem resultar em conexões com falha ou sobrecarga do buffer de soquete.

Às vezes, as conexões TCP perdem um pacote, mas o reconhecimento seletivo e a retransmissão de pacotes geralmente recuperam pacotes perdidos, evitando o tempo limite da conexão. Considere que os tempos limite podem ter sido o resultado da falha ou reimplantação do servidor de aplicativos, causando uma falha temporária nas conexões.

Se o aplicativo do servidor depende de uma conexão com um banco de dados ou outro serviço, confirme se os serviços acoplados não estão tendo um desempenho insatisfatório. O aplicativo pode rastrear essas métricas.

Se os problemas persistirem

Se os problemas persistirem, consulte Como receber suporte para ver as próximas etapas. É útil que a saída das etapas de solução de problemas esteja disponível para compartilhar com outros colaboradores.

A seguir

  • Se os problemas persistirem, consulte a página Suporte.