Soluciona problemas de conectividad interna entre VMs

En este documento, se proporcionan pasos para solucionar problemas de conectividad entre VM de Compute Engine que se encuentran en la misma red de nube privada virtual (VPC), ya sea independiente o VPC compartida, o en dos redes de VPC conectadas con el intercambio de tráfico entre redes de VPC. Se asume que las VM se comunican mediante las direcciones IP internas de sus respectivos controladores de interfaz de red virtual (vNIC).

Los pasos de esta guía se aplican a las VM de Compute Engine y a los nodos de Google Kubernetes Engine.

Si quieres ver situaciones adicionales específicas de solución de problemas, haz clic en el vínculo Enviar comentarios en la parte inferior de la página para avisarnos.

Las siguientes configuraciones de VM y VPC se aplican a esta guía:

  • Conexiones de VM a VM mediante direcciones IP internas en una sola red de VPC
  • Conexiones de VM a VM mediante direcciones IP internas dentro de una red de VPC compartida
  • Conexiones de VM a VM mediante direcciones IP internas en diferentes redes de VPC con intercambio de tráfico entre redes de VPC.

Los comandos que se usan en esta guía están disponibles en todas las imágenes de SO que proporciona Google. Si usas tu propia imagen de SO, es posible que debas instalar las herramientas.

Cuantifica el problema

Soluciona problemas de falla de conexión completa

En las siguientes secciones, se proporcionan pasos para solucionar problemas de falla de conectividad interna completa entre VMs. En cambio, si experimentas un aumento de la latencia o tiempos de espera de conexión intermitentes, ve a Soluciona problemas de pérdida o latencia de red que causan problemas de capacidad de procesamiento.

Determina los valores de conexión

Primero, recopila la siguiente información:

  • En la página Instancia de VM, recopila lo siguiente para ambas VMs:
    • Nombres de las VM
    • Zonas de las VM
    • Direcciones IP internas para los vNIC que se comunican
  • Desde la configuración del software del servidor de destino, recopila la siguiente información:

    • Protocolo de capa 4
    • Puerto de destino

    Por ejemplo, si tu destino es un servidor HTTPS, el protocolo es TCP y el puerto suele ser 443, pero la configuración específica puede usar un puerto diferente.

Si tienes problemas con varias VM, elige una sola VM de origen y una de destino con problemas y usa esos valores. En general, no deberías necesitar el puerto de origen de la conexión.

Una vez que tengas esta información, continúa con Investiga problemas con la red de Google subyacente.

Investiga problemas con la red de Google subyacente

Si tu configuración es una existente que no ha cambiado recientemente, el problema podría ser con la red de Google subyacente. Consulta el Panel de rendimiento de Network Intelligence Center para obtener información sobre la pérdida de paquetes entre las zonas de las VM. Si hay un aumento en la pérdida de paquetes entre las zonas durante el período en el que experimentaste tiempos de espera de red, esto podría indicar que el problema fue con la red física que subyace en tu red virtual. Consulta el Panel de estado de Google Cloud para obtener información sobre problemas conocidos antes de presentar un caso de ayuda.

Si el problema parece no estar relacionado con la red de Google subyacente, ve a Verifica las reglas de firewall de Google Cloud mal configuradas.

Verifica las reglas de firewall de Google Cloud mal configuradas

Las pruebas de conectividad analizan la configuración de la ruta de acceso de la red de VPC entre dos VM y muestran si la configuración programada debe permitir o no el tráfico. Si el tráfico no está permitido, los resultados muestran si una regla de firewall de salida o entrada de Google Cloud bloquea el tráfico o si una ruta no está disponible.

Las pruebas de conectividad también pueden probar la ruta de forma dinámica mediante el envío de paquetes entre los hipervisores de las VM. Si se realizan estas pruebas, se muestran sus resultados.

Las pruebas de conectividad examinan la configuración solo de la red de VPC. No se prueba el firewall del sistema operativo, las rutas del sistema operativo ni el software del servidor en la VM.

En el siguiente procedimiento, se ejecutan pruebas de conectividad desde la consola de Google Cloud. Para conocer otras formas de ejecutar pruebas, consulta Ejecuta pruebas de conectividad.

