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.
Se você quiser ver outros cenários específicos de solução de problemas, clique no link Enviar feedback na parte inferior da página e informe-nos.
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
- Se achar que é o caso de perda total de pacotes, acesse Resolver problemas de falha de conexão completa.
- Se você estiver enfrentando latência, apenas perda parcial de pacote ou tempos limite ocorrendo no meio da conexão, acesse Resolver problemas de latência ou perda de rede que causam problemas de capacidade de processamento.
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, você não precisará da porta de origem da conexão.
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:
No console do Google Cloud, acesse a página Testes de conectividade.
No menu suspenso do projeto, confirme se você está no projeto correto ou especifique o correto.
Clique em Criar teste de conectividade.
Dê um nome ao teste.
Especifique o seguinte:
- Protocolo
- Endereço IP do endpoint de origem
- Projeto de origem e rede VPC
- Endereço IP do endpoint de destino
- Projeto de destino e rede VPC
- Porta de destino
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:
- Verifique a lista Tráfego sempre bloqueado. Se o tráfego estiver bloqueado pelo Google Cloud, conforme descrito na lista de tráfego sempre bloqueado, a configuração existente não funcionará.
- Acesse a página de políticas de "Firewall" e revise as regras de firewall. Se o firewall estiver configurado incorretamente, crie ou modifique uma regra de firewall para permitir a conexão. Essa regra pode ser uma regra de firewall VPC ou uma política de firewall hierárquica.
- 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
No Console do Google Cloud, acesse a página Firewall.
Verifique se há uma regra de firewall que permita conexões SSH pelo IAP com a VM ou crie uma nova.
No console do Google Cloud, acesse a página Instâncias de VMs.
Encontre a VM de origem.
Clique em SSH na coluna Conectar para essa VM.
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
No console do Google Cloud, acesse a página Instâncias de VMs.
Encontre a VM de origem.
Use um dos métodos descritos em Como conectar-se às VMs do Windows para se conectar à VM.
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)`
- Windows 2019:
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 acima não resolverem o problema, prossiga para Verificar o firewall no cliente e no servidor em busca de pacotes descartados.
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 as regras de firewall não parecerem ser 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 as rotas não parecerem ser o problema, prossiga para Verificar 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 corresponderem, é possível reconfigurar a 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 acima não resolverem um problema, pode ser que o aplicativo esteja 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:
- Cloud Logging para a VM;
- Registros seriais da VM;
- Syslog e kern.log do Linux ou Visualizador de eventos do Windows.
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 acima esteja disponível para compartilhar com outros colaboradores.
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, você não precisará da porta de origem da conexão.
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 corresponderem, é possível reconfigurar a 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:
No Console do Google Cloud, acesse a página Logging.
Escolha o período de ocorrência da latência.
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
Use o comando
netstatpara ver estatísticas de rede.$ netstat -sTcpExt: 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.
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_maxou espalhando uma carga de trabalho de VMs por várias VMs para reduzir a carga.
IU do Windows
Perfmon
- Usando o menu do Windows, procure "perfmon" e abra o programa.
- No menu à esquerda, selecione Desempenho > Ferramentas de monitoramento > Monitor de desempenho.
- 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 baixos/segundo
- Pacotes de recurso baixo recebidos/segundo
- Processador
- % do tempo de interrupção
- % de tempo privilegiado
- % de tempo do processador
- % do tempo do usuário
- Adaptador de rede
O Pefmon permite traçar os contadores acima em um gráfico de série temporal. Pode ser útil observar isso quando ocorrer um teste ou quando um servidor estiver afetado no momento. 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 acima não revelarem um problema, os tempos limite poderão ser causados pelo comportamento do 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.