View a markdown version of this page

Résolution des problèmes de réseau VPC - AWS HealthOmics
Surveillance du réseau et résolution des problèmesRésolution des problèmes de configuration

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Résolution des problèmes de réseau VPC

Surveillance du réseau et résolution des problèmes

CloudTrail journalisation

Toutes les opérations de l'API de configuration et les exécutions de flux de travail utilisant le réseau VPC sont connectées. CloudTrail CloudTrail À utiliser pour auditer les modifications de configuration et suivre les exécutions utilisant le réseau VPC.

Résolution des problèmes avec les journaux de flux ENI

Lorsque votre flux de travail exécute l'accès à des ressources externes via Internet, vous pouvez utiliser les journaux de flux VPC pour vérifier la connectivité et diagnostiquer les problèmes. HealthOmics fournit des interfaces réseau élastiques (ENIs) dans vos sous-réseaux VPC pour acheminer le trafic provenant de vos tâches de flux de travail. En examinant les journaux de flux correspondants ENIs, vous pouvez suivre le trafic réseau à destination et en provenance de destinations externes.

Gestion des coûts pour les journaux de flux VPC

Les journaux de flux VPC peuvent entraîner des coûts importants, en particulier au niveau du VPC. Pour minimiser les coûts :

  • Supprimez les journaux de flux après le dépannage. Une fois les problèmes de connectivité résolus, supprimez le journal des flux pour ne plus encourir de frais.

  • Utilisez Amazon S3 au lieu de CloudWatch Logs pour le stockage à long terme. Le stockage Amazon S3 est nettement moins cher que celui CloudWatch des journaux. Configurez les journaux de flux à publier sur Amazon S3 si vous devez conserver des journaux à des fins d'analyse de conformité ou de sécurité.

  • Définissez CloudWatch des politiques de conservation des journaux. Si vous utilisez CloudWatch des journaux, configurez l'expiration automatique des journaux (par exemple, 7 jours) pour éviter des coûts de stockage indéfinis.

  • Utilisez les journaux de flux au niveau ENI pour le dépannage. Pour un débogage ponctuel, créez des journaux de flux sur l'ENI spécifique du client plutôt que sur l'ensemble du VPC.

Configuration des journaux de flux pour le dépannage

Option 1 : journaux de flux au niveau du VPC (pour une surveillance continue)

Activez les journaux de flux sur votre VPC pour capturer automatiquement le trafic provenant de toutes les exécutions de HealthOmics flux de travail. C'est la meilleure solution lorsque vous devez exécuter de nombreux flux de travail et que vous souhaitez bénéficier d'une visibilité complète sans effectuer de suivi individuel ENIs.

  1. Activez les journaux de flux VPC. Dans la console Amazon VPC :

    1. Choisissez votre VPCs et sélectionnez le VPC utilisé dans votre configuration HealthOmics

    2. Choisissez l'onglet Flow logs

    3. Choisissez Créer un journal de flux

    4. Configurer le journal de flux pour capturer tout le trafic (accepté et rejeté)

    5. Sélectionnez CloudWatch Logs comme destination pour faciliter les requêtes

  2. Lancez une exécution de flux de travail. Démarrez un flux de travail avec le réseau VPC activé. Notez l'ID d'exécution et l'heure de début du filtrage des journaux de flux ultérieurement.

Interrogez les journaux de flux à l'aide de CloudWatch Logs Insights par fenêtre temporelle, IP de destination ou modèles de trafic. Vous n'avez pas besoin d'identifier une ENI spécifique IDs.

Option 2 : journaux de flux au niveau ENI (pour un dépannage ciblé)

Activez les journaux de flux sur des ENIs sujets spécifiques lorsque vous n' HealthOmics ENIs en avez que quelques-uns sur votre compte. Il s'agit de l'approche la plus rentable et permet d'isoler facilement le trafic pour des exécutions de flux de travail spécifiques.

  1. Trouvez le client ENI. Dans la console Amazon EC2 :

    1. Choisissez les interfaces réseau

    2. Filtrer par tag Service: HealthOmics pour n'afficher que les ENIs créations créées par HealthOmics

    3. Facultativement, filtrez davantage en fonction de l'ID de sous-réseau de votre configuration HealthOmics

    4. Notez l'ID ENI et l'adresse IP privée

  2. Activez les journaux de flux sur l'ENI.

    1. Sélectionnez l'ENI et choisissez l'onglet Flow logs

    2. Choisissez Créer un journal de flux

    3. Configurer le journal de flux pour capturer tout le trafic

    4. Sélectionnez CloudWatch Logs comme destination