Usa el siguiente procedimiento para crear y ejecutar una prueba:

  1. En la consola de Google Cloud, ve a la página Pruebas de conectividad.

    Ir a Pruebas de conectividad

  2. En el menú desplegable del proyecto, confirma que estés en el proyecto correcto o especifica el correcto.

  3. Haz clic en Crear prueba de conectividad.

  4. Asigna un nombre a la prueba.

  5. Especifique lo siguiente:

    1. Protocolo
    2. Dirección IP del extremo de origen
    3. Proyecto de origen y red de VPC
    4. Dirección IP del extremo de destino
    5. Proyecto de destino y red de VPC
    6. Puerto de destino
  6. Haga clic en Crear.

La prueba se ejecuta de inmediato. Para ver el diagrama de resultados, haz clic en Ver en la columna Detalles del resultado.

  • Si los resultados indican que una regla de firewall de Google Cloud descarta la conexión, determina si la configuración de seguridad deseada debe permitir la conexión. Es posible que debas consultar más detalles a tu administrador de seguridad o de red. Si se debe permitir el tráfico, verifica lo siguiente:
  • Si hay una regla de firewall configurada de forma correcta que bloquee este tráfico, consulta con tu administrador de seguridad o red. Si los requisitos de seguridad de tu organización implican que las VM no deben alcanzarse entre sí, es posible que debas rediseñar tu configuración.
  • Si los resultados indican que no hay problemas con la ruta de acceso de conectividad de VPC, el problema podría ser uno de los siguientes.
    • Problemas con la configuración del SO invitado, como problemas con el software de firewall
    • Problemas con aplicaciones del cliente o del servidor, como que la aplicación se congele o que esté configurada para escuchar en el puerto equivocado

En los pasos posteriores, se explica cada una de estas posibilidades. Continúa con Prueba la conectividad TCP desde la VM.

Prueba la conectividad TCP desde la VM

Si tu prueba de conectividad de VM a VM no detectó un problema de configuración de VPC, comienza a probar la conectividad de SO a SO. Los siguientes pasos te ayudarán a determinar lo siguiente:

  • Si un servidor TCP escucha en el puerto indicado
  • Si el software del firewall del servidor permite conexiones a ese puerto desde la VM del cliente
  • Si el software del firewall del cliente permite conexiones a ese puerto en el servidor
  • Si la tabla de ruta del servidor está configurada correctamente para reenviar paquetes
  • Si la tabla de ruta del cliente está configurada correctamente para reenviar paquetes

Puedes probar el protocolo de enlace TCP con curl con Linux o Windows 2019 o con el comando New-Object System.Net.Sockets.TcpClient con Windows PowerShell. El flujo de trabajo de esta sección debería generar uno de los siguientes resultados: éxito de la conexión, tiempo de espera de la conexión o restablecimiento de la conexión.

  • Éxito: Si el protocolo de enlace TCP se completa con éxito, una regla de firewall del SO no bloquea la conexión, el SO reenvía paquetes de forma correcta y un servidor de algún tipo escucha en el puerto de destino. Si este es el caso, el problema podría estar en la aplicación en sí. Si quieres verificarlo, consulta Verifica el registro del servidor para obtener información sobre su comportamiento.
  • Tiempo de espera: Si se agota el tiempo de espera de tu conexión, por lo general, significa una de las siguientes opciones:
    • No hay ninguna máquina en esa dirección IP
    • Hay un firewall que descarta tus paquetes de forma silenciosa
    • El enrutamiento de paquetes del SO envía los paquetes a un destino que no puede procesarlos, o el enrutamiento asimétrico envía el paquete de retorno en una ruta no válida
  • Restablecer: Si la conexión se está restableciendo, significa que la IP de destino recibe paquetes, pero un SO o una aplicación rechaza los paquetes. Esto puede tener uno de los siguientes significados:

    • Los paquetes llegan a la máquina incorrecta y esta no se configuró para responder a ese protocolo en ese puerto
    • Los paquetes llegan a la máquina correcta, pero ningún servidor está escuchando en ese puerto
    • Los paquetes llegan a la máquina y al puerto correctos, pero los protocolos de nivel superior (como SSL) no completan su protocolo de enlace
    • Un firewall está restableciendo la conexión. Esto es menos probable que un firewall que descarta los paquetes de forma silenciosa, pero puede ocurrir.

