Résoudre les problèmes de connectivité interne entre les VM
Ce document fournit les étapes à suivre pour résoudre les problèmes de connectivité entre les VM Compute Engine qui se trouvent dans le même réseau cloud privé virtuel (VPC partagé ou autonome) ou deux réseaux VPC connectés à l'aide de l'appairage de réseaux VPC. Il suppose que les VM communiquent à l'aide des adresses IP internes de leurs cartes d'interface de réseau virtuel (vNIC) respectives.
Les étapes décrites dans ce guide s'appliquent aux VM Compute Engine et aux 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 au sein d'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.
Quantifiez le problème
- Si vous pensez que la perte de paquets est complète, consultez la section Résoudre les échecs de connexion complète.
- Si vous rencontrez une latence, une perte de paquets partielle ou des délais avant expiration en cours de connexion, consultez la section Résoudre les problèmes de latence ou de perte de réseau entraînant des problèmes de débit.
Résoudre un échec de connexion complète
Les sections suivantes fournissent des étapes pour dépanner une défaillance complète de connectivité interne entre des VM. Si vous rencontrez plutôt une latence accrue ou des délais avant expiration de connexion intermittents, passez à la section Résolution des problèmes de latence ou de perte réseau entraînant des problèmes de 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 vous rencontrez des problèmes avec plusieurs VM, choisissez une seule VM source et une seule VM de destination qui rencontre 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 à la section 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é, le problème peut être lié au réseau Google sous-jacent. tableau de bord des performances 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é 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 de Google Cloud pour connaître 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 à la section 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
Les tests de connectivité analysent la configuration du chemin 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.
Les tests de connectivité peuvent également tester de manière dynamique le chemin en envoyant des paquets entre les hyperviseurs des VM. Si ces tests sont effectués, les résultats de ces tests sont affichés.
Les tests de connectivité examinent uniquement la configuration du réseau VPC. Ils ne testent pas le pare-feu du système d'exploitation, 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 console Google Cloud. Pour découvrir d'autres moyens d'exécuter des tests, consultez la page Exécuter des tests de connectivité.
Pour créer et exécuter un test, procédez comme suit :
Dans Google Cloud Console, 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 bon.
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 View (Afficher) dans la colonne Result details (Détails du résultat).
- 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 de la sécurité ou du réseau. 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 Règles 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. Cette règle peut être une règle de pare-feu VPC ou une règle de stratégie de pare-feu hiérarchique.
- Si une règle de pare-feu correctement configurée bloque le trafic, contactez votre administrateur de la sécurité ou du réseau. 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, le problème peut être l'un des éléments suivants.
- Problèmes liés à la configuration de l'OS invité, tels que des problèmes liés au logiciel de pare-feu.
- Problèmes avec les applications clientes ou de serveur, telles qu'une application figée ou configurée pour écouter sur le mauvais port.
Les étapes suivantes vous guideront lors de l'examen de chacune de ces possibilités. Passez à la section Tester la connectivité TCP depuis la VM.
Tester la connectivité TCP depuis la VM
Si votre test de connectivité VM à VM n'a pas détecté de problème de configuration VPC, commencez à tester la connectivité OS à OS. Les étapes suivantes vous aident à 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 avec 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 : réussite de la connexion, délai avant expiration de la connexion ou réinitialisation de la connexion.
- Réussite : si le handshake TCP s'effectue avec succès, alors, une règle de pare-feu de système d'exploitation ne bloque pas la connexion, et le système d'exploitation 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 plus d'informations, consultez la section Vérifier la journalisation du serveur pour plus d'informations sur le comportement du serveur.
- Délai avant expiration : 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. Il peut s'agir de l'un des éléments 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 machine appropriée, mais aucun serveur n'écoute sur ce port
- Les paquets arrivent sur la machine et le port corrects, mais les protocoles de niveau supérieur (tels que SSL) ne terminent pas leur handshake.
- Un pare-feu réinitialise la connexion. Cette situation est moins probable que celle ou le pare-feu supprime les paquets en mode silencieux, mais cela peut se produire.
Linux
Dans la console Google Cloud, accédez à la page Règles d'administration.
Assurez-vous qu'il existe une règle de pare-feu autorisant les connexions SSH à partir d'IAP à votre VM ou créez-en une.
Dans Google Cloud Console, 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 Google Cloud Console, 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 avec succès, le problème n'est pas lié au délai avant expiration ou à la réinitialisation de la connexion TCP. Au lieu de cela, le problème de délai avant expiration se produit dans les couches d'application. Si vous obtenez une connexion réussie, passez à la journalisation des serveurs pour obtenir des informations sur le comportement des serveurs.
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 de connexion
Les résultats suivants indiquent que la connexion a dépassé le délai. Si votre connexion dépasse le délai, passez à la section 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'expiration 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'expiration 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"
Connexion réinitialisée
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 à la section Vérifier que vous accédez à l'adresse IP et au port corrects.
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/Nom du programme 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
Le résultat affiche les résultats de l'exécution de la commande avec DEST_PORT défini sur 443.
Ce résultat 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 indique l'ID 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 port ou à l'adresse IP corrects, 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 particulière 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é à l'adresse IP et au port corrects, 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 création de chiffrement.
Vérifiez que votre client accède au bon port.
Si les étapes précédentes ne résolvent pas le problème, passez à la section Vérifier la présence de paquets dans les pare-feu du client et du serveur.
Vérifier la présence de paquets 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 les VM clientes et du serveur à l'aide des commandes suivantes.
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 des suppressions croissantes avec des délais de connexion, consultez la documentation sur les iptables pour appliquer la règle allow appropriée 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 sont 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 avant expiration.
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 de nouvelles règles de pare-feu à Windows à l'aide des commandes suivantes.
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 fournie par 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 à la page Vérifiez 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 sont les plus courants 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 ne se produisent généralement que si quelqu'un a modifié manuellement la table de routage par défaut.
- Sur une VM migrée sur site vers une réseau VPC, 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 la 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é à une vNIC, mais la passerelle par défaut (destination 0.0.0.0/0) est configurée sur une 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 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 la section Mettre à jour les tables de routage si nécessaire.
Examiner toutes les routes
Répertoriez 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 dans les VM clientes et du serveur.
Linux
$ ip route get DEST_IP
Résultat correct :
Une route valide est affichée. Dans ce cas, les paquets sortant 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 à la vNIC et au réseau corrects.
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 d'exécuter 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. Une utilisation incorrecte des commandes de mise à jour de route peut entraîner des problèmes inattendus ou une déconnexion de la VM. 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 à la page 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 la section 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 obtenir des conseils sur la résolution des problèmes liés au serveur, consultez la page 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épassements de délai. Consultez les journaux du serveur et des applications pour déterminer le comportement qui expliquerait ce que vous voyez.
Sources du journal à vérifier :
- Cloud Logging pour la VM
- Journaux 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 la section Obtenir de l'aide pour les étapes suivantes. Il est utile que les résultats des étapes de dépannage ci-dessus soient disponibles pour le partage avec d'autres collaborateurs.
Résoudre les problèmes de latence ou de perte réseau entraînant des problèmes de 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 au sein d'une VM ou d'un chemin réseau. Il peut arriver que la perte du réseau provoque des délais de connexion intermittents. Des causes telles que l'épuisement des vCPU ou la saturation des cartes virtuelles entraînent une augmentation de la latence et de la perte de paquets, ce qui entraîne une réduction des performances réseau.
Les instructions suivantes supposent que les connexions ne dépassent pas le délai systématiquement et que vous rencontrez des problèmes de capacité ou de performances limitées. Si vous constatez une perte de paquets complète, consultez la section Résoudre un échec de connexion complet.
De petites variations de latence, telles que les latences variables de quelques millisecondes, sont normales. Les latences varient en raison de la charge réseau ou de la mise en file d'attente à l'intérieur de 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 vous rencontrez des problèmes avec plusieurs VM, choisissez une seule VM source et une seule VM de destination qui rencontre 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 à la section 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é, le problème peut être lié au réseau Google sous-jacent. tableau de bord des performances 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é 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 de Google Cloud pour connaître 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 à la section Vérifier la latence de handshake.
Vérifier la latence de 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 ne puisse démarrer, puis le handshake TLS doit être terminé pour que les données puissent être transmises.
La latence de handshake dans la même zone Google Cloud est généralement négligeable, mais les handshakes dans des lieux situés à l'échelle mondiale peuvent entraîner des retards plus importants lors du lancement de la connexion. Si vous disposez de ressources dans des régions distantes, vous pouvez vérifier si la latence est due à un handshake de protocoles.
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 protocole TLS (généralement).
- temps de handshake supplémentaire = application_handshake - tcp_handshake
Windows 2012 et 2016
Non disponible avec les outils du système d'exploitation 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 à la section 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 processeurs virtuels. 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 la page 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 la page Vérifier les performances des disques persistants.
L'entrée réseau d'une VM n'est pas limitée par le réseau VPC ou le type d'instance de VM. Elle est déterminée par les performances de mise en file d'attente et de traitement du paquet 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 la section Vérifier la journalisation du serveur pour plus d'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 ê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 la page 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 du cycle de vie d'une VM, une VM peut être redémarrée par l'utilisateur, migrée à chaud pour la maintenance Google Cloud ou, dans de rares cas, une VM peut être perdue et recréée en cas de défaillance au sein de l'hôte physique contenant votre VM. Ces événements peuvent entraîner une brève augmentation de la latence ou des délais avant expiration 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 Logging.
Choisissez la période à laquelle la latence s'est produite.
Utilisez la requête Logging suivante pour déterminer si un événement de VM s'est produit proche de la période pendant laquelle la latence est observée :
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 vérifier, procédez à la vérification des statistiques de réseau et de système d'exploitation 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 rejets 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 entraîne une latence ou des délais avant expiration de la connexion. Ces délais avant expiration peuvent ne pas être visibles au démarrage du client ou du serveur, mais ils peuvent apparaître au fil du temps 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 l'exécution 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. L'épuisement des paquets peut être dû à 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 expirer. Si conntrack a été activé, le nombre maximal de connexions est disponible avec la commande suivante :
sudo sysctl net.netfilter.nf_conntrack_maxVous 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 Performances > Outils de surveillance > Contrôle des 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 de traitement
- % de temps utilisateur
- Carte réseau
Pefmon vous permet de tracer 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 d'être traité par les sockets du client ou du 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. L'épuisement des paquets peut être dû à 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 rechercher des solutions possibles, ou demander de l'aide en suivant l'une des méthodes décrites dans la section Si les problèmes persistent.
Si l'épuisement des ressources ne semble pas être le problème, le problème peut être lié au logiciel serveur lui-même. Pour obtenir des conseils sur la résolution des problèmes lié à un logiciel serveur, consultez la page 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 avant expiration peuvent être causés par un comportement de l'application, tel que des blocages de traitement causés par l'épuisement du vCPU. Consultez les journaux du serveur et des applications 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, ce qui peut entraîner une utilisation accrue de la mémoire et des temps d'attente des CPU. 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élective des paquets, évitant ainsi les délais avant expiration 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 avant expiration, ce qui entraînant 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 la section Obtenir de l'aide pour les étapes suivantes. Il est utile que les résultats des étapes de dépannage ci-dessus soient disponibles pour le partage avec d'autres collaborateurs.
Étapes suivantes
- Si le problème persiste, consultez la page Ressources.