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
- Si crees que tienes pérdida de paquetes completa, ve a Soluciona problemas de falla de conexión completa.
- Si experimentas latencia, solo pérdida parcial de paquetes o tiempos de espera que ocurren en la conexión media, ve a Soluciona problemas de pérdida o latencia de red que causan problemas de capacidad de procesamiento.
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 la 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 asistencia.
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:
En la consola de Google Cloud, ve a la página Pruebas de conectividad.
En el menú desplegable del proyecto, confirma que estés en el proyecto correcto o especifica el correcto.
Haz clic en Crear prueba de conectividad.
Asigna un nombre a la prueba.
Especifique lo siguiente:
- Protocolo
- Dirección IP del extremo de origen
- Proyecto de origen y red de VPC
- Dirección IP del extremo de destino
- Proyecto de destino y red de VPC
- Puerto de destino
Haz 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:
- Verifica la lista Tráfico siempre bloqueado. Si Google Cloud bloquea el tráfico como se describe en la lista de tráfico siempre bloqueado, tu configuración existente no funcionará.
- Ve a la página de políticas de Firewall y revisa tus reglas de firewall. Si el firewall está mal configurado, crea o modifica una regla de firewall para permitir la conexión. Puede ser una regla de firewall de VPC o una regla de políticas de firewall jerárquica.
- 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 indican que las VMs no deberían llegar a todos es posible que debas rediseñar tu equipo.
- 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
En la consola de Google Cloud, ve a la página Firewall.
Asegúrate de que haya una regla de firewall que permita conexiones SSH desde IAP a tu VM o crea una nueva.
En la consola de Google Cloud, ve a la página Instancias de VM.
Busca la VM de origen.
Haz clic en SSH, en la columna Conectar para esa VM.
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
En la consola de Google Cloud, ve a la página Instancias de VM.
Busca la VM de origen.
Usa uno de los métodos descritos en Conéctate a las VM de Windows para conectarte a la VM.
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)`
- Windows 2019:
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 Comprueba 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 las reglas de firewall no son el problema, continúa con Comprueba 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 las MTUs de la interfaz y la red no coinciden, puedes reconfigurar 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:
- Cloud Logging para la VM
- Registros en serie de VM
- Syslog y kern.log de Linux, o el visualizador de eventos de Windows
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 así puedes compartirlos 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 la 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 asistencia.
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 las MTUs de la interfaz y la red no coinciden, puedes reconfigurar 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 comprobar los registros para ver si una VM se reinició, se detuvo o se migró en vivo así puedes 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:
En la consola de Google Cloud, ve a la página Logging.
Elige el período en el que ocurrió la latencia.
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
Usa el comando
netstatpara ver las estadísticas de la red.$ 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
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.
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_maxo si distribuyes una carga de trabajo de VM en varias VM para reducir la carga.
IU de Windows
Perfmon
- En el menú de Windows, busca “perfmon” y abre el programa.
- En el menú de la izquierda, selecciona Rendimiento > Herramientas de supervisión > Supervisor de rendimiento.
- 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 por segundo
- Paquetes recibidos con pocos recursos por segundo
- Procesador
- Porcentaje de tiempo de interrupción
- % de tiempo con privilegios
- Porcentaje de tiempo del procesador
- Porcentaje de tiempo del usuario
- Adaptador de red
Perfmon te permite trazar los contadores anteriores en un gráfico de serie temporal. Puede ser beneficioso mirar 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 las detenciones del procesamiento causadas por el agotamiento de la CPU virtual. 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.