Linux

  1. En la consola de Google Cloud, ve a la página Firewall.

    Ir a Políticas de firewall

  2. Asegúrate de que haya una regla de firewall que permita conexiones SSH desde IAP a tu VM o crea una nueva.

  3. En la consola de Google Cloud, ve a la página Instancias de VM.

    Ir a Instancias de VM

  4. Busca la VM de origen.

  5. Haz clic en SSH, en la columna Conectar para esa VM.

  6. En la línea de comandos de la máquina cliente, ejecuta el siguiente comando. Reemplaza DEST_IP:DEST_PORT por tu dirección IP y puerto de destino.

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

Windows

  1. En la consola de Google Cloud, ve a la página Instancias de VM.

    Ir a Instancias de VM

  2. Busca la VM de origen.

  3. Usa uno de los métodos descritos en Conéctate a las VM de Windows para conectarte a la VM.

  4. Desde la línea de comandos de la máquina cliente, ejecuta el siguiente comando:

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

Se estableció correctamente la conexión

Los siguientes resultados indican un protocolo de enlace TCP exitoso. Si el protocolo de enlace TCP se completa con éxito, el problema no está relacionado con el tiempo de espera de conexión TCP o con el restablecimiento. En su lugar, el problema de tiempo de espera se produce dentro de las capas de la aplicación. Si obtienes una conexión exitosa, consulta Verifica el registro del servidor para obtener información sobre su comportamiento.

Linux y Windows 2019

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

La línea “Connected to” indica un protocolo de enlace TCP exitoso.

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 y 2016

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

Resultado correcto de la conexión. La línea “Connected: True” es 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

Tiempo de espera de la conexión

Los siguientes resultados indican que se agotó el tiempo de espera de la conexión. Si se agota el tiempo de espera de tu conexión, consulta Verifica la dirección IP y el puerto del servidor.

Linux y Windows 2019

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

Resultado del tiempo de espera de conexión:

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

Windows 2012 y 2016

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

Resultado del tiempo de espera de conexión:

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"

Restablecimiento de la conexión

Un restablecimiento es cuando un dispositivo envía un paquete de RST al cliente y, luego, informa al cliente que la conexión finalizó. La conexión puede restablecerse por uno de los siguientes motivos:

  • El servidor receptor no se configuró para aceptar conexiones para ese protocolo en ese puerto. Esto podría deberse a que el paquete se envió al servidor o al puerto equivocados, o el software del servidor se configuró de forma incorrecta.
  • El software de firewall rechazó el intento de conexión

Si se restableció la conexión, ve a Verifica que estás accediendo a la dirección IP y el puerto correctos.

Linux y Windows 2019

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

Resultado del restablecimiento de la conexión:

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 y 2016

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

Resultado del restablecimiento de la conexión:

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"

Verifica la dirección IP y el puerto del servidor

Ejecuta uno de los siguientes comandos en tu servidor. Indican si hay un servidor que escucha en el puerto necesario.

Linux

$ sudo netstat -ltuvnp

El resultado muestra que un servidor TCP escucha cualquier dirección IP de destino (0.0.0.0) en el puerto 22 y acepta conexiones desde cualquier dirección de origen (0.0.0.0) y cualquier puerto de origen (*). En la columna PID/nombre del programa se especifica el límite ejecutable del 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

El resultado muestra los resultados del comando ejecutado con DEST_PORT establecido en 443. Este resultado muestra que un servidor TCP está escuchando cualquier dirección (0.0.0.0) en el puerto443, que acepta conexiones desde cualquier dirección de origen (0.0.0.0) y cualquier puerto de origen (0). La columna OwningProcess indica el ID del proceso que escucha el socket.

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

Si ves que el servidor no está vinculado al puerto o la IP correctos, o que el prefijo remoto no coincide con el cliente, consulta la documentación o el proveedor del servidor para resolver el problema. El servidor debe estar vinculado a la dirección IP de una interfaz en particular o a 0.0.0.0, y debe aceptar conexiones del prefijo de IP de cliente correcto o 0.0.0.0.

Si el servidor de aplicaciones está vinculado a la dirección IP y al puerto correctos, es posible que el cliente esté accediendo al puerto equivocado, que un protocolo de nivel superior (con frecuencia TLS) esté rechazando de forma activa la conexión o que haya un firewall que esté rechazando la conexión.

Verifica que el cliente y el servidor usen la misma versión de TLS y formación de encriptación.

Verifica que tu cliente esté accediendo al puerto correcto.

Si los pasos anteriores no resuelven el problema, consulta Verifica el firewall en el cliente y el servidor para ver si se descarta el paquete.