Note

Les journaux de flux ne capturent le trafic qu'à partir du moment où ils sont activés. Pour les journaux de flux au niveau VPC, activez-les avant d'exécuter les flux de travail. Pour les journaux de flux de niveau ENI, une fois activés sur un ENI, le même journal de flux capturera le trafic pour tous les futurs cycles de flux de travail utilisant cet ENI.

Comprendre le format du journal de flux VPC

Les journaux de flux VPC utilisent un format séparé par des espaces avec les champs suivants :

version account_id interface_id srcaddr dstaddr srcport dstport protocol packets bytes start end action log_status

Descriptions des champs :

  • version — Version du format du journal de flux (généralement 2)

  • account_id — Votre AWS identifiant de compte

  • interface_id — L'ID ENI (par exemple, eni-0e57c5476efeac402)

  • srcaddr — Adresse IP source

  • dstaddr — Adresse IP de destination

  • srcport — Numéro de port source

  • dstport — Numéro de port de destination

  • protocole — numéro de protocole IANA (6 = TCP, 17 = UDP, 1 = ICMP)

  • paquets — Nombre de paquets dans le flux

  • octets — Nombre d'octets dans le flux

  • start — Heure de début du flux (horodatage Unix)

  • fin — Heure de fin du flux (horodatage Unix)

  • action — ACCEPTER ou REJETER

  • log_status — OK, NODATA ou SKIPDATA

Exemples d'entrées du journal de flux :

2 074296239033 eni-0e57c5476efeac402 10.0.130.58 13.226.238.96 40565 443 6 13 1502 1774338927 1774338929 ACCEPT OK
2 074296239033 eni-0e57c5476efeac402 13.226.238.96 10.0.130.58 443 40565 6 8 1024 1774338928 1774338930 ACCEPT OK

Ces entrées indiquent une communication HTTPS bidirectionnelle réussie. Clé IPs : 10.0.130.58 est l'ENI du client créé par HealthOmics votre compte, et 13.226.238.96 est le domaine public externe auquel votre flux de travail accède. La première entrée est le trafic sortant et la seconde est le trafic retour. Les deux affichent ACCEPT, ce qui indique que le trafic a été autorisé par les groupes de sécurité.

Interrogation des journaux de flux dans CloudWatch Logs Insights

Lorsque les journaux de flux sont publiés dans CloudWatch Logs, utilisez CloudWatch Logs Insights pour interroger et analyser les données.

Trouvez le trafic refusé (commencez ici)

fields @timestamp, interfaceId, srcAddr, dstAddr, srcPort, dstPort, protocol, action
| filter action = "REJECT"
| sort @timestamp desc

Si cela donne des résultats, il se peut que vous rencontriez un problème de connectivité. Les entrées rejetées indiquent quel trafic est bloqué par les groupes de sécurité ou le réseau ACLs.

Rechercher du trafic vers une adresse IP externe spécifique

Tout d'abord, remplacez le domaine par une adresse IP en utilisant nslookup ou dig :

$ nslookup ftp.ncbi.nlm.nih.gov
Server:  127.53.53.53
Address: 127.53.53.53#53

Non-authoritative answer:
ftp.ncbi.nlm.nih.gov    canonical name = ftp.wip.ncbi.nlm.nih.gov.
Name:    ftp.wip.ncbi.nlm.nih.gov
Address: 130.14.250.10
Name:    ftp.wip.ncbi.nlm.nih.gov
Address: 130.14.250.11

Les champs « Serveur » et « Adresse » situés en haut sont votre résolveur DNS. Les adresses figurant sous « Réponse non officielle » (130.14.250.10 et 130.14.250.11) sont les adresses réelles du domaine. IPs

Interrogez les journaux de flux à l'aide d'un préfixe correspondant à n'importe quelle adresse IP comprise dans cette plage :

fields @timestamp, interfaceId, srcAddr, dstAddr, srcPort, dstPort, protocol, action
| filter dstAddr like "130.14.250"
| sort @timestamp desc

Cela correspond à n'importe quelle adresse IP commençant par 130.14.250, capturant le trafic vers tous les IPs membres de ce sous-réseau.

Trouvez le trafic HTTPS vers des destinations externes

fields @timestamp, interfaceId, srcAddr, dstAddr, srcPort, dstPort, protocol, action
| filter dstPort = 443 and protocol = 6
| filter not (dstAddr like /^10\./ or dstAddr like /^172\./ or dstAddr like /^192\.168\./)
| sort @timestamp desc

