Résoudre les problèmes de connectivité interne entre les VM
Ce document indique les étapes à suivre pour résoudre les problèmes de connectivité entre des VM Compute Engine qui se trouvent dans le même réseau cloud privé virtuel (VPC partagé ou autonome) ou dans deux réseaux VPC connectés à l'aide de l'appairage de réseaux VPC. Nous partons du principe que les VM communiquent à l'aide des adresses IP internes de leurs contrôleurs d'interface réseau virtuels (vNIC) respectifs.
Les étapes décrites dans ce guide concernent les VM Compute Engine et les nœuds Google Kubernetes Engine.
Si vous souhaitez voir d'autres scénarios de dépannage spécifiques, cliquez sur le lien Envoyer des commentaires en bas de la page pour nous en informer.
Ce guide s'applique aux configurations de VM et de VPC suivantes :
- Connexions de VM à VM à l'aide d'adresses IP internes dans un seul réseau VPC
- Connexions de VM à VM à l'aide d'adresses IP internes dans un réseau VPC partagé
- Connexions de VM à VM à l'aide d'adresses IP internes dans différents réseaux VPC appairés à l'aide de l'appairage de réseaux VPC
Les commandes utilisées dans ce guide sont disponibles sur toutes les images de l'OS fournies par Google. Si vous utilisez votre propre image de l'OS, vous devrez peut-être installer les outils.
Quantifier le problème
- Si vous pensez que la perte de paquets est complète, consultez Résoudre un problème lié à l'échec complet de la connexion.
- Si vous subissez une latence, une perte de paquets partielle ou des délais d'inactivité en cours de connexion, consultez Résoudre les problèmes de latence ou de perte réseau impactant le débit.
Résoudre un problème lié à l'échec complet de la connexion
Les sections suivantes fournissent des étapes pour résoudre un problème lié à l'échec complet de la connectivité interne entre des VM. Si vous subissez plutôt une latence accrue ou des délais d'inactivité de la connexion intermittents, passez à Résoudre les problèmes de latence ou de perte réseau impactant le débit.
Déterminer les valeurs de connexion
Commencez par recueillir les informations suivantes :
- Sur la page Instances de VM, rassemblez les informations suivantes pour les deux VM :
- Noms des VM
- Zones des VM
- Adresses IP internes pour les vNIC qui communiquent
Dans la configuration du logiciel serveur de destination, rassemblez les informations suivantes :
- Protocole de couche 4
- Port de destination
Par exemple, si votre destination est un serveur HTTPS, le protocole est TCP et le port est généralement
443, mais votre configuration spécifique peut utiliser un port différent.
Si des problèmes surviennent avec plusieurs VM, choisissez une seule VM source et une seule VM de destination qui rencontrent des problèmes, puis utilisez ces valeurs. En général, vous n'avez pas besoin du port source de la connexion.
Une fois que vous disposez de ces informations, passez à Examiner les problèmes liés au réseau Google sous-jacent.
Examiner les problèmes liés au réseau Google sous-jacent
Si vous utilisez une configuration existante qui n'a pas changé récemment, le problème peut être lié au réseau Google sous-jacent. Consultez le module Performance Dashboard de Network Intelligence Center pour vérifier s'il existe une perte de paquets entre les zones de VM. Si la perte de paquets augmente entre les zones au cours de la période où vous avez subi des délais d'inactivité sur le réseau, cela peut indiquer que le problème est lié au réseau physique sous-jacent à votre réseau virtuel. Consultez le tableau de bord d'état du service Google Cloud pour en savoir plus sur les problèmes connus avant de déposer une demande d'assistance.
Si le problème ne semble pas lié au réseau Google sous-jacent, passez à Rechercher les règles de pare-feu mal configurées dans Google Cloud .
Rechercher les règles de pare-feu mal configurées dans Google Cloud
Le module Tests de connectivité analyse la configuration du chemin d'accès du réseau VPC entre deux VM et indique si la configuration programmée doit autoriser ou non le trafic. Si le trafic n'est pas autorisé, les résultats indiquent si une règle de pare-feu d'entrée ou de sortie Google Cloud bloque le trafic ou si une route n'est pas disponible.
Le module Tests de connectivité peut également tester de manière dynamique le chemin d'accès en envoyant des paquets entre les hyperviseurs des VM. Si ces tests sont effectués, leurs résultats sont affichés.
Ce module examine uniquement la configuration du réseau VPC. Il ne teste pas le pare-feu ni les routes du système d'exploitation, ni le logiciel serveur de la VM.
La procédure suivante exécute des tests de connectivité à partir de la consoleGoogle Cloud . Pour découvrir d'autres moyens d'exécuter des tests, consultez Exécuter des tests de connectivité.
Pour créer et exécuter un test, procédez comme suit :
Dans la console Google Cloud , accédez à la page Tests de connectivité.
Dans le menu déroulant du projet, vérifiez que vous êtes dans le bon projet ou spécifiez le projet concerné.
Cliquez sur Créer un test de connectivité.
Attribuez un nom au test.
Renseignez les champs suivants :
- Protocole
- Adresse IP du point de terminaison source
- Projet source et réseau VPC
- Adresse IP du point de terminaison de destination
- Projet de destination et réseau VPC
- Port de destination
Cliquez sur Créer.
Le test s'exécute immédiatement. Pour afficher le schéma des résultats, cliquez sur Afficher dans la colonne Résultats détaillés.
- Si les résultats indiquent que la connexion est supprimée par une règle de pare-feu Google Cloud, déterminez si la configuration de sécurité souhaitée doit autoriser la connexion. Vous devrez peut-être demander des informations à votre administrateur réseau ou de la sécurité. Si le trafic doit être autorisé, vérifiez les points suivants :
- Vérifiez la liste Trafic toujours bloqué. Si le trafic est bloqué par Google Cloud comme décrit dans la liste du trafic toujours bloqué, votre configuration existante ne fonctionnera pas.
- Accédez à la page "Stratégies de pare-feu" et examinez vos règles de pare-feu. Si le pare-feu est mal configuré, créez ou modifiez une règle de pare-feu pour autoriser la connexion. Il peut s'agir d'une règle de pare-feu VPC ou d'une règle de pare-feu hiérarchique.
- Si une règle de pare-feu correctement configurée bloque le trafic, contactez votre administrateur réseau ou de la sécurité. Si les exigences de sécurité de votre organisation impliquent que les VM ne doivent pas communiquer entre elles, vous devrez peut-être modifier votre configuration.
- Si les résultats indiquent qu'il n'y a pas de problème avec le chemin de connectivité VPC, il peut s'agir de l'un des problèmes suivants :
- Problèmes liés à la configuration de l'OS invité (problèmes avec le logiciel de pare-feu, par exemple)
- Problèmes avec les applications clientes ou de serveur (une application figée ou configurée pour écouter sur le mauvais port, par exemple)
Les étapes suivantes vous guideront lors de l'examen de chacune de ces possibilités. Passez à Tester la connectivité TCP depuis la VM.
Tester la connectivité TCP depuis la VM
Si votre test de connectivité de VM à VM n'a pas détecté de problème de configuration VPC, commencez à tester la connectivité d'OS à OS. Ces étapes vont vous aider à déterminer les éléments suivants :
- Si un serveur TCP écoute sur le port indiqué
- Si le logiciel de pare-feu côté serveur autorise les connexions à ce port depuis la VM cliente
- Si le logiciel de pare-feu côté client autorise les connexions à ce port sur le serveur
- Si la table de routage côté serveur est correctement configurée pour transférer les paquets
- Si la table de routage côté client est correctement configurée pour transférer les paquets
Vous pouvez tester le handshake TCP à l'aide de la commande curl sous Linux ou Windows 2019, ou à l'aide de la commande New-Object System.Net.Sockets.TcpClient avec Windows PowerShell. Le workflow de cette section doit entraîner l'un des résultats suivants : connexion établie, délai d'inactivité de la connexion ou réinitialisation de la connexion.
- Connexion établie : si le handshake TCP s'effectue correctement, alors une règle de pare-feu de l'OS ne bloque pas la connexion, l'OS transfère correctement les paquets et un serveur écoute sur le port de destination. Si tel est le cas, le problème peut être lié à l'application elle-même. Pour en savoir plus, consultez Vérifier la journalisation du serveur pour obtenir des informations sur le comportement du serveur.
- Délai d'inactivité : si votre connexion dépasse le délai, cela signifie généralement que l'un des événements suivants se produit :
- Il n'y a pas de machine à cette adresse IP.
- Un pare-feu supprime vos paquets en mode silencieux.
- Le routage de paquets de l'OS envoie les paquets à une destination qui ne peut pas les traiter, ou le routage asymétrique envoie le paquet de retour sur un chemin non valide.
Réinitialisation : si la connexion est en cours de réinitialisation, cela signifie que l'adresse IP de destination reçoit des paquets, mais qu'un OS ou une application les rejette. Le problème peut être dû à l'un des facteurs suivants :
- Les paquets arrivent sur la mauvaise machine et elle n'est pas configurée pour répondre à ce protocole sur ce port.
- Les paquets arrivent sur la bonne machine, mais aucun serveur n'écoute sur ce port.
- Les paquets arrivent sur la bonne machine et le bon port, mais les protocoles de niveau supérieur (SSL, par exemple) ne terminent pas leur handshake.
- Un pare-feu réinitialise la connexion. Cette situation est moins probable que celle où le pare-feu supprime les paquets en mode silencieux, mais cela peut se produire.
Linux
Dans la console Google Cloud , accédez à la page Stratégies de pare-feu.
Assurez-vous qu'il existe une règle de pare-feu autorisant les connexions SSH depuis IAP à votre VM ou créez-en une.
Dans la console Google Cloud , accédez à la page Instances de VM.
Recherchez votre VM source.
Cliquez sur SSH dans la colonne Connecter de cette VM.
À partir de la ligne de commande de la machine cliente, exécutez la commande suivante. Remplacez DEST_IP:DEST_PORT par l'adresse IP et le port de destination.
curl -vso /dev/null --connect-timeout 5 DEST_IP:DEST_PORT
Windows
Dans la console Google Cloud , accédez à la page Instances de VM.
Recherchez votre VM source.
Utilisez l'une des méthodes décrites sur la page Se connecter à des VM Windows pour vous connecter à votre VM.
À partir de la ligne de commande de la machine cliente, exécutez la commande suivante :
- Windows 2019 :
curl -vso /dev/null --connect-timeout 5 DEST_IP:DEST_PORT
- Windows 2012 ou Windows 2016 Powershell :
PS C:> New-Object System.Net.Sockets.TcpClient('DEST_IP',DEST_PORT)`
- Windows 2019 :
Connexion établie
Les résultats suivants indiquent un handshake TCP réussi. Si le handshake TCP s'effectue correctement, le problème n'est pas lié au délai d'inactivité ni à la réinitialisation de la connexion TCP. Cela signifie plutôt que le problème du délai d'inactivité survient dans les couches application. Si la connexion aboutit, passez à Vérifier la journalisation du serveur pour obtenir des informations sur le comportement du serveur.
Linux et Windows 2019
$ curl -vso /dev/null --connect-timeout 5 192.168.0.4:443
La ligne "Connecté à" indique un handshake TCP réussi.
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 et 2016
PS C:\> New-Object System.Net.Sockets.TcpClient('DEST_IP_ADDRESS', PORT)
Résultat de connexion réussie. La ligne "Connected: True" est pertinente.
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
Délai d'inactivité de la connexion
Les résultats suivants indiquent que la connexion a dépassé le délai. Si votre connexion dépasse le délai, passez à Vérifier l'adresse IP et le port du serveur.
Linux et Windows 2019
$ curl -vso /dev/null --connect-timeout 5 DEST_IP_ADDRESS:PORT
Résultat du délai d'inactivité de la connexion :
Trying 192.168.0.4:443... Connection timed out after 5000 milliseconds Closing connection 0
Windows 2012 et 2016
PS C:\> New-Object System.Net.Sockets.TcpClient('DEST_IP_ADDRESS', PORT)
Résultat du délai d'inactivité de la connexion :
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"
Réinitialisation de la connexion
Une réinitialisation signifie qu'un appareil renvoie un paquet RST au client pour l'informer que la connexion a été interrompue. La connexion peut être réinitialisée pour l'une des raisons suivantes :
- Le serveur de réception n'a pas été configuré pour accepter les connexions pour ce protocole sur ce port. Cela peut être dû au fait que le paquet a été envoyé au mauvais serveur ou au mauvais port, ou que le logiciel serveur a été mal configuré.
- Un logiciel de pare-feu a refusé la tentative de connexion.
Si la connexion a été réinitialisée, passez à Vérifier que vous accédez à la bonne adresse IP et au bon port.
Linux et Windows 2019
$ curl -vso /dev/null --connect-timeout 5 DEST_IP_ADDRESS:PORT
Résultat de la réinitialisation de la connexion :
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 et 2016
PS C:\> New-Object System.Net.Sockets.TcpClientt('DEST_IP_ADDRESS', PORT)
Résultat de la réinitialisation de la connexion :
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"
Vérifier l'adresse IP et le port du serveur
Exécutez l'une des commandes suivantes sur votre serveur. Elles indiquent si un serveur écoute sur le port nécessaire.
Linux
$ sudo netstat -ltuvnp
Le résultat indique qu'un serveur TCP écoute n'importe quelle adresse IP de destination (0.0.0.0) sur le port 22, acceptant les connexions à partir de n'importe quelle adresse source (0.0.0.0) et de n'importe quel port source (*). La colonne PID/Program name spécifie le fichier exécutable lié au 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
Vous obtenez les résultats de l'exécution de la commande avec DEST_PORT défini sur 443.
Le code affiché indique qu'un serveur TCP écoute n'importe quelle adresse (0.0.0.0) sur le port 443, acceptant les connexions à partir de n'importe quelle adresse source (0.0.0.0) et de n'importe quel port source (0). La colonne OwningProcess contient l'identifiant du processus qui écoute le 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 vous constatez que le serveur n'est pas lié au bon port ni à la bonne adresse IP, ou que le préfixe distant ne correspond pas à votre client, consultez la documentation ou le fournisseur du serveur pour résoudre le problème. Le serveur doit être lié à l'adresse IP d'une interface spécifique ou à 0.0.0.0, et il doit accepter les connexions issues du préfixe d'adresse IP client approprié ou de 0.0.0.0.
Si le serveur d'application est lié à la bonne adresse IP et au bon port, il se peut que le client accède au mauvais port, qu'un protocole de niveau supérieur (souvent TLS) refuse activement la connexion ou qu'un pare-feu rejette la connexion.
Vérifiez que le client et le serveur utilisent la même version TLS et la même procédure de chiffrement.
Assurez-vous que votre client accède au bon port.
Si les étapes précédentes ne permettent pas de résoudre le problème, passez à Vérifier la présence de paquets supprimés dans les pare-feu du client et du serveur.
Vérifier la présence de paquets supprimés dans les pare-feu du client et du serveur
Si le serveur est inaccessible depuis la VM cliente, mais écoute sur le port approprié, il est possible que l'une des VM exécute un logiciel de pare-feu qui supprime les paquets associés à la connexion. Vérifiez le pare-feu sur la VM cliente et la VM du serveur à l'aide des commandes indiquées ci-dessous.
Si une règle bloque votre trafic, vous pouvez mettre à jour le logiciel de pare-feu pour autoriser le trafic. Si vous mettez à jour le pare-feu, soyez prudent lorsque vous préparez et exécutez les commandes, car un pare-feu mal configuré peut bloquer le trafic inattendu. Envisagez de configurer l'accès à la console série de VM avant de continuer.
Linux iptables
Vérifiez le nombre de paquets traités pour chaque chaîne et règle iptables installées. Déterminez quelles règles DROP sont mises en correspondance en comparant les adresses IP et les ports sources et de destination avec les préfixes et les ports spécifiés par les règles iptables.
Si une règle correspondante indique une hausse des suppressions avec des délais d'inactivité de la connexion, consultez la documentation sur les iptables pour appliquer la bonne règle allow aux connexions appropriées.
$ sudo iptables -L -n -v -x
Cet exemple de chaîne INPUT montre que les paquets depuis n'importe quelle adresse IP vers n'importe quelle adresse IP utilisant le port TCP de destination 5000 seront supprimés au niveau du pare-feu.
La colonne pkts indique que la règle a supprimé 10 342 paquets. Par conséquent, si vous créez des connexions qui sont supprimées par cette règle, vous constaterez une augmentation du compteur de pkts, ce qui confirmera le comportement.
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
Vous pouvez ajouter une règle d'entrée ou de sortie à iptables à l'aide des commandes suivantes :
Règle d'entrée :
$ sudo iptables -A INPUT -p tcp -s SOURCE_IP_PREFIX --dport SERVER_PORT -j ACCEPT
Règle de sortie :
$ sudo iptables -A OUTPUT -p tcp -d DEST_IP_PREFIX --dport DEST_PORT -j ACCEPT
Pare-feu Windows
Vérifiez dans le pare-feu Windows que la connexion est autorisée à sortir du client et à entrer dans le serveur. Si une règle bloque votre trafic, effectuez les corrections nécessaires dans le pare-feu Windows pour autoriser les connexions. Vous pouvez également activer la journalisation du pare-feu Windows.
Le comportement par défaut DENY du pare-feu Windows consiste à supprimer silencieusement les paquets refusés, ce qui entraîne des délais d'inactivité.
Cette commande vérifie le serveur. Pour vérifier les règles de sortie sur la VM cliente, remplacez la valeur -match par 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
Vous pouvez ajouter des règles de pare-feu à Windows à l'aide des commandes indiquées ci-dessous.
Règle de sortie :
PS C:\> netsh advfirewall firewall add rule name="My Firewall Rule" dir=out action=allow protocol=TCP remoteport=DEST_PORT
Règle d'entrée :
PS C:\> netsh advfirewall firewall add rule name="My Firewall Rule" dir=in action=allow protocol=TCP localport=PORT
Logiciels tiers
Les logiciels antivirus ou les pare-feu d'application tiers peuvent également supprimer ou rejeter les connexions. Veuillez consulter la documentation de votre fournisseur.
Si vous rencontrez un problème avec les règles de pare-feu et que vous le corrigez, retestez votre connectivité. Si les règles de pare-feu ne semblent pas être à l'origine du problème, passez à Vérifier la configuration du routage de l'OS.
Vérifier la configuration du routage de l'OS
Les problèmes de routage du système d'exploitation peuvent provenir de l'une des situations suivantes :
- Les problèmes de routage surviennent le plus fréquemment sur les VM avec plusieurs interfaces réseau en raison de la complexité supplémentaire du routage.
- Sur une VM créée dans Google Cloud avec une seule interface réseau, les problèmes de routage n'arrivent généralement que si quelqu'un a modifié manuellement la table de routage par défaut.
- Sur une VM migrée depuis un environnement sur site, la VM peut contenir des paramètres de routage ou de MTU qui étaient nécessaires sur site, mais qui causent des problèmes dans le réseau VPC.
Si vous utilisez une VM avec plusieurs interfaces réseau, les routes doivent être configurées pour sortir vers le vNIC et le sous-réseau appropriés. Par exemple, une VM peut avoir des routes configurées de sorte que le trafic destiné aux sous-réseaux internes soit envoyé à un vNIC, mais la passerelle par défaut (destination : 0.0.0.0/0) est configurée sur un autre vNIC qui possède une adresse IP externe ou un accès à Cloud NAT.
Vous pouvez examiner les routes en vérifiant les routes individuelles une par une ou en consultant l'intégralité de la table de routage de la VM. Si l'une des approches révèle des problèmes liés à la table de routage, suivez les étapes décrites dans Mettre à jour les tables de routage si nécessaire.
Examiner toutes les routes
Dressez la liste de toutes vos routes pour identifier celles qui existent déjà sur votre 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
Vérifier les routes individuelles
Si un préfixe d'adresse IP semble être le problème, vérifiez qu'il existe des routes appropriées pour les adresses IP source et de destination sur la VM cliente et la VM du serveur.
Linux
$ ip route get DEST_IP
Résultat correct :
Une route valide est affichée. Dans ce cas, les paquets sortent de l'interface ens4.
10.3.0.34 via 10.3.0.1 dev ens4 src 10.3.0.26 uid 1000 cache
Résultat incorrect :
Ce résultat confirme que les paquets sont supprimés, car il n'y a pas de chemin vers le réseau de destination. Vérifiez que votre table de routage contient un chemin d'accès à l'interface de sortie appropriée.
**RTNETLINK answers: Network is unreachable
Windows
PS C:\> Find-NetRoute -RemoteIpAddress "DEST_IP"
Résultat correct :
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
Résultat incorrect :
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
Cette commande confirme que les paquets sont supprimés, car il n'existe aucun chemin d'accès à l'adresse IP de destination. Vérifiez que vous disposez d'une passerelle par défaut et que la passerelle est appliquée au vNIC et au réseau appropriés.
Mettre à jour les tables de routage
Si nécessaire, vous pouvez ajouter une route à la table de routage de votre système d'exploitation. Avant que vous exécutiez une commande pour mettre à jour la table de routage de la VM de routage, nous vous recommandons de vous familiariser avec les commandes et de comprendre les implications possibles. Si vous n'utilisez pas correctement les commandes destinées à mettre à jour les routes, des problèmes ou une déconnexion de la VM peuvent survenir de façon inattendue. Envisagez de configurer l'accès à la console série de VM avant de continuer.
Consultez la documentation de votre système d'exploitation pour obtenir des instructions sur la mise à jour des routes.
Si vous rencontrez un problème avec les routes et que vous le corrigez, retestez votre connectivité. Si les routes ne semblent pas être à l'origine du problème, passez à Vérifier la MTU de l'interface.
Vérifier la MTU
La MTU de l'interface d'une VM doit correspondre à la MTU du réseau VPC auquel elle est associée. Dans l'idéal, les VM qui communiquent entre elles ont également des MTU correspondantes. Les MTU non concordantes ne sont généralement pas un problème pour TCP, mais peuvent en présenter un pour UDP.
Vérifiez la MTU du VPC. Si les VM se trouvent sur deux réseaux différents, vérifiez les deux.
gcloud compute networks describe NET_NAME --format="table(name,mtu)"
Vérifiez la configuration de la MTU des interfaces réseau du client et du serveur.
Linux
$ netstat -i
L'interface lo (rebouclage) a toujours une MTU de 65 536 et peut être ignorée pour cette étape.
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
Les pseudo-interfaces de rebouclage ont toujours une MTU de 4 294 967 295 et peuvent être ignorées pour cette étape.
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 les MTU de l'interface et du réseau ne correspondent pas, vous pouvez reconfigurer la MTU de l'interface. Pour en savoir plus, consultez Paramètres des VM et MTU. Si elles correspondent et si vous avez suivi les étapes de dépannage jusqu'à présent, le problème se situe probablement au niveau du serveur. Pour avoir des conseils sur la résolution des problèmes liés au serveur, consultez Vérifier la journalisation du serveur pour obtenir des informations sur le comportement du serveur.
Vérifier la journalisation du serveur pour obtenir des informations sur le comportement du serveur
Si les étapes précédentes ne permettent pas de résoudre un problème, il se peut que l'application soit à l'origine des délais d'inactivité. Consultez les journaux du serveur et de l'application pour déterminer le comportement qui expliquerait ce que vous voyez.
Sources du journal à vérifier :
- Cloud Logging pour la VM
- Journaux des ports série de la VM
- Linux syslog et kern.log, ou la visionneuse d'événements Windows
Si les problèmes persistent
Si vous rencontrez toujours des problèmes, consultez Obtenir de l'aide pour les étapes suivantes. Nous vous recommandons de mettre les résultats des étapes de dépannage ci-dessus à la disposition d'autres collaborateurs.
Résoudre les problèmes de latence ou de perte réseau impactant le débit
Les problèmes de latence ou de perte de réseau sont généralement causés par l'épuisement des ressources ou des goulots d'étranglement sur une VM ou dans un chemin d'accès réseau. Il peut arriver que la perte du réseau provoque des délais d'inactivité de la connexion intermittents. Des causes telles que l'épuisement des vCPU ou la saturation des vNIC augmentent la latence et la perte de paquets, ce qui entraîne une réduction des performances réseau.
Pour les instructions suivantes, nous partons du principe que les connexions ne dépassent pas systématiquement le délai et que vous rencontrez plutôt des problèmes de capacité ou de performances limitées. Si vous constatez une perte de paquets complète, consultez Résoudre un problème lié à l'échec complet de la connexion.
De petites variations de latence (de quelques millisecondes, par exemple), sont normales. Les latences varient en raison de la charge réseau ou de la mise en file d'attente sur la VM.
Déterminer les valeurs de connexion
Commencez par recueillir les informations suivantes :
- Sur la page Instances de VM, rassemblez les informations suivantes pour les deux VM :
- Noms des VM
- Zones des VM
- Adresses IP internes pour les vNIC qui communiquent
- Dans la configuration du logiciel serveur de destination, rassemblez les informations suivantes :
- Protocole de couche 4
- Port de destination
Si des problèmes surviennent avec plusieurs VM, choisissez une seule VM source et une seule VM de destination qui rencontrent des problèmes, puis utilisez ces valeurs. En général, vous n'avez pas besoin du port source de la connexion.
Une fois que vous disposez de ces informations, passez à Examiner les problèmes liés au réseau Google sous-jacent.
Examiner les problèmes liés au réseau Google sous-jacent
Si vous utilisez une configuration existante qui n'a pas changé récemment, le problème peut être lié au réseau Google sous-jacent. Consultez le module Performance Dashboard de Network Intelligence Center pour vérifier s'il existe une perte de paquets entre les zones de VM. Si la perte de paquets augmente entre les zones au cours de la période où vous avez rencontré des délais d'inactivité sur le réseau, cela peut indiquer que le problème est lié au réseau physique sous-jacent à votre réseau virtuel. Consultez le tableau de bord d'état du service Google Cloud pour en savoir plus sur les problèmes connus avant de déposer une demande d'assistance.
Si le problème ne semble pas lié au réseau Google sous-jacent, passez à Vérifier la latence de handshake.
Vérifier la latence du handshake
Tous les protocoles basés sur la connexion entraînent une latence pendant le handshake de configuration des connexions. Chaque handshake de protocole s'ajoute à la surcharge. Pour les connexions SSL/TLS, par exemple, le handshake TCP doit se terminer avant que le handshake SSL/TLS puisse démarrer, puis le handshake TLS doit être terminé pour que les données puissent être transmises.
La latence du handshake dans la même zone Google Cloud est généralement négligeable, mais les handshakes dans des régions du monde éloignées peuvent entraîner des retards plus importants lors du lancement de la connexion. Si vous disposez de ressources dans des régions éloignées, vous pouvez vérifier si la latence est due à un handshake de protocole.
Linux et 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 correspond à la durée entre le moment où le client envoie le paquet SYN initial et le moment où le client envoie l'accusé de réception du handshake TCP.
- application_handshake correspond à la durée entre le premier paquet SYN du handshake TCP et la fin du handshake TLS (en général).
- temps de handshake supplémentaire = application_handshake - tcp_handshake
Windows 2012 et 2016
Non disponible avec les outils de l'OS par défaut. Le délai aller-retour ICMP peut être utilisé comme référence si les règles de pare-feu le permettent.
Si la latence est supérieure à celle que les handshakes pourraient tenir, passez à Déterminer le débit maximal de votre type de VM.
Déterminer le débit maximal de votre type de VM
Le débit de sortie du réseau de la VM est limité par l'architecture du processeur de la VM et le nombre de vCPU. Pour déterminer la bande passante de sortie potentielle de votre VM, consultez la page Bande passante réseau.
Si votre VM n'est pas en mesure de répondre à vos exigences de sortie, envisagez de la mettre à niveau vers une VM plus grande. Pour obtenir des instructions, consultez Modifier le type de machine d'une instance.
Si votre type de machine doit autoriser une bande passante de sortie suffisante, déterminez si l'utilisation du disque persistant interfère avec votre sortie réseau. Les opérations des disques persistants sont autorisées à occuper jusqu'à 60 % du débit réseau total de votre VM. Pour déterminer si les opérations de disque persistant peuvent interférer avec le débit du réseau, consultez Vérifier les performances du disque persistant.
L'entrée réseau d'une VM n'est pas limitée par le réseau VPC ni par le type d'instance de VM. Elle est déterminée par les performances de mise en file d'attente et de traitement des paquets du système d'exploitation ou de l'application de la VM. Si votre bande passante de sortie est suffisante, mais que vous rencontrez des problèmes d'entrée, consultez Vérifier la journalisation du serveur pour obtenir des informations sur le comportement du serveur.
Vérifier la MTU de l'interface
La MTU d'un réseau VPC est configurable. La MTU de l'interface sur la VM doit correspondre à la valeur de la MTU du réseau VPC auquel elle est associée. Dans un cas d'appairage de réseaux VPC, les VM de différents réseaux peuvent avoir des MTU différentes. Lorsque ce scénario se produit, appliquez la valeur de MTU la plus faible aux interfaces associées. Les incohérences de MTU ne sont généralement pas des problèmes pour TCP, mais peuvent l'être pour UDP.
Vérifiez la MTU du VPC. Si les VM se trouvent sur deux réseaux différents, vérifiez les deux.
gcloud compute networks describe NET_NAME --format="table(name,mtu)"
Vérifiez la configuration de la MTU de votre interface réseau.
Linux
L'interface lo (rebouclage) a toujours une MTU de 65 536 et peut être ignorée pour cette étape.
$ 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
Les pseudo-interfaces de rebouclage ont toujours une MTU de 4 294 967 295 et peuvent être ignorées pour cette étape.
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 les MTU de l'interface et du réseau ne correspondent pas, vous pouvez reconfigurer la MTU de l'interface. Pour obtenir des instructions sur la mise à jour de la MTU des VM Windows, consultez Paramètres des VM et MTU. Si elles correspondent, le problème est probablement lié à la disponibilité du serveur. L'étape suivante consiste à consulter les journaux pour voir si une VM a été redémarrée, arrêtée ou migrée à chaud afin de voir si quelque chose s'est produit sur votre VM à un moment donné.
Consulter les journaux pour voir si une VM a été redémarrée, arrêtée ou migrée à chaud
Au cours de son cycle de vie, une VM peut être redémarrée par l'utilisateur, migrée à chaud pour la maintenanceGoogle Cloud ou, dans de rares cas, peut être perdue et recréée en cas de défaillance dans l'hôte physique où elle se trouve. Ces événements peuvent entraîner une brève augmentation de la latence ou des délais d'inactivité de la connexion. Si l'un de ces événements se produit sur la VM, l'événement est enregistré.
Pour afficher les journaux de votre VM, procédez comme suit :
Dans la console Google Cloud , accédez à la page Journalisation.
Choisissez la période à laquelle la latence s'est produite.
Utilisez la requête de journalisation suivante pour déterminer si un événement de VM est survenu aux alentours de la période pendant laquelle la latence s'est produite :
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 les VM n'ont pas redémarré ou n'ont pas migré pendant la période appropriée, le problème peut être dû à l'épuisement des ressources. Pour le savoir, passez à Vérifier les statistiques du réseau et de l'OS pour les suppressions de paquets en raison de l'épuisement des ressources.
Vérifier les statistiques du réseau et de l'OS pour les suppressions de paquets en raison de l'épuisement des ressources
L'épuisement des ressources est un terme général qui signifie qu'il est demandé à une ressource de la VM, telle que la bande passante de sortie, de gérer plus de ressources qu'elle ne le peut. L'épuisement des ressources peut entraîner la suppression périodique des paquets, ce qui provoquer des délais d'inactivité ou une latence de la connexion. Il est possible que ces délais d'inactivité ne soient pas visibles au démarrage du client ou du serveur, mais ils peuvent apparaître par la suite lorsqu'un système épuise des ressources.
Voici une liste de commandes qui affichent les compteurs de paquets et les statistiques. Certaines de ces commandes dupliquent les résultats d'autres commandes. Dans ce cas, vous pouvez utiliser la commande qui vous convient le mieux. Consultez les notes de chaque section pour mieux comprendre le résultat attendu de la commande. Il peut être utile d'exécuter les commandes à différents moments pour voir si des suppressions ou des erreurs se produisent en même temps que le problème.
Linux
Utilisez la commande
netstatpour afficher les statistiques du réseau.$ 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
La commande netstat génère des statistiques réseau contenant les valeurs des paquets supprimés par protocole. La suppression des paquets peut être due à l'épuisement des ressources par l'application ou l'interface réseau. Affichez le motif de compteur pour indiquer pourquoi un compteur a été incrémenté.
Consultez le fichier kern.log pour rechercher les journaux correspondant à
nf_conntrack: table full, dropping packet.Debian :
cat /var/log/kern.log | grep "dropping packet"CentOS :
sudo cat /var/log/dmesg | grep "dropping packet"Ce journal indique que la table de suivi des connexions de la VM a atteint le nombre maximal de connexions pouvant être suivies. D'autres connexions vers et depuis cette VM peuvent dépasser le délai. Si conntrack a été activé, vous pouvez afficher le nombre maximal de connexions avec la commande suivante
sudo sysctl net.netfilter.nf_conntrack_max.Vous pouvez augmenter la valeur du nombre maximal de connexions suivies en modifiant le fichier sysctl
net.netfilter.nf_conntrack_maxou en répartissant la charge de travail d'une VM sur plusieurs VM afin de réduire la charge.
UI Windows
Perfmon
- Dans le menu de Windows, recherchez "perfmon" et ouvrez le programme.
- Dans le menu de gauche, sélectionnez Performance > Outils d'analyse > Analyseur de performances.
- Dans la vue principale, cliquez sur le signe vert plus "+" pour ajouter des compteurs de performances au graphique de surveillance. Les compteurs suivants sont importants :
- Carte réseau
- Longueur de la file d'attente de sortie
- Paquets sortants supprimés
- Erreurs des paquets sortants
- Paquets reçus supprimés
- Erreurs des paquets reçus
- Paquets reçus inconnus
- Interface réseau
- Longueur de la file d'attente de sortie
- Paquets sortants supprimés
- Erreurs des paquets sortants
- Paquets reçus supprimés
- Erreurs des paquets reçus
- Paquets reçus inconnus
- Activité de la carte d'interface réseau par processeur
- Faibles indications de réception de ressources par seconde
- Faible nombre de paquets de ressources reçus par seconde
- Processeur
- % de temps d'interruption
- % de temps privilégié
- % de temps processeur
- % de temps utilisateur
- Carte réseau
perfmon vous permet de représenter les compteurs ci-dessus sur un graphique de séries temporelles. Cela peut être utile lorsque des tests sont effectués ou lorsqu'un serveur est actuellement affecté. Des pics de compteurs liés au processeur, tels que le temps d'interruption et le temps privilégié, peuvent indiquer des problèmes de saturation lorsque la VM atteint les limites de débit du processeur. Des suppressions et des erreurs de paquets peuvent se produire lorsque le processeur est saturé, ce qui entraîne la perte des paquets avant qu'ils soient traités par les sockets client ou serveur. Enfin, la longueur de la file d'attente de sortie augmente également avec la saturation du processeur à mesure que d'autres paquets sont mis en file d'attente pour traitement.
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
La commande netstat génère des statistiques réseau contenant les valeurs des paquets supprimés par protocole. La suppression des paquets peut être due à l'épuisement des ressources par l'application ou l'interface réseau.
Si vous constatez que vos ressources sont épuisées, vous pouvez essayer de répartir votre charge de travail sur un plus grand nombre d'instances, mettre à niveau la VM vers une instance disposant de plus de ressources, régler l'OS ou l'application en fonction des besoins spécifiques en termes de performances, saisir le message d'erreur dans un moteur de recherche pour trouver des solutions possibles ou demander de l'aide en suivant l'une des méthodes décrites dans Si les problèmes persistent.
Si l'épuisement des ressources ne semble pas être le problème, la situation est peut-être due au logiciel serveur lui-même. Pour obtenir des conseils sur la résolution des problèmes liés à un logiciel serveur, consultez Vérifier la journalisation du serveur pour obtenir des informations sur le comportement du serveur.
Vérifier la journalisation du serveur pour obtenir des informations sur le comportement du serveur
Si les étapes ci-dessus ne révèlent pas de problème, les délais d'inactivité peuvent être causés par un comportement de l'application, tel que des blocages de traitement provoqués par l'épuisement du vCPU. Consultez les journaux du serveur et de l'application pour obtenir des indications sur le comportement auquel vous faites face.
Par exemple, un serveur soumis à une latence accrue en raison d'un système en amont, tel qu'une base de données avec une charge élevée, peut mettre en file d'attente un nombre excessif de requêtes. Cela peut alors entraîner une utilisation plus intensive de la mémoire et des temps d'attente plus longs des processeurs. Ces facteurs peuvent entraîner l'échec de connexions ou le dépassement du tampon de socket.
Les connexions TCP perdent parfois un paquet, mais celui-ci est généralement récupéré par l'accusé de réception et la retransmission sélectifs des paquets, évitant ainsi les délais d'inactivité de la connexion. Au lieu de cela, une défaillance ou un redéploiement du serveur d'applications peuvent être à l'origine du délai d'inactivité, entraînant ainsi une défaillance temporaire des connexions.
Si votre application de serveur repose sur une connexion à une base de données ou à un autre service, assurez-vous que les services couplés fonctionnent correctement. Votre application peut suivre ces métriques.
Si les problèmes persistent
Si vous rencontrez toujours des problèmes, consultez Obtenir de l'aide pour les étapes suivantes. Nous vous recommandons de mettre les résultats des étapes de dépannage à la disposition d'autres collaborateurs.
Étapes suivantes
- Si le problème persiste, consultez la page Ressources.