Verifica el firewall en el cliente y el servidor para ver si se descarta el paquete

Si no se puede acceder al servidor desde la VM del cliente, pero está escuchando en el puerto correcto, una de las VM podría ejecutar un software de firewall que descarta los paquetes asociados con la conexión. Verifica el firewall de las VM de cliente y de servidor mediante los comandos siguientes.

Si una regla bloquea el tráfico, puedes actualizar el software de firewall para permitirlo. Si actualizas el firewall, continúa con precaución mientras preparas y ejecutas los comandos, ya que un firewall mal configurado puede bloquear el tráfico inesperado. Considera configurar el acceso a la consola en serie de VM antes de continuar.

iptables de Linux

Verifica los recuentos de paquetes de la cantidad de paquetes procesados para cada cadena y regla de iptables instalada. Determina con qué reglas de DROP se comparan los puertos y las direcciones IP de origen y destino con los prefijos y puertos especificados por las reglas de iptables.

Si una regla coincidente muestra un descarte creciente con los tiempos de espera de conexión, consulta la documentación de iptables para aplicar la regla allow correcta a las conexiones adecuadas.

$ sudo iptables -L -n -v -x

En esta cadena INPUT de ejemplo, se muestra que los paquetes de cualquier dirección IP a cualquier dirección IP que use el puerto TCP de destino 5000 se descartarán en el firewall. La columna pkts indica que la regla descarta 10,342 paquetes. Como prueba, si creas conexiones que descarta esta regla, verás que el contador de pkts aumenta, lo que confirma el comportamiento.

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

Puedes agregar una regla de entrada o salida a iptables con los siguientes comandos:

Regla de entrada:

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

Regla de salida:

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

Firewall de Windows

Verifica en el firewall de Windows que la conexión pueda salir del cliente y, luego, ingresar al servidor. Si una regla bloquea el tráfico, realiza las correcciones necesarias en el firewall de Windows para permitir las conexiones. También puedes habilitar el registro de firewall de Windows.

El comportamiento predeterminado DENY del firewall de Windows es descartar de forma silenciosa los paquetes denegados, lo que genera tiempos de espera.

Este comando verifica el servidor. Para verificar las reglas de salida en la VM del cliente, cambia el valor -match a 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

Puedes agregar reglas de firewall nuevas a Windows con los siguientes comandos.

Regla de salida:

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

Regla de entrada:

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

Software de terceros

Los firewalls de aplicaciones de terceros o software antivirus también pueden descartar o rechazar conexiones. Consulta la documentación que proporciona tu proveedor.

Si encuentras un problema con las reglas de firewall y lo corriges, vuelve a probar tu conectividad. Si parece que las reglas de firewall no son el problema, ve a Verifica la configuración del enrutamiento del SO.

Verifica la configuración del enrutamiento del SO

Los problemas de enrutamiento del sistema operativo pueden provenir de una de las siguientes situaciones:

  • Los problemas de enrutamiento son más comunes en las VM con interfaces de red múltiples debido a la complejidad adicional del enrutamiento.
  • En una VM creada en Google Cloud con una interfaz de red única, los problemas de enrutamiento solo suelen ocurrir si alguien modificó manualmente la tabla de enrutamiento predeterminada.
  • En una VM que se migró desde las instalaciones, la VM podría transferir la configuración de enrutamiento o MTU que se necesitaba en las instalaciones locales, pero que causa problemas en la red de VPC.

Si usas una VM con interfaces de red múltiples, las rutas deben configurarse para salir a la subred y al vNIC correctos. Por ejemplo, una VM puede tener rutas configuradas para que el tráfico destinado a las subredes internas se envíe a un vNIC, pero la puerta de enlace predeterminada (destino 0.0.0.0/0) está configurada en otro vNIC que tiene una dirección IP externa o acceso a Cloud NAT.

Puedes revisar las rutas si verificas las rutas individuales de a una o si consultas la tabla de enrutamiento de la VM completa. Si alguno de los enfoques revela problemas con la tabla de enrutamiento, consulta los pasos en Actualiza las tablas de enrutamiento si es necesario para obtener instrucciones.

Revisa todas las rutas

Enumera todas tus rutas para comprender qué rutas ya existen en tu 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

Revisa las rutas individuales

Si un prefijo de IP en particular parece ser el problema, verifica que existan las rutas adecuadas para las IP de origen y destino dentro de las VM del cliente y del servidor.

