Solucionar problemas de conectividad interna entre máquinas virtuales
En este documento se describen los pasos para solucionar los problemas de conectividad entre las máquinas virtuales de Compute Engine que estén en la misma red de nube privada virtual (VPC), ya sea compartida o independiente, o que sean dos redes de VPC conectadas mediante el emparejamiento de redes de VPC. En esta guía se da por sentado que las máquinas virtuales se comunican mediante las direcciones IP internas de sus respectivos controladores de interfaz de red virtual (vNICs).
Los pasos de esta guía se aplican tanto a las máquinas virtuales de Compute Engine como a los nodos de Google Kubernetes Engine.
Si quieres ver más casos prácticos específicos para solucionar problemas, haz clic en el enlace Enviar comentarios, situado en la parte inferior de la página, y háznoslo saber.
Las siguientes configuraciones de VM y VPC se aplican a esta guía:
- Conexiones entre máquinas virtuales mediante direcciones IP internas en una sola red de VPC.
- Conexiones entre máquinas virtuales mediante direcciones IP internas en una red de VPC compartida.
- Conexiones entre máquinas virtuales que usan direcciones IP internas en diferentes redes de VPC emparejadas mediante el emparejamiento entre redes de VPC.
Los comandos que se usan en esta guía están disponibles en todas las imágenes del SO proporcionadas por Google. Si usas tu propia imagen del SO, puede que tengas que instalar las herramientas.
Cuantificar el problema
- Si crees que has perdido todos los paquetes, consulta el artículo Solucionar problemas de conexión completa.
- Si experimentas latencia, pérdida parcial de paquetes o tiempos de espera que se producen a mitad de la conexión, ve a Solucionar problemas de latencia o pérdida de paquetes en la red que provocan problemas de rendimiento.
Solucionar problemas de conexión fallida
En las siguientes secciones se indican los pasos para solucionar problemas de conectividad interna completa entre máquinas virtuales. Si, por el contrario, experimentas un aumento de la latencia o tiempos de espera de conexión intermitentes, ve a Solucionar problemas de latencia o pérdida de red que provocan problemas de rendimiento.
Determinar los valores de conexión
Primero, reúne la siguiente información:
- En la página Instancias de VM, recopila la siguiente información de ambas VMs:
- Nombres de VMs
- Zonas de VM
- Direcciones IP internas de las vNICs que se comunican
En la configuración del software del servidor de destino, recoge 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 tu configuración específica puede usar otro puerto.
Si tienes problemas con varias máquinas virtuales, elige una máquina virtual de origen y otra de destino que tengan problemas y usa esos valores. Por lo general, no necesitas el puerto de origen de la conexión.
Una vez que tengas esta información, ve a Investigar problemas con la red de Google subyacente.
Investigar problemas con la red de Google subyacente
Si tu configuración es antigua y no ha cambiado recientemente, el problema podría estar en la red de Google subyacente. Consulta el panel de rendimiento de Network Intelligence Center para ver la pérdida de paquetes entre las zonas de las VMs. Si se produce un aumento de la pérdida de paquetes entre las zonas durante el periodo en el que has experimentado tiempos de espera de la red, puede indicar que el problema se debe a la red física subyacente a tu red virtual. Consulta el panel de estado de Google Cloud para ver si hay problemas conocidos antes de crear un caso de asistencia.
Si parece que el problema no está relacionado con la red de Google subyacente, ve a la sección Comprobar si hay reglas de firewall mal configuradas Google Cloud .
Comprobar si hay reglas de cortafuegos mal configuradas en Google Cloud
Pruebas de conectividad analiza la configuración de la ruta de la red VPC entre dos máquinas virtuales y muestra si la configuración programada debería permitir el tráfico o no. Si el tráfico no está permitido, los resultados mostrarán si una regla de cortafuegos de salida o de entrada está bloqueando el tráfico o si no hay ninguna ruta disponible. Google Cloud
Las pruebas de conectividad también pueden probar la ruta de forma dinámica enviando paquetes entre los hipervisores de las VMs. Si se realizan estas pruebas, se mostrarán los resultados.
Pruebas de conectividad solo examina la configuración de la red de VPC. No prueba el cortafuegos del sistema operativo, las rutas del sistema operativo ni el software del servidor de la VM.
En el siguiente procedimiento se ejecutan pruebas de conectividad desde la consola deGoogle Cloud . Para ver otras formas de ejecutar pruebas, consulta Ejecutar pruebas de conectividad.
Sigue este procedimiento para crear y ejecutar una prueba:
En la Google Cloud consola, ve a la página Pruebas de conectividad.
En el menú desplegable del proyecto, comprueba que estás en el proyecto correcto o especifica el que corresponda.
Haz clic en Crear prueba de conectividad.
Asigna un nombre a la prueba.
Especifica lo siguiente:
- Protocolo
- Dirección IP del endpoint de origen
- Proyecto y red de VPC de origen
- Dirección IP del endpoint de destino
- Proyecto y red VPC de destino
- Puerto de destino
Haz clic en Crear.
La prueba se ejecuta inmediatamente. Para ver el diagrama de resultados, haga clic en Ver en la columna Detalles del resultado.
- Si los resultados indican que la conexión se ha interrumpido por una regla de cortafuegos, determina si la configuración de seguridad que quieres aplicar debería permitir la conexión. Google CloudPuede que tengas que pedirle más información a tu administrador de seguridad o de red. Si el tráfico se debe permitir, comprueba lo siguiente:
- Consulta la lista Tráfico siempre bloqueado. Si el tráfico está bloqueado por Google Cloud , tal como se describe en la lista de tráfico siempre bloqueado, la configuración que tenga no funcionará.
- Ve a la página Políticas de cortafuegos y revisa tus reglas de cortafuegos. Si el cortafuegos está mal configurado, crea o modifica una regla de cortafuegos para permitir la conexión. Esta regla puede ser una regla de cortafuegos de VPC o una regla de política de cortafuegos jerárquica.
- Si hay una regla de cortafuegos configurada correctamente que bloquea este tráfico, ponte en contacto con el administrador de seguridad o de red. Si los requisitos de seguridad de tu organización implican que las VMs no deben comunicarse entre sí, es posible que tengas que rediseñar la configuración.
- Si los resultados indican que no hay problemas con la ruta de conectividad de la VPC, puede que el problema sea uno de los siguientes.
- Problemas con la configuración del SO invitado, como problemas con el software del cortafuegos.
- Problemas con las aplicaciones del cliente o del servidor, como que la aplicación se haya bloqueado o se haya configurado para escuchar en el puerto incorrecto.
En los pasos siguientes se explica cómo analizar cada una de estas posibilidades. Continúa con la sección Probar la conectividad TCP desde la máquina virtual.
Probar la conectividad TCP desde dentro de la VM
Si la prueba de conectividad entre VMs no ha detectado ningún problema de configuración de VPC, empieza a probar la conectividad entre sistemas operativos. Los pasos que se indican a continuación te ayudarán a determinar lo siguiente:
- Si un servidor TCP está escuchando en el puerto indicado
- Si el software de cortafuegos del lado del servidor permite las conexiones a ese puerto desde la VM cliente
- Si el software de cortafuegos del lado del cliente permite las conexiones a ese puerto en el servidor
- Si la tabla de rutas del lado del servidor está configurada correctamente para reenviar paquetes
- Si la tabla de rutas del lado del cliente está configurada correctamente para reenviar paquetes
Puedes probar el handshake de TCP con curl en Linux o Windows 2019, o con el comando New-Object System.Net.Sockets.TcpClient en Windows PowerShell. El flujo de trabajo de esta sección debe dar como resultado una de las siguientes opciones: conexión correcta, tiempo de espera de la conexión o restablecimiento de la conexión.
- Correcto: si la negociación TCP se completa correctamente, significa que una regla de firewall del SO no está bloqueando la conexión, que el SO está reenviando los paquetes correctamente y que un servidor de algún tipo está escuchando en el puerto de destino. Si es así, es posible que el problema esté en la propia aplicación. Para comprobarlo, consulta Comprobar el registro del servidor para obtener información sobre el comportamiento del servidor.
- Tiempo de espera: si se agota el tiempo de espera de tu conexión, suele significar una de las siguientes opciones:
- No hay ninguna máquina en esa dirección IP
- Hay un cortafuegos que está descartando 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 respuesta por una ruta no válida.
Restablecer: si se está restableciendo la conexión, significa que la IP de destino está recibiendo paquetes, pero un SO o una aplicación están rechazando los paquetes. Esto puede significar una de las siguientes opciones:
- Los paquetes llegan a la máquina incorrecta y no está configurada para responder a ese protocolo en ese puerto.
- Los paquetes llegan al ordenador correcto, pero ningún servidor está escuchando en ese puerto.
- Los paquetes llegan al ordenador y al puerto correctos, pero los protocolos de nivel superior (como SSL) no completan su handshake.
- Un cortafuegos está restableciendo la conexión. Es menos probable que un cortafuegos descarte los paquetes de forma silenciosa, pero puede ocurrir.
Linux
En la Google Cloud consola, ve a la página Políticas de cortafuegos.
Asegúrate de que haya una regla de cortafuegos que permita las conexiones SSH desde IAP a tu VM o crea una.
En la consola de Google Cloud , ve a la página Instancias de VM.
Busca la máquina virtual de origen.
Haz clic en SSH en la columna Conectar de esa máquina virtual.
En la línea de comandos de la máquina cliente, ejecuta el siguiente comando. Sustituye DEST_IP:DEST_PORT por la dirección IP y el 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 máquina virtual de origen.
Usa uno de los métodos descritos en Conectarse a VMs de Windows para conectarte a tu VM.
En la línea de comandos de la máquina cliente, ejecuta lo siguiente:
- 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:
Conexión correcta
Los siguientes resultados indican que el handshake TCP se ha realizado correctamente. Si el handshake TCP se completa correctamente, el problema no está relacionado con el tiempo de espera o el restablecimiento de la conexión TCP. En su lugar, el problema de tiempo de espera se produce en las capas de la aplicación. Si la conexión se realiza correctamente, ve a la sección Comprobar el registro del servidor para obtener información sobre el comportamiento del servidor.
Linux y Windows 2019
$ curl -vso /dev/null --connect-timeout 5 192.168.0.4:443
La línea "Conectado a" indica que se ha completado correctamente la negociación TCP.
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 de conexión correcta. 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 agotado
Los siguientes resultados indican que se ha agotado el tiempo de espera de la conexión. Si la conexión se agota, ve a Verificar 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"
Conexión restablecida
Un restablecimiento se produce cuando un dispositivo envía un paquete RST al cliente para informarle de que la conexión se ha terminado. La conexión se puede restablecer por uno de los siguientes motivos:
- El servidor receptor no se ha configurado para aceptar conexiones de ese protocolo en ese puerto. Esto puede deberse a que el paquete se ha enviado al servidor o al puerto incorrectos, o a que el software del servidor no se ha configurado correctamente.
- El software de cortafuegos ha rechazado el intento de conexión
Si se ha restablecido la conexión, ve a la sección Verificar que estás accediendo a la dirección IP y al puerto correctos.
Linux y Windows 2019
$ curl -vso /dev/null --connect-timeout 5 DEST_IP_ADDRESS:PORT
Resultado de la conexión restablecida:
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 de la conexión restablecida:
New-Object: Exception calling ".ctor" with "2" argument(s): "No connection could be made because the target machine actively refused it. 192.168.0.4:443"
Verificar la dirección IP y el puerto del servidor
Ejecuta uno de los siguientes comandos en tu servidor. Indican si hay un servidor escuchando en el puerto necesario.
Linux
$ sudo netstat -ltuvnp
El resultado muestra que un servidor TCP está escuchando cualquier dirección IP de destino (0.0.0.0) en el puerto 22 y acepta conexiones de cualquier dirección de origen (0.0.0.0) y cualquier puerto de origen (*). La columna PID/Nombre del programa especifica el ejecutable enlazado al 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 definido como 443.
En este resultado se muestra que un servidor TCP está escuchando cualquier dirección (0.0.0.0) en el puerto 443 y acepta conexiones de cualquier dirección de origen (0.0.0.0) y cualquier puerto de origen (0). La columna OwningProcess indica el ID del proceso que está escuchando 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 a la IP correctos, o que el prefijo remoto no coincide con tu cliente, consulta la documentación del servidor o al proveedor para resolver el problema. El servidor debe estar enlazado a la dirección IP de una interfaz concreta o a 0.0.0.0, y debe aceptar conexiones desde el prefijo de IP del cliente correcto o desde 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 incorrecto, que un protocolo de nivel superior (con frecuencia, TLS) esté rechazando activamente la conexión o que haya un cortafuegos que rechace la conexión.
Comprueba que el cliente y el servidor usen la misma versión de TLS y el mismo formato de cifrado.
Comprueba que tu cliente esté accediendo al puerto correcto.
Si el problema persiste después de seguir los pasos anteriores, ve a la sección Comprobar si el cortafuegos del cliente y del servidor descarta paquetes.
Comprobar si el cortafuegos del cliente y del servidor descarta paquetes
Si no se puede acceder al servidor desde la VM cliente, pero está escuchando en el puerto correcto, es posible que una de las VMs esté ejecutando un software de cortafuegos que descarte los paquetes asociados a la conexión. Comprueba el cortafuegos de las VMs de cliente y de servidor con los siguientes comandos.
Si una regla bloquea tu tráfico, puedes actualizar el software del cortafuegos para permitirlo. Si actualiza el cortafuegos, hágalo con precaución al preparar y ejecutar los comandos, ya que un cortafuegos mal configurado puede bloquear tráfico inesperado. Te recomendamos que configures el acceso a la consola en serie de la VM antes de continuar.
Iptables de Linux
Comprueba el número de paquetes procesados de cada cadena y regla de iptables instalada. Determina con qué reglas DROP se compara la información comparando las direcciones IP y los puertos de origen y de destino con los prefijos y los puertos especificados por las reglas de iptables.
Si una regla coincidente muestra un número creciente de descartes con 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 este ejemplo de cadena INPUT se muestra que los paquetes de cualquier dirección IP a cualquier dirección IP que utilice el puerto TCP de destino 5000 se descartarán en el cortafuegos.
La columna pkts indica que la regla ha descartado 10.342 paquetes. Como prueba, si creas conexiones que se descartan con esta regla, verás cómo aumenta el contador de paquetes, 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 añadir 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
Cortafuegos de Windows
Comprueba en Firewall de Windows que se permite la conexión de salida del cliente y de entrada al servidor. Si una regla bloquea tu tráfico, haz 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 de DENY del cortafuegos de Windows es descartar silenciosamente los paquetes denegados, lo que provoca tiempos de espera.
Este comando comprueba el servidor. Para comprobar las reglas de salida de la VM cliente, cambia el valor de -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 añadir nuevas reglas de cortafuegos 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 cortafuegos de aplicaciones de terceros o el software antivirus también pueden rechazar o interrumpir las conexiones. Consulta la documentación proporcionada por tu proveedor.
Si detectas un problema con las reglas de cortafuegos y lo corriges, vuelve a probar la conectividad. Si parece que el problema no se debe a las reglas de cortafuegos, ve a la sección Comprobar la configuración del enrutamiento del SO.
Comprobar la configuración de enrutamiento del SO
Los problemas de enrutamiento del sistema operativo pueden deberse a una de las siguientes situaciones:
- Los problemas de enrutamiento son más habituales en las VMs con varias interfaces de red debido a la complejidad adicional del enrutamiento.
- En una VM creada en Google Cloud con una sola interfaz de red, los problemas de enrutamiento solo se producen si alguien ha modificado manualmente la tabla de enrutamiento predeterminada.
- En una máquina virtual que se ha migrado desde un entorno local, es posible que la máquina virtual conserve ajustes de enrutamiento o de MTU que eran necesarios en el entorno local, pero que causan problemas en la red de VPC.
Si usas una VM con varias interfaces de red, las rutas deben configurarse para salir a la subred y la NIC virtual correctas. Por ejemplo, una máquina virtual puede tener rutas configuradas de forma que el tráfico destinado a subredes internas se envíe a una interfaz de red virtual, pero la puerta de enlace predeterminada (destino 0.0.0.0/0) se configura en otra interfaz de red virtual que tiene una dirección IP externa o acceso a Cloud NAT.
Puedes revisar las rutas comprobando las rutas individuales de una en una o consultando toda la tabla de rutas de la máquina virtual. Si con alguno de los dos métodos se detectan problemas en la tabla de enrutamiento, consulta los pasos que se indican en Actualizar las tablas de enrutamiento si es necesario para obtener instrucciones.
Revisar todas las rutas
Lista todas tus rutas para saber cuáles 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
Consultar rutas concretas
Si parece que el problema es un prefijo IP concreto, comprueba que haya rutas adecuadas para las IPs de origen y de destino en las VMs 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 ninguna ruta a la red de destino. Confirma que tu tabla de rutas contiene 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 están descartando porque no hay ninguna ruta a la dirección IP de destino. Comprueba que tengas una pasarela predeterminada y que se aplique a la vNIC y a la red correctas.
Actualizar tablas de enrutamiento
Si es necesario, puedes añadir 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 que entiendas las posibles implicaciones. Si se usan de forma incorrecta los comandos de actualización de ruta, se pueden producir problemas inesperados o desconexiones en la VM. Te recomendamos que configures el acceso a la consola en serie de la VM antes de continuar.
Consulta la documentación de tu sistema operativo para obtener instrucciones sobre cómo actualizar las rutas.
Si detectas un problema con las rutas y lo corriges, vuelve a probar la conectividad. Si parece que el problema no se debe a las rutas, ve a Comprobar la MTU de la interfaz.
Comprobar la MTU
El MTU de la interfaz de una VM debe coincidir con el MTU de la red de VPC a la que está conectada. Lo ideal es que las VMs que se comunican entre sí también tengan MTUs coincidentes. Normalmente, las MTUs no coincidentes no suponen un problema para TCP, pero sí para UDP.
Comprueba la MTU de la VPC. Si las VMs están en dos redes diferentes, comprueba ambas redes.
gcloud compute networks describe NET_NAME --format="table(name,mtu)"
Comprueba la configuración de MTU de las interfaces de red del cliente y del servidor.
Linux
$ netstat -i
La interfaz lo (loopback) siempre tiene un MTU de 65536 y se puede ignorar en 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 pseudointerfaces de bucle de retorno siempre tienen un MTU de 4294967295 y se pueden ignorar en 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 los MTUs de la interfaz y de la red no coinciden, puedes volver a configurar el MTU de la interfaz. Para obtener más información, consulta Máquinas virtuales y ajustes de MTU. Si coinciden y has seguido los pasos para solucionar el problema hasta ahora, es probable que el problema esté en el propio servidor. Para obtener ayuda sobre cómo solucionar problemas del servidor, consulta el artículo Comprobar el registro del servidor para obtener información sobre el comportamiento del servidor.
Consultar los registros del servidor para obtener información sobre el comportamiento del servidor
Si los pasos anteriores no resuelven el problema, es posible que la aplicación esté provocando los tiempos de espera. Comprueba los registros del servidor y de la aplicación para ver si hay algún comportamiento que explique lo que estás viendo.
Orígenes del registro que se deben comprobar:
- Cloud Logging de la VM
- Registros de serie de VM
- syslog y kern.log de Linux, o Visor de eventos de Windows
Si sigues teniendo problemas
Si sigues teniendo problemas, consulta la sección Obtener asistencia para saber qué hacer a continuación. Es útil tener la salida de los pasos de solución de problemas anteriores para compartirla con otros colaboradores.
Solucionar problemas de latencia o pérdida de red que provoquen problemas de rendimiento
Los problemas de latencia o pérdida de red suelen deberse a que se han agotado los recursos o a que hay cuellos de botella en una máquina virtual o en una ruta de red. En ocasiones, la pérdida de red puede provocar tiempos de espera de conexión intermitentes. Causas como el agotamiento de la vCPU o la saturación de la vNIC provocan un aumento de la latencia y una pérdida de paquetes, lo que conlleva una reducción del rendimiento de la red.
En las siguientes instrucciones se da por hecho que las conexiones no se agotan constantemente y que, en su lugar, se producen problemas de capacidad o rendimiento limitados. Si se produce una pérdida total de paquetes, consulta el artículo Solucionar problemas de conexión.
Es normal que haya pequeñas variaciones en la latencia, como latencias que varían en unos pocos milisegundos. Las latencias varían debido a la carga de la red o a las colas dentro de la VM.
Determinar los valores de conexión
Primero, reúne la siguiente información:
- En la página Instancias de VM, recopila la siguiente información de ambas VMs:
- Nombres de VMs
- Zonas de VM
- Direcciones IP internas de las vNICs que se comunican
- En 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 máquinas virtuales, elige una máquina virtual de origen y otra de destino que tengan problemas y usa esos valores. Por lo general, no necesitas el puerto de origen de la conexión.
Una vez que tengas esta información, ve a Investigar problemas con la red de Google subyacente.
Investigar problemas con la red de Google subyacente
Si tu configuración es antigua y no ha cambiado recientemente, el problema podría estar en la red de Google subyacente. Consulta el panel de rendimiento de Network Intelligence Center para ver la pérdida de paquetes entre las zonas de las VMs. Si se produce un aumento de la pérdida de paquetes entre las zonas durante el periodo en el que has experimentado tiempos de espera de la red, puede indicar que el problema está en la red física subyacente a tu red virtual. Consulta el panel de estado de Google Cloud para ver si hay problemas conocidos antes de crear un caso de asistencia.
Si parece que el problema no está relacionado con la red de Google subyacente, ve a la sección Comprobar la latencia del handshake.
Comprobar la latencia de handshake
Todos los protocolos basados en conexiones incurren en cierta latencia mientras realizan su handshake de configuración de conexión. Cada handshake de protocolo aumenta la sobrecarga. Por ejemplo, en las conexiones SSL/TLS, el handshake TCP debe completarse antes de que pueda iniciarse el handshake SSL/TLS. Después, el handshake TLS debe completarse antes de que se puedan transmitir los datos.
La latencia de la negociación en la misma zona Google Cloud suele ser insignificante, pero las negociaciones con ubicaciones lejanas a nivel mundial pueden añadir mayores retrasos al iniciar la conexión. Si tienes recursos en regiones lejanas, puedes comprobar si la latencia que observas se debe a la negociación 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 que el cliente envía el paquete SYN inicial hasta que envía el ACK del protocolo de enlace TCP.
- application_handshake es el tiempo transcurrido desde el primer paquete SYN del handshake de TCP hasta que se completa el handshake de TLS (normalmente).
- Tiempo de handshake adicional = handshake_aplicación - handshake_tcp
Windows 2012 y 2016
No está disponible con las herramientas predeterminadas del SO. El tiempo de ida y vuelta de ICMP se puede usar como referencia si las reglas de cortafuegos lo permiten.
Si la latencia es superior a la que se debería producir por las peticiones de enlace, consulta la sección Determinar el rendimiento máximo de tu tipo de VM.
Determinar el rendimiento máximo de tu tipo de VM
El rendimiento de salida de la red de la VM está limitado por la arquitectura de la CPU de la VM y el número de vCPUs. Para determinar el ancho de banda de salida potencial de tu VM, consulta la página Ancho de banda de red.
Si tu máquina virtual no puede cumplir tus requisitos de salida, plantéate actualizarla a una con mayor capacidad. Para obtener instrucciones, consulta Cambiar el tipo de máquina de una instancia.
Si el tipo de máquina debería permitir suficiente ancho de banda de salida, investiga si el uso de discos persistentes está interfiriendo con la salida de tu red. Las operaciones de Persistent Disk pueden ocupar hasta el 60% del rendimiento total de la red de tu VM. Para determinar si las operaciones de disco persistente pueden estar interfiriendo con el rendimiento de la red, consulta Comprobar el rendimiento del disco persistente.
La entrada de red a una VM no está limitada por la red de VPC ni por el tipo de instancia de VM. En su lugar, se determina en función del rendimiento de la cola de paquetes y del procesamiento del sistema operativo o la aplicación de la VM. Si el ancho de banda de salida es adecuado, pero tienes problemas con el de entrada, consulta Comprobar el registro del servidor para obtener información sobre el comportamiento del servidor.
Comprobar la MTU de la interfaz
El MTU de una red de VPC se puede configurar. La MTU de la interfaz de la VM debe coincidir con el valor de MTU de la red de VPC a la que está conectada. En una situación de emparejamiento entre redes de VPC, las VMs de diferentes redes pueden tener MTUs distintos. Cuando se dé esta situación, aplique el valor de MTU más pequeño a las interfaces asociadas. Normalmente, las discrepancias de MTU no suponen un problema para TCP, pero sí para UDP.
Comprueba la MTU de la VPC. Si las VMs están en dos redes diferentes, comprueba ambas redes.
gcloud compute networks describe NET_NAME --format="table(name,mtu)"
Comprueba la configuración de MTU de tu interfaz de red.
Linux
La interfaz lo (loopback) siempre tiene un MTU de 65536 y se puede ignorar en 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 pseudointerfaces de bucle de retorno siempre tienen un MTU de 4294967295 y se pueden ignorar en 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 los MTUs de la interfaz y de la red no coinciden, puedes volver a configurar el MTU de la interfaz. Para obtener instrucciones sobre cómo actualizar la MTU de las VMs de Windows, consulta Máquinas virtuales y ajustes de MTU. Si coinciden, es probable que el problema sea la disponibilidad del servidor. El siguiente paso es consultar los registros para ver si se ha reiniciado, detenido o migrado en directo una VM y comprobar si ha ocurrido algo con tu VM durante el periodo correspondiente.
Consultar los registros para ver si se ha reiniciado, detenido o migrado en directo una máquina virtual
Durante el ciclo de vida de una VM, esta puede reiniciarse por el usuario o migrarse en vivo para realizar tareas de mantenimiento. En raras ocasiones, una VM puede perderse y recrearse si se produce un fallo en el host físico que la contiene.Google Cloud Estos eventos pueden provocar un breve aumento de la latencia o tiempos de espera de conexión. Si le ocurre alguna de estas cosas a la VM, el evento se registra.
Para ver los registros de tu máquina virtual, sigue estos pasos:
En la Google Cloud consola, ve a la página Registro.
Elige el periodo en el que se produjo la latencia.
Usa la siguiente consulta de registro para determinar si se ha producido un evento de VM cerca del periodo en el que se ha producido 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 VMs no se reiniciaron ni migraron durante el periodo correspondiente, es posible que el problema se deba a que se han agotado los recursos. Para comprobarlo, ve a Comprobar las estadísticas de la red y del SO para ver si se han descartado paquetes debido al agotamiento de recursos.
Comprobar las estadísticas de la red y del SO para ver si se han descartado paquetes debido al agotamiento de recursos
Agotamiento de recursos es un término general que significa que se le pide a algún recurso de la VM, como el ancho de banda de salida, que gestione más de lo que puede. El agotamiento de recursos puede provocar que se descarten paquetes periódicamente, lo que causa latencia de conexión o tiempos de espera. Es posible que estos tiempos de espera no se vean al iniciar el cliente o el servidor, pero pueden aparecer con el tiempo a medida que el sistema agota los recursos.
A continuación se muestra una lista de comandos que muestran contadores de paquetes y estadísticas. Algunos de estos comandos duplican los resultados de otros comandos. En estos casos, puedes usar el comando que te resulte más útil. Consulta las notas de cada sección para entender mejor el resultado previsto de ejecutar el 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 muestra estadísticas de red que contienen valores de paquetes descartados por protocolo. Los paquetes descartados pueden deberse a que la aplicación o la interfaz de red se han quedado sin recursos. Consulta el motivo del contador para saber por qué se ha incrementado.
Consulta kern.log para ver los registros que coincidan 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 conexiones de la máquina virtual ha alcanzado el número máximo de conexiones que se pueden monitorizar. Es posible que se agote el tiempo de espera de otras conexiones a esta VM y desde ella. Si conntrack está habilitado, el número máximo de conexiones se puede consultar con el siguiente comando:
sudo sysctl net.netfilter.nf_conntrack_maxPuedes aumentar el valor de las conexiones máximas monitorizadas modificando sysctl
net.netfilter.nf_conntrack_maxo distribuyendo la carga de trabajo de las VMs en varias VMs para reducir la carga.
Interfaz de Windows
Perfmon
- En el menú de Windows, busca "perfmon" y abre el programa.
- En el menú de la izquierda, selecciona Rendimiento > Herramientas de monitorización > Monitor de rendimiento.
- En la vista principal, haz clic en el signo más (+) verde para añadir contadores de rendimiento al gráfico de monitorización. Los siguientes contadores son de interés:
- Adaptador de red
- Longitud de la cola de salida
- Paquetes salientes descartados
- Errores de paquetes salientes
- Paquetes recibidos descartados
- Errores de paquetes recibidos
- Paquetes recibidos desconocidos
- Interfaz de red
- Longitud de la cola de salida
- Paquetes salientes descartados
- Errores de paquetes salientes
- 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 pocos recursos por segundo
- Paquetes recibidos por segundo con pocos recursos
- Procesador
- Porcentaje de tiempo de interrupción
- % Tiempo privilegiado
- % de tiempo de procesador
- % Tiempo de usuario
- Adaptador de red
Pefmon te permite representar gráficamente los contadores anteriores en un gráfico de serie temporal. Puede ser útil para ver qué ocurre cuando se realizan pruebas o cuando un servidor se ve afectado. Los picos en los contadores relacionados con la CPU, como Tiempo de interrupción y Tiempo privilegiado, pueden indicar problemas de saturación cuando la VM alcanza las limitaciones de rendimiento de la CPU. Los descartes y errores de paquetes pueden producirse cuando la CPU está saturada, lo que provoca que los paquetes se pierdan antes de que los sockets del cliente o del servidor los procesen. Por último, la longitud de la cola de salida también aumentará durante la saturación de la CPU, ya que se pondrán en cola más paquetes para su 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 muestra estadísticas de red que contienen valores de paquetes descartados por protocolo. Los paquetes descartados pueden deberse a que la aplicación o la interfaz de red se han quedado sin recursos.
Si se produce un agotamiento de recursos, puedes intentar distribuir la carga de trabajo en más instancias, actualizar la VM a una con más recursos, optimizar el SO o la aplicación para satisfacer necesidades de rendimiento específicas, introducir el mensaje de error en un buscador para buscar posibles soluciones o pedir ayuda mediante uno de los métodos descritos en Si sigues teniendo problemas.
Si no parece que el problema sea el agotamiento de recursos, puede que el problema esté en el propio software del servidor. Para obtener ayuda sobre cómo solucionar problemas del software del servidor, consulta el artículo Comprobar el registro del servidor para obtener información sobre el comportamiento del servidor.
Consultar los registros del servidor para obtener información sobre el comportamiento del servidor
Si los pasos anteriores no revelan ningún problema, es posible que los tiempos de espera se deban al comportamiento de la aplicación, como las interrupciones del procesamiento causadas por el agotamiento de las vCPUs. Consulta los registros del servidor y de las aplicaciones para ver si hay indicios del comportamiento que estás experimentando.
Por ejemplo, un servidor que experimente un aumento de la latencia debido a un sistema upstream, como una base de datos con carga, podría poner en cola una cantidad excesiva de solicitudes, lo que puede provocar un aumento del uso de la memoria y de los tiempos de espera de la CPU. Estos factores pueden provocar errores de conexión o desbordamiento del búfer de socket.
Las conexiones TCP pierden paquetes de vez en cuando, pero el acuse de recibo selectivo y la retransmisión de paquetes suelen recuperar los paquetes perdidos, lo que evita que se agote el tiempo de espera de la conexión. En su lugar, ten en cuenta que los tiempos de espera pueden deberse a que el servidor de aplicaciones ha fallado o se ha vuelto a implementar, lo que ha provocado un fallo momentáneo en las conexiones.
Si tu aplicación de servidor depende de una conexión a una base de datos u otro servicio, confirma que los servicios acoplados no tengan un rendimiento deficiente. Tu aplicación puede registrar estas métricas.
Si sigues teniendo problemas
Si sigues teniendo problemas, consulta la sección Obtener asistencia para saber qué hacer a continuación. Es útil tener la salida de los pasos para solucionar problemas disponible para compartirla con otros colaboradores.
Siguientes pasos
- Si sigues teniendo problemas, consulta la página Recursos.