Le second filtre exclut les plages d'adresses IP privées, affichant uniquement le trafic vers des destinations externes (publiques).

Note

Numéros de protocole : 6 = TCP, 17 = UDP, 1 = ICMP. Pour les services à répartition de charge (par exemple, CloudFront), le DNS peut renvoyer des informations différentes IPs. Filtrez donc par port de destination plutôt que par adresse IP.

Modèles et problèmes courants liés aux journaux de flux

Trafic sortant rejeté
Outbound: 2 074296239033 eni-0e57c5476efeac402 10.0.130.58 13.226.238.96 40565 443 6 1 60 1774338927 1774338929 REJECT OK

Cause : le groupe de sécurité n'autorise pas le trafic sortant vers le port de destination ou la plage d'adresses IP.

Solution : ajoutez une règle de trafic sortant à votre groupe de sécurité :

  • Pour HTTPS : autoriser le port TCP 443 à 0.0.0.0/0

  • Pour HTTP : autoriser le port TCP 80 à 0.0.0.0/0

  • Pour un accès plus large : Autoriser tout TCP/UDP à 0.0.0.0/0

Trafic de retour refusé
Outbound: 2 074296239033 eni-0e57c5476efeac402 10.0.130.58 8.8.8.8 54321 53 17 1 64 1774338927 1774338929 ACCEPT OK
Return:   2 074296239033 eni-0e57c5476efeac402 8.8.8.8 10.0.130.58 53 54321 17 1 64 1774338928 1774338930 REJECT OK

Cause : L'ACL réseau bloque le trafic de retour. Contrairement aux groupes de sécurité (stateful), ACLs les réseaux sont apatrides et nécessitent des règles explicites dans les deux directions.

Solution : Dans la console VPC, vérifiez l'ACL réseau de votre sous-réseau et vérifiez que les règles entrantes autorisent le trafic sur les ports éphémères (1024-65535) en provenance de sources externes. Ajoutez une règle si nécessaire : Autoriser les TCP/UDP ports 1024 à 65535 à partir de 0.0.0.0/0

Trafic aller-retour manquant
Outbound: 2 074296239033 eni-0e57c5476efeac402 10.0.130.58 8.8.8.8 54321 53 17 1 64 1774338927 1774338929 ACCEPT OK

Cause : La Gateway/Internet passerelle NAT n'est pas configurée correctement ou ENI n'est pas connectée à Internet.

Solution :

  • Vérifiez que la table de routage possède une route vers la passerelle NAT (0.0.0.0/0 → nat-xxxxx)

  • Vérifiez que la passerelle NAT est à l'état DISPONIBLE avec une adresse IP élastique

  • Vérifiez que la passerelle NAT se trouve dans un sous-réseau public avec une route vers Internet Gateway

Aucune entrée dans le journal des flux pour le trafic attendu

Cause : le trafic n'atteint pas l'ENI ou les journaux de flux ne sont pas configurés correctement.

Solution :

  • Vérifiez que les journaux de flux sont activés et configurés pour capturer tout le trafic

  • Vérifiez les journaux du flux de travail dans les CloudWatch journaux pour confirmer que le flux de travail tente d'accéder à la ressource externe

  • Vérifiez que la table de routage possède une route vers la passerelle NAT (0.0.0.0/0 → nat-xxxxx)

  • Vérifiez que la passerelle NAT est à l'état DISPONIBLE avec une adresse IP élastique

Meilleures pratiques en matière de résolution des problèmes liés aux journaux de flux

  1. Activez les journaux de flux avant de commencer le dépannage. Les journaux de flux ne capturent le trafic qu'à partir du moment où ils sont activés. Activez-les sur tous les sous-réseaux de votre HealthOmics configuration avant d'exécuter des flux de travail.

  2. Utilisez CloudWatch Logs Insights à des fins d'analyse. CloudWatch Logs Insights fournit de puissantes fonctionnalités d'interrogation pour les journaux de flux. Enregistrez les requêtes fréquemment utilisées pour y accéder rapidement.

  3. Filtrez par fenêtre horaire. Limitez les requêtes du journal de flux à la fenêtre temporelle spécifique pendant laquelle l'exécution de votre flux de travail était active afin de réduire le bruit et d'améliorer les performances des requêtes.

  4. Recherchez les deux sens de circulation. Vérifiez toujours que le trafic sortant et le trafic retour portent la mention ACCEPT. Une connexion nécessite une communication bidirectionnelle.

  5. Documentez vos conclusions. Lorsque vous résolvez des problèmes de connectivité, documentez l'ID ENI, les adresses IP, les ports et les entrées du journal de flux du client. Ces informations sont précieuses pour les demandes d'assistance et les futurs dépannages.

  6. Testez d'abord avec un flux de travail simple. Avant d'exécuter des flux de travail complexes, testez la connectivité à l'aide d'un flux de travail simple qui tente d'accéder à la ressource externe et enregistre le résultat. Cela permet d'isoler les problèmes de réseau des problèmes de logique du flux de travail.

