Ec2, Node.js: Appel API situé sur le même serveur

Bonjour,

j’ai une API express installé sur un serveur EC2. Pour certaines routes, il me faut appeler cette API depuis le serveur lui-même mais lorsque je le fait j’ai toujours une erreur :

getaddrinfo ENOTFOUND

J’ai vérifié un nombre de fois incalculable et l’adresse appelée est correcte.

Voici un example de code ou je fait ça (httpUtil est basé sur axios):

try {
  const httpUtil = require('../utils/http.util')();
  const apiStatus = await httpUtil.get(`${process.env.URL}api/status`);

  console.log(apiStatus.data);
} catch (e) {
  if (e.response) {
    console.log(e.response.data);
  } else {
    console.log(e);
  }
}

En faisant mes recherches j’ai lu que je devais ajouter des règles inbound et outbound dans le security group de mon serveur EC2. J’ai ajouté des règles contenant l’IP du serveur mais sans succès.

Est-ce que quelqu’un a déjà eu affaire à une situation similaire ?

Tu as mis quoi comme règles dans ton security group exactement ?

Pourquoi ne pas utiliser localhost sinon pour taper directement sur l’instance locale ?

Tu as mis quoi comme règles dans ton security group exactement ?

J’ai autorisé l’IP du serveur EC2.

J’ai besoin de vérifier que la requête est bien appelée depuis le même serveur et pour cela je vérifie le header 'x-forwarded-for’. Le problème c’est que lorsque j’utilise localhost ce header n’existe pas.

Et process.env.URL contient quoi ? L’IP du serveur ? Ou l’URL d’un load-balancer ?

C’est l’adresse de l’API. Ex: https://api.exemple.com/v1

Tu as un load-balancer devant ou c’est juste un champ A dans tes DNS qui pointe vers ton instance EC2 ?

Tes règles de security group ressemblent à quoi exactement pour tout ça ?

Tes instances sont dans un sous-réseaux public ou privé ?

Oui, j’ai un load balancer et donc j’ai un enregistrement A qui pointe vers ce load balancer.

L’instance est dans un subnet public et les règles du security group ressemblent à ça :

En rouge c’est l’adresse IP de l’instance EC2.

Alors si tu autorises déjà 0.0.0.0/0 en entrée, pas besoin de préciser l’adresse de l’instance vu que tu autorises toute les IP en entrée.

Ça c’est les règles du security-group de ton instance, et ton load-balancer il a quoi comme SG ?

Pour info il vaut mieux avoir un SG pour ton LB qui autorise 80+443 de partout et un SG pour ton instance qui n’autorise que son port HTTP (qui peut être custom si besoin) en entrée depuis le SG du load-balancer.

Ok. J’ai supprimé l’adresse de l’instance. C’est le même security group pour le load balancer et l’instance mais ça ne fonctionne pas

ufw est également installé et activé sur le serveur avec les port 80 et 443 ouverts.

Status: active

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere                  
80/tcp                     ALLOW       Anywhere                  
443/tcp                    ALLOW       Anywhere                  
22/tcp (v6)                ALLOW       Anywhere (v6)             
80/tcp (v6)                ALLOW       Anywhere (v6)             
443/tcp (v6)               ALLOW       Anywhere (v6)             

Si tu autorises tout en sortie et tout en entrée j’ai du mal à voir ce qui pourrait bloquer, là je t’avoue

Ton LB redirige bien vers le port exposé de ton app ?

Si tu te connectes en SSH sur l’instance tu peux faire un curl à la main pour voir ?

Si je fait un curl ça fonctione si j’utilise l’IP, mais ça fonctionne pas si j’utilise l’URL:

curl 1.1.1.1/v1/api/status // OK

curl https://api.exemple.com/v1/api/status // Pas OK

Et depuis ton ordi tu peux taper sur l’URL sans problème ?

Si non ton LB n’est probablement pas bien configuré pour rediriger le trafic.

Oui, ça fonctionne depuis mon ordi. Qu’est-ce qu’il faudrait faire pour configurer le LB ?

Si ça fonctionne depuis ton ordi ça ressemble à un problème de config réseau…

Tu aurais pas un firewall sur ton instance qui bloquerait le trafic sortant ?

Bizarement ça marche lorsque je teste une autre API externe :

curl https://jsonplaceholder.typicode.com/todos/1

Mais ça ne fonctionne pas si l’API est sur le même serveur.

Alors là je commence à sécher…

Peut-être un problème de DNS ?

Tu peux faire un dig <tondomaine> sur ton EC2 voir si ça résout bien ?

Pas de ;; ANSWER SECTION: donc. On dirait que ton instance n’a pas les bons DNS…

J’ai essayé de faire quelques modifications au DNS en modifiant le fichier /etc/resolv.conf manuellement seulement il est remis à défaut automatiquement.

Après ça j’ai suivi la solution sur cette page pour Ubuntu et crée le fichier /etc/netplan/99-custom-dns.yaml avec le contenu suivant :

network:
    version: 2
    ethernets:
        eth0:         
            nameservers:
                    addresses: [W.V.X.Y]
            dhcp4-overrides:
                    use-dns: false

Dans addresses, j’ai mis l’adresse de IP de l’instance, puis re-démarré mais sans succès.

Dans ton VPC et ton subnet, ta configuration ressemble à quoi ? Tes instances utilisent quel DNS ?

Configuration du VPC :

Configuration du subnet :

Je suis pas sûr de ce que tu veux dire ici car quand je regarde la configuration de l’instance j’ai une adresse DNS IPV4 Publique et une adresse DNS IPV4 Privée.