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 résolution des problèmes veuillez cliquer sur le lien Envoyer des commentaires en bas de la page et 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 permettant de résoudre les problèmes de connectivité interne complète entre les 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. Consultez le 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é.

Accéder à 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 :
1. Protocole
2. Adresse IP du point de terminaison source
3. Projet source et réseau VPC
4. Adresse IP du point de terminaison de destination
5. Projet de destination et réseau VPC
6. Port de destination
Cliquez sur Create (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éder à la page Règles de pare-feu et examiner 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.

Accéder à la page "Stratégies de pare-feu"
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.

Accéder à 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.

Accéder à 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)`
```

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 ) au port443, acceptant les connexions à partir de n'importe quelle adresse source (0.0.0.0 ) et 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 ci-dessus 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 section 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 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 ci-dessus ne permettent pas de résoudre un problème, l'application peut être à l'origine des délais avant expiration. 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

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 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 à votre VM au moment opportun.

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.

Accéder à Stackdriver 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 à proximité 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 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 netstat pour afficher les statistiques du réseau.
```
$ netstat -s
```
```
TcpExt:
  341976 packets pruned from receive queue because of socket buffer overrun
  6 ICMP packets dropped because they were out-of-window
  45675 TCP sockets finished time wait in fast timer
  3380 packets rejected in established connections because of timestamp
  50065 delayed acks sent
```
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_max

Vous pouvez augmenter la valeur du nombre maximal de connexions suivies en modifiant le fichier sysctl net.netfilter.nf_conntrack_max ou 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
  - Indications de ressources reçues faibles par seconde
  - Paquets de ressources reçues faibles par seconde
- Processeur
  - % de temps d'interruption
  - % de temps privilégié
  - % de temps de traitement
  - % de temps utilisateur

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 :

Étapes suivantes

Si le problème persiste, consultez la page Ressources.