Résolution des problèmes de configuration

Configuration bloquée dans le statut CREATING

Cause : le provisionnement des ressources réseau peut prendre plusieurs minutes.

Solution : attendez jusqu'à 10 minutes. Si le statut ne passe pas à ACTIF, vérifiez les points suivants :

  • Vos sous-réseaux et groupes de sécurité existent et se trouvent dans le même VPC.

  • Vous disposez des autorisations IAM requises.

  • Le rôle lié au service a été créé avec succès.

L'exécution ne démarre pas avec le réseau VPC

Cause : Il se peut que la configuration ne soit pas ACTIVE ou qu'il y ait des problèmes de connectivité réseau.

Solution :

  • Vérifiez que l'état de configuration est ACTIF en utilisantGetConfiguration.

  • Vérifiez que les règles du groupe de sécurité autorisent le trafic sortant requis.

  • Assurez-vous que les sous-réseaux se trouvent dans les zones de disponibilité où HealthOmics opère l'entreprise.

Impossible de supprimer la configuration

Cause : La configuration est utilisée par les exécutions de flux de travail actives.

Solution : attendez que toutes les exécutions utilisant la configuration soient terminées, puis recommencez la suppression.

Impossible de supprimer le rôle lié à un service

Cause : des configurations VPC actives existent dans votre compte.

Solution : supprimez d'abord toutes les configurations VPC, puis supprimez le rôle lié au service.

Le flux de travail ne peut pas se connecter à une ressource externe

Cause : mauvaise configuration du groupe de sécurité ou de la table de routage.

Solution :

  1. Activer les journaux de flux VPC pour identifier les paquets rejetés

  2. Vérifiez que les règles sortantes du groupe de sécurité autorisent le trafic vers la destination

  3. Vérifiez que la table de routage possède une route vers la passerelle NAT (0.0.0.0/0 → nat-xxxxxx)

  4. Pour l'accès aux AWS services interrégionaux, assurez-vous que la région de destination est accessible

  5. Tester la connectivité depuis une instance Amazon EC2 dans le même sous-réseau

Problèmes de performance du réseau

Symptôme : transfert de données lent ou délais d'expiration du flux de travail.

Cause : limitation du débit du réseau ou saturation de la passerelle NAT.

Solution :

  • Le débit du réseau commence à 10 Gbit/s par ENI et augmente jusqu'à 100 Gbit/s sur une période de 60 minutes avec un trafic soutenu

  • Pour les flux de travail nécessitant un débit élevé immédiat, veuillez contacter le Support AWS

  • Surveillez les métriques de la passerelle NAT CloudWatch pour identifier la saturation

  • Envisagez de déployer des passerelles NAT supplémentaires dans plusieurs zones de disponibilité pour un débit plus élevé

Le flux de travail ne peut pas accéder à Internet

Cause : Les sous-réseaux privés n'ont peut-être pas de route vers une passerelle NAT, ou les règles du groupe de sécurité bloquent peut-être le trafic sortant.

Solution :

  • Vérifiez que la table de routage de vos sous-réseaux privés inclut une route vers une passerelle NAT (0.0.0.0/0 → nat-xxxxxxxxx).

  • Vérifiez que les règles du groupe de sécurité autorisent le trafic sortant sur les ports requis.

  • Vérifiez que la passerelle NAT se trouve dans un sous-réseau public avec une route vers une passerelle Internet.

L'exécution du flux de travail échoue en raison d'erreurs de connectivité

Cause : le trafic réseau est peut-être bloqué ou mal configuré.

Solution :

  1. Vérifiez que la configuration est toujours active en utilisantGetConfiguration.

  2. Créez un journal des flux VPC ENIs dans votre VPC pour inspecter le trafic. Pour plus d’informations, consultez Journaux de flux VPC dans le Guide de l’utilisateur Amazon VPC.

  3. Consultez le journal des flux pour détecter les entrées REJECT. Si des paquets sont rejetés, mettez à jour les règles de votre groupe de sécurité pour autoriser le trafic sortant requis.

  4. Si le journal de flux ne révèle pas la cause première, contactez le AWS Support.