web-dev-qa-db-fra.com

Dépannage de HTTPS sur AWS ALB: échec du contrôle de l'intégrité du groupe cible

Je rencontre des problèmes pour configurer HTTPS pour mon instance AWS EC2. En bref, j'exécute un programme sur une instance EC2, et il est essentiel que je puisse transférer les données en toute sécurité des clients vers AWS.

Ce que j'ai fait jusqu'à présent:

Sur AWS:

  • Lancement d'une instance EC2 (t2.micro, ubuntu). L'instance est bien vivante et accessible via SSH.
  • Création d'un certificat SSL public via Amazon's Certificate Manager, sous www.ourdomain.com
  • Création d'un équilibreur de charge d'application accessible sur Internet avec un écouteur HTTPS (sur le port 443), à l'aide du certificat précédent
  • Créé un groupe cible avec notre instance EC2 et l'ajouté à l'équilibreur de charge
  • Pour le groupe de sécurité de l'équilibreur de charge, activé HTTPS entrant depuis n'importe où et HTTP et HTTPS sortant vers le groupe de sécurité de l'instance EC2
  • Pour le groupe de sécurité d'instance, activé HTTPS entrant à partir du groupe de sécurité de l'équilibreur de charge

Sur GoDaddy:

  • Création d'un enregistrement CNAME (hôte: www.ourdomain.com, valeur: nom DNS de l'équilibreur de charge)

Problèmes:

  • Sous l'onglet "Cibles" pour mon groupe cible, je vois ce qui suit: "Aucune de ces zones de disponibilité ne contient une cible saine. Les demandes sont acheminées vers toutes les cibles"
  • En outre, sous l'onglet "Cibles" du groupe cible, le bouton info de l'instance indique: "Les contrôles d'intégrité ont échoué avec ces codes: [502]"
  • Si je vérifie le domaine sur ssllabs.com, j'obtiens "L'évaluation a échoué: impossible de se connecter au serveur"

Je veux éviter d'utiliser Route53 si possible, et malheureusement je ne trouve pas de documentation AWS pour ce problème qui n'implique pas Route53.

Je ne suis pas un expert en réseau ou AWS, il est donc tout à fait possible qu'il manque quelque chose de simple. Toutes les suggestions sont grandement appréciées!

amazon-web-servicesamazon-ec2httpsamazon-elb
2
pixel-drinker

En dehors de ce que @Jakub a mentionné, assurez-vous que vos API de contrôle de santé fonctionnent correctement. J'ai utilisé AWS Fargate et lorsque l'équilibreur de charge est créé, le contrôle d'intégrité aura par défaut '/' comme API de contrôle d'intégrité et lorsque vous créez un service ECS, il prend le nom du service '/ ecs-service'. Vous pouvez vérifier vos API de contrôle de santé configurées ici comme indiqué dans ce lien https://engineering.telia.no/blog/troubleshooting-fargate-health-check

Commande AWS CLI: aws elbv2 modify-target-group --target-group-arn ""\--health-check-timeout-seconds 30\--health-check-interval-seconds 200

Si vous utilisez ECS Fargate, assurez-vous que ces étapes sont en place: 1) si l'adresse IP du sous-réseau est accessible dans votre conteneur 2) Le port de votre conteneur Docker est-il correctement exposé? 3) Votre API de bilan de santé fonctionne-t-elle correctement?

1
Manideep Kethineedi

502 est une mauvaise passerelle, vous avez des problèmes de routage. Il s'agit très probablement de votre groupe de sécurité ou de votre table de routage.

Votre instance alb/elb et ec2 doit se trouver dans des sous-réseaux distincts dans le même VPC.

Votre elb doit accepter les connexions sur le port 80 et les rediriger vers le port 443, et votre instance EC2 doit accepter les connexions sur le port 80 du sous-réseau où réside l'elb.

Créez un groupe cible qui pointe vers le sous-réseau où l'instance EC2 réside sur le port 80, mais vous devez vous assurer que votre instance écoute réellement sur ce port.

Créez ensuite un ELB qui utilise ce groupe cible.

Pour votre règle d'écoute du port 80, assurez-vous qu'elle redirige vers https://www.ourdomain.com:443/ ? , code d'état http_301.

Pour votre règle d'écoute du port 443, transférez-la à votre groupe cible.

0
Chupacabra

Chupacabra a de bonnes suggestions, n’ont-elles pas aidé? Moi aussi, j'ai perdu trop de temps à ce sujet et résume mes conseils ici: AWS Fargate: Dépannage du redouté 'service .. est malsain'

meilleures astuces:

  1. Les demandes de/retour 200 OK?
  2. Reviennent-ils assez rapidement?
  3. Le service commence-t-il à répondre assez rapidement après un démarrage?
  4. L'auditeur essaie-t-il de contacter le service sur un port où il s'exécute réellement, en utilisant le bon protocole? Le groupe de sécurité du service permet-il au groupe de sécurité de l'équilibreur de charge d'accéder au port?

Voir le blog pour plus de détails et d'autres conseils.

0
Jakub Holý