Linux

$ ip route get DEST_IP

Resultado correcto:

Se muestra una ruta válida. En este caso, los paquetes salen de la interfaz ens4.

10.3.0.34 via 10.3.0.1 dev ens4 src 10.3.0.26 uid 1000
   cache

Resultado incorrecto:

Este resultado confirma que los paquetes se descartan porque no hay una ruta a la red de destino. Confirma que la tabla de ruta contenga una ruta a la interfaz de salida correcta.

**RTNETLINK answers: Network is unreachable

Windows

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

Resultado correcto:

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 incorrecto:


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 los paquetes se descartan porque no hay una ruta a la dirección IP de destino. Verifica que tengas una puerta de enlace predeterminada y que esta se aplique a la vNIC y a la red correctas.

Actualiza las tablas de enrutamiento

Si es necesario, puedes agregar una ruta a la tabla de rutas de tu sistema operativo. Antes de ejecutar un comando para actualizar la tabla de enrutamiento de la VM de enrutamiento, te recomendamos que te familiarices con los comandos y comprendas las posibles consecuencias. El uso incorrecto de los comandos de actualización de ruta puede causar problemas inesperados o una desconexión de la VM. Considera configurar el acceso a la consola en serie de VM antes de continuar.

Consulta la documentación de tu sistema operativo para obtener instrucciones sobre cómo actualizar las rutas.

Si encuentras un problema con las rutas y lo corriges, vuelve a probar tu conectividad. Si el problema no parece estar en las rutas, continúa con Verifica la interfaz de MTU.

Verifica la MTU

La MTU de la interfaz de una VM debe coincidir con la MTU de la red de VPC a la que está conectada. Lo ideal es que las VM que se comunican entre sí también tengan MTU coincidentes. Las MTU no coincidentes no suelen ser un problema para TCP, pero pueden serlo para UDP.

Verifica la MTU de la VPC. Si las VM se encuentran en dos redes diferentes, verifica ambas redes.

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

Verifica la configuración de MTU para tus interfaces de red de cliente y servidor.

Linux

$ netstat -i

La interfaz de lo (bucle invertido) siempre tiene una MTU de 65536 y se puede ignorar para este paso.

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

Las seudointerfaces de bucle invertido siempre tienen una MTU de 4294967295 y se pueden ignorar para este paso.

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

Si la MTU de la interfaz y la red no coinciden, puedes volver a configurar la MTU de la interfaz. Para obtener más información, consulta Configuración de VM y MTU. Si coinciden, y seguiste los pasos para solucionar problemas hasta este punto, es probable que el problema esté relacionado con el servidor. Si quieres obtener ayuda para solucionar problemas del servidor, consulta Verifica el registro del servidor para obtener información sobre su comportamiento.

Verifica el registro del servidor para obtener información sobre su comportamiento

Si los pasos anteriores no resuelven un problema, es posible que la aplicación esté causando los tiempos de espera. Verifica los registros de la aplicación y del servidor a fin de encontrar comportamientos que expliquen lo que ves.

Fuentes de registros para verificar:

Si los problemas persisten

Si aún tienes problemas, consulta Cómo obtener asistencia para conocer los siguientes pasos. Es útil tener el resultado de los pasos de solución de problemas anteriores disponible para compartir con otros colaboradores.

Soluciona problemas de pérdida o latencia de red que causan problemas de capacidad de procesamiento

Por lo general, la latencia de la red o los problemas de pérdida se producen por el agotamiento de los recursos o los cuellos de botella dentro de una VM o ruta de red. En ocasiones, la pérdida de red puede causar tiempos de espera de conexión intermitentes. Causas como el agotamiento de la CPU virtual o la saturación de vNIC dan como resultado una mayor latencia y pérdida de paquetes, lo que reduce el rendimiento de la red.

En las siguientes instrucciones, se supone que las conexiones no agotan el tiempo de espera constantemente y, en su lugar, ves problemas de capacidad o rendimiento limitados. Si ves una pérdida de paquetes completa, consulta Cómo solucionar problemas de conexión completa.

Las pequeñas variaciones en la latencia, como las latencias que varían en unos milisegundos, son normales. Las latencias varían debido a la carga de la red o a la puesta en cola dentro de la VM.

Determina los valores de conexión

