Resolva problemas de conetividade interna entre VMs
Este documento fornece passos de resolução de problemas para problemas de conetividade entre VMs do Compute Engine que estão na mesma rede da nuvem virtual privada (VPC) (VPC partilhada ou autónoma) ou duas redes da VPC ligadas com o intercâmbio da rede da VPC. Parte do princípio de que as VMs estão a comunicar através dos endereços IP internos dos respetivos controladores de interface da rede virtual (vNICs).
Os passos deste guia aplicam-se às VMs do Compute Engine e aos nós do Google Kubernetes Engine.
Se quiser ver cenários de resolução de problemas adicionais específicos, clique no link Enviar feedback na parte inferior da página e informe-nos.
As seguintes configurações de VM e VPC são aplicáveis a este guia:
- Ligações de VM para VM através de endereços IP internos numa única rede VPC.
- Ligações de VM para VM através de endereços IP internos numa rede de VPC partilhada.
- Ligações de VM para VM que usam endereços IP internos em diferentes redes VPC com peering através do peering de redes VPC.
Os comandos usados neste guia estão disponíveis em todas as imagens do SO fornecidas pela Google. Se estiver a usar a sua própria imagem do SO, pode ter de instalar as ferramentas.
Quantifique o problema
- Se considerar que tem uma perda de pacotes completa, aceda ao artigo Resolva problemas de falha de ligação completa.
- Se estiver a ter problemas de latência, perda de pacotes parcial ou limites de tempo esgotados durante a ligação, aceda ao artigo Resolva problemas de latência ou perda de rede que causam problemas de débito.
Resolva problemas de falha de ligação completa
As secções seguintes fornecem passos para resolver problemas de falha de conetividade interna completa entre VMs. Se, em alternativa, estiver a ter um aumento da latência ou limites de tempo de ligação intermitentes, avance para a secção Resolva problemas de latência ou perda de rede que causam problemas de débito.
Determine os valores de ligação
Primeiro, reúna as seguintes informações:
- Na página Instâncias de VM,
reúna as seguintes informações para ambas as VMs:
- Nomes das VMs
- Zonas de VMs
- Endereços IP internos das vNICs que estão a comunicar
A partir da configuração do software do servidor de destino, recolha as seguintes informações:
- Protocolo de camada 4
- Porta de destino
Por exemplo, se o seu destino for um servidor HTTPS, o protocolo é TCP e a porta é normalmente
443, mas a sua configuração específica pode usar uma porta diferente.
Se estiver a ter problemas com várias VMs, escolha uma única VM de origem e de destino que estejam a ter problemas e use esses valores. Em geral, não deve precisar da porta de origem da ligação.
Assim que tiver estas informações, avance para a secção Investigue problemas com a rede Google subjacente.
Investigue problemas com a rede Google subjacente
Se a sua configuração for uma configuração existente que não foi alterada recentemente, o problema pode estar na rede Google subjacente. Verifique o Network Intelligence Center Painel de controlo de desempenho para perda de pacotes entre as zonas de VMs. Se houver um aumento na perda de pacotes entre as zonas durante o período em que teve problemas de tempo limite de rede, pode indicar que o problema estava na rede física subjacente à sua rede virtual. Verifique o painel de controlo do estado do Google Cloud para ver se existem problemas conhecidos antes de registar um pedido de apoio técnico.
Se o problema não parecer estar relacionado com a rede Google subjacente, avance para a secção Verifique se existem regras de firewall Google Cloud mal configuradas.
Verifique se existem regras de firewall configuradas incorretamente no Google Cloud
Os testes de conetividade analisam a configuração do caminho da rede VPC entre duas VMs e mostram se a configuração programada deve permitir o tráfego ou não. Se o tráfego não for permitido, os resultados mostram se uma Google Cloud regra de firewall de saída ou de entrada está a bloquear o tráfego ou se não está disponível uma rota.
Os testes de conetividade também podem testar dinamicamente o caminho enviando pacotes entre os hipervisores das VMs. Se estes testes forem realizados, os resultados dos mesmos são apresentados.
Os testes de conetividade examinam apenas a configuração da rede VPC. Não testa a firewall do sistema operativo, as rotas do sistema operativo nem o software do servidor na VM.
O procedimento seguinte executa testes de conetividade a partir da Google Cloud consola. Para outras formas de executar testes, consulte o artigo Executar testes de conetividade.
Use o procedimento seguinte para criar e executar um teste:
Na Google Cloud consola, aceda à página Testes de conetividade.
No menu pendente do projeto, confirme se está no projeto correto ou especifique o correto.
Clique em Criar teste de conetividade.
Atribua um nome ao teste.
Especifique o seguinte:
- Protocolo
- Endereço IP do ponto final de origem
- Projeto de origem e rede VPC
- Endereço IP do ponto final 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 Ver na coluna Detalhes dos resultados.
- Se os resultados indicarem que a ligação foi rejeitada por uma regra de firewall, determine se a configuração de segurança pretendida deve permitir a ligação. Google CloudPode ter de pedir detalhes ao seu administrador de segurança ou de rede. Se o tráfego deve ser permitido, verifique o seguinte:
- Consulte a lista Tráfego sempre bloqueado. Se o tráfego for bloqueado Google Cloud conforme descrito na lista de tráfego sempre bloqueado, a sua configuração existente não vai funcionar.
- Aceda à página Políticas de firewall e reveja as regras da firewall. Se a firewall estiver configurada incorretamente, crie ou modifique uma regra da firewall para permitir a ligação. Esta regra pode ser uma regra de firewall da VPC ou uma regra de política de firewall hierárquica.
- Se existir uma regra de firewall configurada corretamente que bloqueie este tráfego, contacte o administrador de segurança ou de rede. Se os requisitos de segurança da sua organização significarem que as VMs não devem alcançar-se entre si, pode ter de reformular a sua configuração.
- Se os resultados indicarem que não existem problemas com o caminho de conetividade da VPC, o problema pode ser um dos seguintes.
- Problemas com a configuração do SO convidado, como problemas com o software de firewall.
- Problemas com as aplicações cliente ou servidor, como a aplicação estar bloqueada ou configurada para ouvir na porta errada.
Os passos seguintes explicam como examinar cada uma destas possibilidades. Continue com o teste da conetividade TCP a partir do interior da VM.
Teste a conetividade TCP a partir do interior da VM
Se o teste de conetividade VM-VM não detetou um problema de configuração da VPC, comece a testar a conetividade SO-SO. Os passos seguintes ajudam a determinar o seguinte:
- Se um servidor TCP estiver a ouvir na porta indicada
- Se o software de firewall do lado do servidor estiver a permitir ligações a essa porta a partir da VM do cliente
- Se o software de firewall do lado do cliente estiver a permitir ligações a essa porta no servidor
- Se a tabela de rotas do lado do servidor estiver configurada corretamente para encaminhar pacotes
- Se a tabela de encaminhamento do lado do cliente estiver configurada corretamente para encaminhar pacotes
Pode testar o handshake TCP com curl no Linux ou no Windows 2019, ou
com o comando New-Object System.Net.Sockets.TcpClient no Windows
Powershell. O fluxo de trabalho nesta secção deve resultar num dos seguintes
resultados: ligação bem-sucedida, tempo limite da ligação ou reposição da ligação.
- Êxito: se a negociação TCP for concluída com êxito, significa que uma regra da firewall do SO não está a bloquear a ligação, o SO está a encaminhar pacotes corretamente e um servidor de algum tipo está a ouvir na porta de destino. Se for o caso, o problema pode estar relacionado com a própria aplicação. Para verificar, consulte o artigo Verifique o registo do servidor para obter informações sobre o comportamento do servidor.
- Limite de tempo: se a ligação atingir o limite de tempo, significa normalmente uma das seguintes situações:
- Não existe nenhuma máquina nesse endereço IP
- Existe uma firewall a rejeitar silenciosamente os seus pacotes
- O encaminhamento de pacotes do SO está a enviar os pacotes para um destino que não os consegue processar, ou o encaminhamento assimétrico está a enviar o pacote de retorno num caminho inválido
Reposição: se a ligação estiver a ser reposta, significa que o IP de destino está a receber pacotes, mas um SO ou uma aplicação está a rejeitar os pacotes. Isto pode significar uma das seguintes situações:
- Os pacotes estão a chegar à máquina errada e não está configurada para responder a esse protocolo nessa porta
- Os pacotes estão a chegar à máquina correta, mas não existe nenhum servidor a ouvir nessa porta
- Os pacotes estão a chegar à máquina e à porta corretas, mas os protocolos de nível superior (como o SSL) não estão a concluir a respetiva negociação
- Uma firewall está a repor a ligação. Isto é menos provável do que um firewall descartar os pacotes silenciosamente, mas pode acontecer.
Linux
Na Google Cloud consola, aceda à página Políticas de firewall.
Certifique-se de que existe uma regra de firewall que permita ligações SSH do IAP à sua VM ou crie uma nova.
Na Google Cloud consola, aceda à página Instâncias de VM.
Encontre a VM de origem.
Clique em SSH na coluna Ligar dessa VM.
Na linha de comandos do computador cliente, execute o seguinte comando. 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
Na Google Cloud consola, aceda à página Instâncias de VM.
Encontre a VM de origem.
Use um dos métodos descritos no artigo Estabelecer ligação a VMs do Windows para estabelecer ligação à sua VM.
Na linha de comandos do computador cliente, execute o seguinte:
- 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:
Êxito na ligação
Os seguintes resultados indicam uma negociação TCP bem-sucedida. Se o handshake TCP for concluído com êxito, o problema não está relacionado com o limite de tempo ou a reposição da ligação TCP. Em alternativa, o problema de limite de tempo está a ocorrer nas camadas da aplicação. Se a ligação for bem-sucedida, avance para Verifique o registo do servidor para obter 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 "Ligado a" indica uma confirmação de TCP bem-sucedida.
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 ligação estabelecida com êxito. A linha "Connected: True" é 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
Limite de tempo da ligação
Os resultados seguintes indicam que a ligação excedeu o tempo limite. Se a ligação estiver a atingir o limite de tempo, avance para Validar 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 do limite de tempo da ligaçã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 do limite de tempo da ligaçã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"
Ligação reposta
Uma reposição ocorre quando um dispositivo envia um pacote RST de volta ao cliente, informando-o de que a ligação foi terminada. A ligação pode ser reposta por um dos seguintes motivos:
- O servidor de receção não foi configurado para aceitar ligações para esse protocolo nessa porta. Isto pode dever-se ao facto de o pacote ter sido enviado para o servidor ou a porta errados, ou o software do servidor ter sido configurado incorretamente.
- O software de firewall rejeitou a tentativa de ligação
Se a ligação foi reposta, avance para Verifique se está a aceder ao endereço IP e à porta corretos.
Linux e Windows 2019
$ curl -vso /dev/null --connect-timeout 5 DEST_IP_ADDRESS:PORT
Resultado da reposição da ligaçã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 da reposição da ligaçã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"
Valide o endereço IP e a porta do servidor
Execute um dos seguintes comandos no seu servidor. Indicam se existe um servidor a ouvir na porta necessária.
Linux
$ sudo netstat -ltuvnp
O resultado mostra que um servidor TCP está a ouvir qualquer endereço IP de destino (0.0.0.0) na porta 22, aceitando ligações de qualquer endereço de origem (0.0.0.0) e qualquer porta de origem (*). A coluna PID/Nome do programa especifica o executável associado ao socket.
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
O resultado mostra os resultados do comando executado com DEST_PORT definido como 443.
Este resultado mostra que um servidor TCP está a ouvir qualquer endereço (0.0.0.0) na porta 443, aceitando ligaçõ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 está a ouvir 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 vir que o servidor não está associado à porta ou ao IP correto, ou que o prefixo remoto não corresponde ao seu cliente, consulte a documentação ou o fornecedor do servidor para resolver o problema. O servidor tem de estar associado ao endereço IP de uma interface específica ou a 0.0.0.0 e tem de aceitar ligações do prefixo IP do cliente correto ou de 0.0.0.0.
Se o servidor de aplicações estiver associado ao endereço IP e à porta corretos, é possível que o cliente esteja a aceder à porta errada, que um protocolo de nível superior (frequentemente TLS) esteja a recusar ativamente a ligação ou que exista uma firewall a rejeitar a ligação.
Verifique se o cliente e o servidor estão a usar a mesma versão do TLS e a mesma formação de encriptação.
Verifique se o cliente está a aceder à porta correta.
Se os passos anteriores não resolverem o problema, avance para a secção Verifique se a firewall no cliente e no servidor rejeita pacotes.
Verifique se a firewall no cliente e no servidor rejeita pacotes
Se o servidor estiver inacessível a partir da VM do cliente, mas estiver a ouvir na porta correta, uma das VMs pode estar a executar software de firewall que está a rejeitar pacotes associados à ligação. Verifique a firewall nas VMs do cliente e do servidor através dos seguintes comandos.
Se uma regra estiver a bloquear o seu tráfego, pode atualizar o software de firewall para permitir o tráfego. Se atualizar a firewall, proceda com cautela ao preparar e executar os comandos, uma vez que uma firewall configurada incorretamente pode bloquear tráfego inesperado. Considere configurar o acesso à consola série de VMs antes de continuar.
Linux iptables
Verifique as contagens de pacotes para o número de pacotes processados para cada regra e cadeia de iptables instalada. Determine a que regras DROP está a ser feita a correspondência comparando os endereços IP e as portas de origem e destino com os prefixos e as portas especificados pelas regras iptables.
Se uma regra correspondente estiver a apresentar um aumento das rejeições com limites de tempo de ligação, consulte a documentação do iptables para aplicar a regra allow correta às ligações adequadas.
$ sudo iptables -L -n -v -x
Esta cadeia INPUT de exemplo mostra que os pacotes de qualquer endereço IP para qualquer endereço IP
que use a porta TCP de destino 5000 são rejeitados na firewall.
A coluna pkts indica que a regra rejeitou 10 342 pacotes. Como teste, se criar ligações que sejam rejeitadas por esta regra, verá o contador de pacotes aumentar, o que confirma 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
Pode adicionar uma regra de entrada ou saída a 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 na firewall do Windows se a ligação tem permissão para sair do cliente e entrar no servidor. Se uma regra estiver a bloquear o seu tráfego, faça as correções necessárias na firewall do Windows para permitir as ligações. Também pode ativar o registo da Firewall do Windows.
O comportamento predefinido de REJEITAR do Firewall do Windows é rejeitar silenciosamente os pacotes, o que resulta em tempos limite.
Este comando verifica o servidor. Para verificar as regras de saída na VM do cliente, altere o valor de -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
Pode adicionar novas regras de firewall ao Windows com os seguintes comandos.
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
As firewalls de aplicações de terceiros ou o software antivírus também podem rejeitar ou interromper ligações. Consulte a documentação fornecida pelo seu fornecedor.
Se encontrar um problema com as regras da firewall e o corrigir, volte a testar a conetividade. Se as regras da firewall não parecerem ser o problema, avance para a secção Verifique a configuração do encaminhamento do SO.
Verifique a configuração de encaminhamento do SO
Os problemas de encaminhamento do sistema operativo podem resultar de uma das seguintes situações:
- Os problemas de encaminhamento são mais comuns em VMs com várias interfaces de rede devido à complexidade de encaminhamento adicional
- Numa VM criada no Google Cloud com uma única interface de rede, os problemas de encaminhamento ocorrem normalmente apenas se alguém tiver modificado manualmente a tabela de encaminhamento predefinida
- Numa VM migrada das instalações, a VM pode transferir definições de encaminhamento ou MTU necessárias nas instalações, mas que estão a causar problemas na rede VPC
Se estiver a usar uma VM com várias interfaces de rede, as rotas têm de ser configuradas para sair para a vNIC e a sub-rede corretas. Por exemplo, uma VM pode ter rotas configuradas para que o tráfego destinado a sub-redes internas seja enviado para uma vNIC, mas o gateway predefinido (destino 0.0.0.0/0) está configurado noutra vNIC que tem um endereço IP externo ou acesso ao Cloud NAT.
Pode rever as rotas verificando as rotas individuais uma de cada vez ou consultando toda a tabela de encaminhamento da VM. Se qualquer uma das abordagens revelar problemas com a tabela de encaminhamento, consulte os passos em Atualize as tabelas de encaminhamento, se necessário para obter instruções.
Reveja todos os trajetos
Liste todos os seus trajetos para compreender que trajetos já existem na sua 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
Verifique rotas individuais
Se um prefixo IP específico parecer ser o problema, verifique se existem trajetos adequados para os IPs de origem e de destino nas VMs do cliente e do servidor.
Linux
$ ip route get DEST_IP
Bom resultado:
É apresentado um trajeto válido. Neste 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
Mau resultado:
Este resultado confirma que os pacotes estão a ser rejeitados porque não existe um caminho para a rede de destino. Confirme se a sua tabela de encaminhamento contém um caminho para a interface de saída correta.
**RTNETLINK answers: Network is unreachable
Windows
PS C:\> Find-NetRoute -RemoteIpAddress "DEST_IP"
Bom resultado:
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
Mau resultado:
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
Este comando confirma que os pacotes estão a ser rejeitados porque não existe um caminho para o endereço IP de destino. Verifique se tem um gateway predefinido e se o gateway está aplicado à vNIC e à rede corretas.
Atualize as tabelas de encaminhamento
Se necessário, pode adicionar uma rota à tabela de rotas do sistema operativo. Antes de executar um comando para atualizar a tabela de encaminhamento da VM de encaminhamento, recomendamos que se familiarize com os comandos e desenvolva uma compreensão das possíveis implicações. A utilização inadequada de comandos de atualização de rotas pode causar problemas inesperados ou a desativação da ligação à VM. Considere configurar o acesso à consola série de VMs antes de continuar.
Consulte a documentação do sistema operativo para ver instruções sobre como atualizar rotas.
Se encontrar um problema com as rotas e o corrigir, teste novamente a conetividade. Se as rotas não parecerem ser o problema, avance para Verificar MTU da interface.
Verifique a MTU
O MTU da interface de uma VM deve corresponder ao MTU da rede VPC à qual está anexada. Idealmente, as VMs que comunicam entre si também têm MTUs correspondentes. Normalmente, as MTUs não correspondentes não são um problema para o TCP, mas podem ser para o UDP.
Verifique a MTU da VPC. Se as VMs estiverem em duas redes diferentes, verifique ambas as redes.
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) tem sempre um MTU de 65536 e pode ser ignorada para este passo.
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 têm sempre uma MTU de 4294967295 e podem ser ignoradas para este passo.
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, pode reconfigurar a MTU da interface. Para mais informações, consulte o artigo VMs e definições de MTU. Se corresponderem e tiver seguido os passos de resolução de problemas até agora, o problema é provavelmente com o próprio servidor. Para orientações sobre a resolução de problemas do servidor, avance para Verifique o registo do servidor para obter informações sobre o comportamento do servidor.
Verifique o registo do servidor para obter informações sobre o comportamento do servidor
Se os passos anteriores não resolverem um problema, a aplicação pode estar a causar os limites de tempo. Verifique os registos do servidor e da aplicação para ver se existe algum comportamento que explique o que está a ver.
Origens dos registos a verificar:
- Cloud Logging para a VM
- Registos de série da VM
- Syslog e kern.log do Linux ou Event Viewer do Windows
Se continuar a ter problemas
Se continuar a ter problemas, consulte a secção Obter apoio técnico para ver os passos seguintes. É útil ter o resultado dos passos de resolução de problemas anteriores disponível para partilhar com outros colaboradores.
Resolva problemas de latência ou perda de rede que causam problemas de débito
Normalmente, os problemas de latência ou perda de rede são causados por esgotamento de recursos ou gargalos num caminho de rede ou numa VM. Ocasionalmente, a perda de rede pode causar limites de tempo de ligação intermitentes. Causas como o esgotamento da vCPU ou a saturação da vNIC resultam num aumento da latência e na perda de pacotes, o que leva a uma redução no desempenho da rede.
As instruções seguintes pressupõem que as ligações não estão a expirar constantemente e que, em vez disso, está a ver problemas de capacidade ou desempenho limitados. Se estiver a ver uma perda de pacotes completa, consulte o artigo Resolva problemas de falha de ligação completa.
As pequenas variações na latência, como as latências que variam alguns milissegundos, são normais. As latências variam devido à carga da rede ou à colocação em fila dentro da VM.
Determine os valores de ligação
Primeiro, reúna as seguintes informações:
- Na página Instâncias de VM,
reúna as seguintes informações para ambas as VMs:
- Nomes das VMs
- Zonas de VMs
- Endereços IP internos das vNICs que estão a comunicar
- A partir da configuração do software do servidor de destino, recolha as
seguintes informações:
- Protocolo de camada 4
- Porta de destino
Se estiver a ter problemas com várias VMs, escolha uma única VM de origem e de destino que estejam a ter problemas e use esses valores. Em geral, não deve precisar da porta de origem da ligação.
Assim que tiver estas informações, avance para a secção Investigue problemas com a rede Google subjacente.
Investigue problemas com a rede Google subjacente
Se a sua configuração for uma configuração existente que não foi alterada recentemente, o problema pode estar na rede Google subjacente. Verifique o Network Intelligence Center Painel de controlo de desempenho para perda de pacotes entre as zonas de VMs. Se houver um aumento na perda de pacotes entre as zonas durante o período em que teve tempos limite de rede, pode indicar que o problema está na rede física subjacente à sua rede virtual. Verifique o painel de controlo do estado do Google Cloud para ver se existem problemas conhecidos antes de registar um pedido de apoio técnico.
Se o problema não parecer estar relacionado com a rede Google subjacente, avance para a secção Verifique a latência da confirmação.
Verifique a latência de sincronização
Todos os protocolos baseados em ligações incorrem em alguma latência enquanto fazem a confirmação da configuração da ligação. Cada sincronização de protocolo aumenta a sobrecarga. Para as ligações SSL/TLS, por exemplo, o handshake TCP tem de ser concluído antes de o handshake SSL/TLS poder começar. Em seguida, o handshake TLS tem de ser concluído antes de os dados poderem ser transmitidos.
Normalmente, a latência de handshake na mesma Google Cloud zona é insignificante, mas os handshakes para localizações distantes a nível global podem adicionar maiores atrasos no início da ligação. Se tiver recursos em regiões distantes, pode verificar se a latência que está a observar se deve à sincronização de protocolos.
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é ao momento em que o cliente envia o ACK do TCP handshake.
- application_handshake é o tempo desde o primeiro pacote SYN do handshake TCP até à conclusão do handshake TLS (normalmente).
- tempo de handshake adicional = handshake_aplicação - handshake_tcp
Windows 2012 e 2016
Não disponível com as ferramentas do SO predefinidas. O tempo de ida e volta do ICMP pode ser usado como referência se as regras de firewall o permitirem.
Se a latência for superior à que seria de esperar com os handshakes, avance para a secção Determine o débito máximo do seu tipo de VM.
Determine o débito máximo do seu tipo de VM
A taxa de transferência de saída da rede de VMs é limitada pela arquitetura da CPU da VM e pela quantidade de vCPUs. Determine a largura de banda de saída potencial da sua VM consultando a página Largura de banda da rede.
Se a sua VM não for capaz de cumprir os requisitos de saída, considere atualizar para uma VM com maior capacidade. Para ver instruções, consulte o artigo Alterar o tipo de máquina de uma instância.
Se o tipo de máquina permitir largura de banda de saída suficiente, investigue se a utilização do disco persistente está a interferir com a saída da rede. As operações do disco persistente podem ocupar até 60% da capacidade de processamento total da rede da sua VM. Para determinar se as operações do disco persistente podem estar a interferir com a taxa de transferência da rede, consulte o artigo Verifique o desempenho do disco persistente.
A entrada na rede de uma VM não é limitada pela rede da VPC nem pelo tipo de instância de VM. Em alternativa, é determinado pelo desempenho de processamento e colocação em fila de pacotes do sistema operativo ou da aplicação da VM. Se a largura de banda de saída for adequada, mas estiver a ter problemas de entrada, consulte o artigo Verifique o registo do servidor para obter informações sobre o comportamento do servidor.
Verifique o MTU da interface
A MTU de uma rede VPC é configurável. A MTU da interface na VM deve corresponder ao valor da MTU da rede VPC à qual está associada. Numa situação de interligação de redes VPC, as VMs em redes diferentes podem ter MTUs diferentes. Quando este cenário ocorre, aplique o valor de MTU mais pequeno às interfaces associadas. Normalmente, as incompatibilidades de MTU não são um problema para o TCP, mas podem ser para o UDP.
Verifique a MTU da VPC. Se as VMs estiverem em duas redes diferentes, verifique ambas as redes.
gcloud compute networks describe NET_NAME --format="table(name,mtu)"
Verifique a configuração da MTU para a sua interface de rede.
Linux
A interface lo (loopback) tem sempre um MTU de 65536 e pode ser ignorada para este passo.
$ 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 têm sempre uma MTU de 4294967295 e podem ser ignoradas para este passo.
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, pode reconfigurar a MTU da interface. Para ver instruções sobre como atualizar a MTU para VMs do Windows, consulte o artigo VMs e definições de MTU. Se corresponderem, o problema pode estar relacionado com a disponibilidade do servidor. O passo seguinte é verificar os registos para ver se uma VM foi reiniciada, parada ou migrada em direto para ver se aconteceu alguma coisa à sua VM durante o período relevante.
Verifique os registos para ver se uma VM foi reiniciada, parada ou migrada em direto
Durante o ciclo de vida de uma VM, esta pode ser reiniciada pelo utilizador, migrada em direto para Google Cloud manutenção ou, em circunstâncias raras, pode ser perdida e recriada se ocorrer uma falha no anfitrião físico que contém a sua VM. Estes eventos podem causar um breve aumento na latência ou nos limites de tempo de ligação. Se alguma destas situações acontecer à MV, o evento é registado.
Para ver os registos da sua VM, faça o seguinte:
Na Google Cloud consola, aceda à página Registo.
Escolha o período em que a latência ocorreu.
Use a seguinte consulta de registo para determinar se ocorreu um evento de VM perto do período em que ocorreu a latência:
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 foram reiniciadas nem migradas durante o período relevante, o problema pode estar relacionado com o esgotamento de recursos. Para verificar, aceda a Verifique as estatísticas do SO e da rede para ver se existem rejeições de pacotes devido ao esgotamento de recursos.
Verifique as estatísticas do SO e da rede para ver se existem pacotes rejeitados devido ao esgotamento de recursos
O esgotamento de recursos é um termo geral que significa que é pedido a um recurso na VM, como a largura de banda de saída, que processe mais do que consegue. O esgotamento de recursos pode resultar na rejeição periódica de pacotes, o que causa latência de ligação ou limites de tempo. Estes limites de tempo podem não ser visíveis no início do cliente ou do servidor, mas podem aparecer ao longo do tempo à medida que um sistema esgota os recursos.
Segue-se uma lista de comandos que apresentam contadores de pacotes e estatísticas. Alguns destes comandos duplicam os resultados de outros comandos. Nestes casos, pode usar o comando que funcionar melhor para si. Consulte as notas em cada secção para compreender melhor o resultado pretendido da execução do comando. Pode ser útil executar os comandos em momentos diferentes para ver se as rejeições ou os erros ocorrem 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 produz estatísticas de rede que contêm valores para pacotes rejeitados por protocolo. Os pacotes rejeitados podem ser o resultado do esgotamento de recursos pela aplicação ou pela interface de rede. Veja o motivo do contador para saber por que motivo um contador foi incrementado.
Verifique se existem registos correspondentes a
nf_conntrack: table full, dropping packetno kern.log.Debian:
cat /var/log/kern.log | grep "dropping packet"CentOS:
sudo cat /var/log/dmesg | grep "dropping packet"Este registo indica que a tabela de acompanhamento de ligações para a VM atingiu o número máximo de ligações que podem ser acompanhadas. As ligações adicionais a esta VM e a partir desta podem atingir o limite de tempo. Se o conntrack tiver sido ativado, pode encontrar a contagem máxima de ligações com:
sudo sysctl net.netfilter.nf_conntrack_maxPode aumentar o valor das ligações rastreadas máximas modificando o sysctl
net.netfilter.nf_conntrack_maxou distribuindo uma carga de trabalho de VMs por várias VMs para reduzir a carga.
IU do Windows
Perfmon
- No menu do Windows, pesquise "perfmon" e abra o programa.
- No menu do lado esquerdo, selecione Desempenho > Ferramentas de monitorização > Monitor de desempenho.
- Na vista principal, clique no sinal de mais verde "+" para adicionar contadores de desempenho ao gráfico de monitorização. Os seguintes contadores são de interesse:
- Adaptador de rede
- Comprimento da fila de saída
- Pacotes de saída rejeitados
- Erros de pacotes de saída
- Pacotes recebidos rejeitados
- Erros de pacotes recebidos
- Pacotes recebidos desconhecidos
- Interface de rede
- Comprimento da fila de saída
- Pacotes de saída rejeitados
- Erros de pacotes de saída
- Pacotes recebidos rejeitados
- Erros de pacotes recebidos
- Pacotes recebidos desconhecidos
- Atividade da placa de rede por processador
- Indicações de receção de recursos baixos por segundo
- Pacotes recebidos de recursos baixos por segundo
- Processador
- % Tempo de interrupção
- % de tempo privilegiado
- % Tempo do processador
- % de tempo do utilizador
- Adaptador de rede
O Pefmon permite-lhe traçar os contadores anteriores num gráfico de intervalos temporais. Isto pode ser útil para ver quando estão a ser realizados testes ou quando um servidor é afetado. Os picos nos contadores relacionados com a CPU, como o tempo de interrupção e o tempo privilegiado, podem indicar problemas de saturação à medida que a VM atinge as limitações de débito da CPU. Os erros e as rejeições de pacotes podem ocorrer quando a CPU está saturada, o que força a perda de pacotes antes de serem processados pelos soquetes do cliente ou do servidor. Por último, o comprimento da fila de saída também aumenta durante a saturação da CPU à medida que são colocados mais pacotes em 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 produz estatísticas de rede que contêm valores para pacotes rejeitados por protocolo. Os pacotes rejeitados podem ser o resultado do esgotamento de recursos pela aplicação ou pela interface de rede.
Se estiver a ver esgotamento de recursos, pode tentar distribuir a sua carga de trabalho por mais instâncias, atualizar a VM para uma com mais recursos, otimizar o SO ou a aplicação para necessidades de desempenho específicas, introduzir a mensagem de erro num motor de pesquisa para procurar possíveis soluções ou pedir ajuda através de um dos métodos descritos em Se continuar a ter problemas.
Se o esgotamento de recursos não parecer ser o problema, o problema pode estar no próprio software do servidor. Para orientações sobre a resolução de problemas de software do servidor, aceda a Verifique o registo do servidor para obter informações sobre o comportamento do servidor.
Verifique o registo do servidor para obter informações sobre o comportamento do servidor
Se os passos anteriores não revelarem um problema, os limites de tempo podem ser causados pelo comportamento da aplicação, como paragens de processamento causadas pelo esgotamento da vCPU. Verifique os registos do servidor e das aplicações para ver indicações do comportamento que está a experienciar.
Por exemplo, um servidor com um aumento da latência devido a um sistema a montante, como uma base de dados sob carga, pode colocar em fila uma quantidade excessiva de pedidos, o que pode provocar um aumento da utilização da memória e dos tempos de espera da CPU. Estes fatores podem resultar em ligações falhadas ou excesso de capacidade do buffer de soquetes.
As ligações TCP perdem ocasionalmente um pacote, mas o reconhecimento seletivo e a retransmissão de pacotes recuperam normalmente os pacotes perdidos, evitando o limite de tempo da ligação. Em alternativa, considere que os limites de tempo podem ter sido o resultado da falha ou da reimplementação do servidor de aplicações, o que causou uma falha momentânea nas ligações.
Se a sua aplicação de servidor depender de uma ligação a uma base de dados ou a outro serviço, confirme que os serviços associados não estão a ter um desempenho fraco. A sua aplicação pode acompanhar estas métricas.
Se continuar a ter problemas
Se continuar a ter problemas, consulte a secção Obter apoio técnico para ver os passos seguintes. É útil ter o resultado dos passos de resolução de problemas disponível para partilhar com outros colaboradores.
O que se segue?
- Se continuar a ter problemas, consulte a página Recursos.