Primero, recopila la siguiente información:

  • En la página Instancia de VM, recopila lo siguiente para ambas VMs:
    • Nombres de las VM
    • Zonas de las VM
    • Direcciones IP internas para los vNIC que se comunican
  • Desde la configuración del software del servidor de destino, recopila la siguiente información:
    • Protocolo de capa 4
    • Puerto de destino

Si tienes problemas con varias VM, elige una sola VM de origen y una de destino con problemas y usa esos valores. En general, no deberías necesitar el puerto de origen de la conexión.

Una vez que tengas esta información, continúa con Investiga problemas con la red de Google subyacente.

Investiga problemas con la red de Google subyacente

Si tu configuración es una existente que no ha cambiado recientemente, el problema podría ser con la red de Google subyacente. Consulta el Panel de rendimiento de Network Intelligence Center para obtener información sobre la pérdida de paquetes entre las zonas de las VM. Si hay un aumento en la pérdida de paquetes entre las zonas durante el período en el que experimentaste tiempos de espera de red, esto podría indicar que el problema es con la red física subyacente a tu red virtual. Consulta el Panel de estado de Google Cloud para obtener información sobre problemas conocidos antes de presentar un caso de ayuda.

Si parece que el problema no está relacionado con la red de Google subyacente, consulta Verifica la latencia del protocolo de enlace.

Verifica la latencia del protocolo de enlace

Todos los protocolos basados en conexiones generan cierta latencia mientras realizan su protocolo de enlace de configuración de conexión. Cada protocolo de enlace del protocolo contribuye a la sobrecarga. Para las conexiones SSL/TLS, por ejemplo, el protocolo de enlace TCP se debe completar antes de que el protocolo de enlace SSL/TLS pueda iniciarse, entonces el protocolo de enlace TLS se debe completar antes de que se puedan transmitir los datos.

La latencia del protocolo de enlace en la misma zona de Google Cloud suele ser insignificante, pero los protocolos de enlace a las ubicaciones globalmente distantes pueden agregar más demoras en el inicio de la conexión. Si tienes recursos en regiones distantes, puedes comprobar si la latencia que ves se debe al protocolo de enlace del protocolo.

Linux y 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 es la duración desde el momento en que el cliente envía el paquete SYN inicial hasta que el cliente envía el ACK del protocolo de enlace TCP.
  • application_shashake es el tiempo que transcurre desde el primer paquete SYN del protocolo de enlace TCP hasta que se completa el protocolo de enlace TLS (por lo general).
  • tiempo de protocolo de enlace adicional = application_handshake - tcp_handshake

Windows 2012 y 2016

No está disponible con las herramientas de SO predeterminadas. El tiempo de ida y vuelta de ICMP se puede usar como referencia si las reglas de firewall lo permiten.

Si la latencia es superior a lo que representarían los protocolos de enlace, ve a Determina la capacidad de procesamiento máxima de tu tipo de VM.

Determina la capacidad de procesamiento máxima del tipo de VM

La capacidad de procesamiento de salida de la red de VM está limitada por la arquitectura de CPU de la VM y el recuento de CPU virtuales. Para determina el posible ancho de banda de salida de tu VM, consulta la página Ancho de banda de red.

Si tu VM no puede cumplir con tus requisitos de salida, considera actualizar a una VM con mayor capacidad. Para obtener instrucciones, consulta Cómo cambiar el tipo de máquina de una instancia.

Si tu tipo de máquina debe permitir suficiente ancho de banda de salida, investiga si el uso de Persistent Disk interfiere con la salida de tu red. Las operaciones de Persistent Disk pueden ocupar hasta el 60% de la capacidad de procesamiento total de la red de tu VM. Para determinar si las operaciones de Persistent Disk pueden interferir en la capacidad de procesamiento de la red, consulta la página Verifica el rendimiento de Persistent Disk.

La entrada de la red a una VM no está limitada por la red de VPC o el tipo de instancia de VM. En su lugar, se determina mediante la puesta en cola del paquete y el rendimiento del procesamiento del sistema operativo o la aplicación de la VM. Si tu ancho de banda de salida es adecuado, pero tienes problemas de entrada, consulta Verifica el registro del servidor para obtener información sobre su comportamiento.

Verifica la MTU de la interfaz

La MTU de una red de VPC se puede configurar. La MTU de la interfaz en la VM debe coincidir con el valor de MTU de la red de VPC a la que está conectada. En una situación de intercambio de tráfico entre redes de VPC, las VM en redes diferentes pueden tener MTU distintas. Cuando se produzca esta situación, aplica el valor de MTU más pequeño a las interfaces asociadas. Las discrepancias de MTU por lo general no son un problema para TCP, pero pueden serlo para UDP.

Verifica la MTU de la VPC. Si las VM se encuentran en dos redes diferentes, verifica ambas redes.

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

Verifica la configuración de MTU para tu interfaz de red.

Linux

La interfaz de lo (bucle invertido) siempre tiene una MTU de 65536 y se puede ignorar para este paso.

$ 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

Las seudointerfaces de bucle invertido siempre tienen una MTU de 4294967295 y se pueden ignorar para este paso.

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

Si la MTU de la interfaz y la red no coinciden, puedes volver a configurar la MTU de la interfaz. Si deseas obtener instrucciones a fin de actualizar la MTU para las VM de Windows, consulta Configuración de VM y MTU. Si coinciden, es probable que el problema sea la disponibilidad del servidor. El siguiente paso es verificar los registros para ver si una VM se reinició, se detuvo o se migró en vivo a fin de ver si algo le sucedió a la VM durante el tiempo correspondiente.

Verifica los registros para ver si una VM se reinició, se detuvo o se migró en vivo

Durante el ciclo de vida de una VM, un usuario la puede reiniciar, se puede migrar en vivo para el mantenimiento de Google Cloud o, en circunstancias excepcionales, se puede perder y volver a crear una VM si ocurre un error dentro del host físico que la contiene. Estos eventos pueden causar un breve aumento en la latencia o los tiempos de espera de la conexión. Si alguno de estos problemas se presenta en la VM, se registra el evento.

Para ver los registros de la VM, sigue estos pasos:

  1. En la consola de Google Cloud, ve a la página Logging.

    Ir a Logging

  2. Elige el período en el que ocurrió la latencia.

  3. Usa la siguiente consulta de Logging para determinar si se produjo un evento de VM cerca del período en el que se produjo la latencia:

    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"
    )
    

Si las VM no se reiniciaron ni migraron durante el tiempo relevante, el problema podría deberse al agotamiento de recursos. Para verificar, consulta Verifica las estadísticas de red y SO en busca de paquetes descartados debido al agotamiento de recursos.

Verifica las estadísticas de red y SO en busca de paquetes descartados debido al agotamiento de recursos

Agotamiento de recursos es un término general que significa que se le pide a un recurso en la VM, como el ancho de banda de salida, que maneje más de lo que puede. El agotamiento de los recursos puede generar descartes periódicos de paquetes, lo que provoca latencia o tiempos de espera de la conexión. Es posible que estos tiempos de espera no sean visibles durante el inicio del cliente o del servidor, pero pueden aparecer con el tiempo a medida que el sistema agota los recursos.

La siguiente es una lista de comandos que muestran los contadores de paquetes y las estadísticas. Algunos de estos comandos duplican los resultados de otros comandos. En esos casos, puedes usar el comando que te funcione mejor. Consulta las notas dentro de cada sección para comprender mejor el resultado deseado de la ejecución del comando. Puede ser útil ejecutar los comandos en diferentes momentos para ver si se producen descartes o errores al mismo tiempo que el problema.

Linux

  1. Usa el comando netstat para ver las estadísticas de la red.

    $ 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
    

    El comando netstat genera estadísticas de red que contienen valores para paquetes descartados por protocolo. Los paquetes descartados pueden deberse al agotamiento de los recursos por parte de la aplicación o la interfaz de red. Consulta el motivo del contador para obtener indicaciones sobre por qué aumentó un contador.

  2. Revisa kern.log para ver los registros que coinciden con nf_conntrack: table full, dropping packet.

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

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

    Este registro indica que la tabla de seguimiento de conexión para VM alcanzó la cantidad máxima de conexiones que se pueden seguir. Es posible que se agote el tiempo de espera de las conexiones adicionales desde y hacia esta VM. Si se habilitó conntrack, el recuento máximo de conexiones se puede encontrar con sudo sysctl net.netfilter.nf_conntrack_max.

    Puedes aumentar el valor de la cantidad máxima de conexiones con seguimiento si modificas sysctl net.netfilter.nf_conntrack_max o si distribuyes una carga de trabajo de VM en varias VM para reducir la carga.

IU de Windows

Perfmon

  1. En el menú de Windows, busca “perfmon” y abre el programa.
  2. En el menú de la izquierda, selecciona Rendimiento > Herramientas de supervisión > Supervisor de rendimiento.
  3. En la vista principal, haz clic en el botón verde más “+” para agregar contadores de rendimiento al gráfico de supervisión. Los siguientes contadores son de interés:
    • Adaptador de red
      • Longitud de la cola de salida
      • Paquetes de salida descartados
      • Errores de paquetes de salida
      • Paquetes recibidos descartados
      • Errores de paquetes recibidos
      • Paquetes recibidos desconocidos
    • Interfaz de red
      • Longitud de la cola de salida
      • Paquetes de salida descartados
      • Errores de paquetes de salida
      • Paquetes recibidos descartados
      • Errores de paquetes recibidos
      • Paquetes recibidos desconocidos
    • Actividad de la tarjeta de interfaz de red por procesador
      • Indicaciones de recepción de recursos bajos/s
      • Paquetes recibidos con pocos recursos/s
    • Procesador
      • Porcentaje de tiempo de interrupción
      • % de tiempo con privilegios
      • Porcentaje de tiempo del procesador
      • Porcentaje de tiempo del usuario

Perfmon te permite trazar los contadores anteriores en un gráfico de serie temporal. Puede ser beneficioso observar este parámetro cuando se produce una prueba o un servidor se ve afectado por el momento. Los aumentos en los contadores relacionados con la CPU, como el tiempo de interrupción y el tiempo con privilegios, pueden indicar problemas de saturación a medida que la VM alcanza las limitaciones de capacidad de procesamiento de CPU. Los descartes y errores de paquetes pueden ocurrir cuando la CPU está saturada, lo que obliga a que los paquetes se pierdan antes de que el cliente o los sockets del servidor los procesen. Por último, la longitud de la cola de salida también aumentará durante la saturación de la CPU a medida que se pongan en cola más paquetes para el procesamiento.

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

El comando netstat genera estadísticas de red que contienen valores para paquetes descartados por protocolo. Los paquetes descartados pueden deberse al agotamiento de los recursos por parte de la aplicación o la interfaz de red.

Si ves que se agota el recurso, puedes intentar distribuir la carga de trabajo en más instancias, actualizar la VM a una con más recursos, ajustar el SO o la aplicación para necesidades de rendimiento específicas, ingresar el mensaje de error en un motor de búsqueda para buscar posibles soluciones o pedir ayuda mediante uno de los métodos descritos en Si los problemas persisten.

Si el agotamiento de los recursos no parece ser el problema, es posible que el problema esté relacionado con el software del servidor. Si quieres obtener orientación para solucionar problemas de software del servidor, consulta Verifica el registro del servidor para obtener información sobre su comportamiento.

Verifica el registro del servidor para obtener información sobre su comportamiento

Si los pasos anteriores no revelan un problema, los tiempos de espera pueden deberse al comportamiento de la aplicación, como los bloqueos de procesamiento causados por el agotamiento de las CPU virtuales. Revisa los registros del servidor y las aplicaciones para obtener indicaciones sobre el comportamiento que experimentas.

Por ejemplo, un servidor que experimenta una mayor latencia debido a un sistema ascendente, como una base de datos bajo carga, puede poner en cola una cantidad excesiva de solicitudes que pueden causar un mayor uso de memoria y tiempos de espera de CPU. Estos factores pueden provocar fallas en las conexiones o una sobrecarga del búfer de socket.

En ocasiones, las conexiones TCP pierden un paquete, pero la confirmación selectiva y la retransmisión de paquetes suelen recuperar los paquetes perdidos, lo que evita el tiempo de espera de conexión. En su lugar, considera que los tiempos de espera pueden ser el resultado de que el servidor de la aplicación falle o se vuelva a implementar, lo que provoca una falla momentánea para las conexiones.

Si tu aplicación de servidor depende de una conexión a una base de datos o a otro servicio, confirma que los servicios vinculados no tengan un rendimiento bajo. Tu aplicación puede hacer un seguimiento de estas métricas.

Si los problemas persisten

Si aún tienes problemas, consulta Cómo obtener asistencia para conocer los siguientes pasos. Es útil que los resultados de los pasos para solucionar problemas estén disponibles a fin de compartirlos con otros colaboradores.

¿Qué sigue?

  • Si aún tienes problemas, consulta la página Recursos.