🔥 Mise en place d’une solution VPN pour intégration API

L’entreprise (mon client) m’a contacté afin de mettre en place une solution VPN pour pouvoir faire des requêtes API depuis ses locaux et machines de production sur un serveur nécessitant une connection VPN IKEv2/IPSec.

Il ‘s’agit d’une entreprise de gestion de patrimoine et placements financiers qui proposent des produits financiers a ces clients.

Ils viennent de signer un contrat de collaboration avec un grand groupe financier (le fournisseur d’API). L’entreprise propose dans son catalogue client les produits fournis par ce groupe financier.

A fin que le client finial puisse faire des simulations de prix en ligne ils doivent intégrer le catalogue du groupe financier dans leur site web a travers une API.

Le seul soucis est que cette API est accessible uniquement par VPN.

Or les développeurs travaillent depuis leurs postes et depuis des instances Heroku donc installer un VPN directement sur leur ordinateur n’était pas une solution.

Après réflexion et en tenant compte du besoin du client, j’ai décidé de créer une infrastructure sur aws qui puisse résoudre ce problème.

J’ai d’abord crée un environnement réseau avec une passerelle par default (IGW) et une passerelle VPN.

Dans cet environnement j’y ai placé une Instance EC2 Ubuntu server 22.04 afin qu’il agisse comme reverse proxy.

Puis j’ai fait pointer un nom de domaine propre a l’entreprise vers cette instance EC2

Donc a chaque fois que une requête API est réalisée avec notre nom de domaine, le proxy qui est connecté au VPN du groupe financier change l’URL afin que le nom de domaine de l’endpoint soit appelé avec le bon URL.

De cette façon mon client peut réaliser des requêtes API depuis n’importe quel poste ou instance cloud en utilisant uniquement son nom de domaine.

J’ai résolu ce problème en 3 étapes:

• Creation de l’infrastructure
• Paramétrage du VPN
• Création et paramétrage du reverse proxy

  

1) Creation de l’infrastructure sur AWS

Dans cette étape, Il s’agit de créer le “térreau” pour que l’ensemble des éléments puisse fonctionner correctement.

Changement de Zone

Nous allons commencer par changer de Zone. Personnellement, si j’ai le choix, je préfère bâtir des projets sur des zones aux USA (par exemple N. Virginia) au lieu de Europe car certains produits ne sont pas disponibles, comme des t2.micro.

Création du VPC

Je choisis un block en /24 qui sera largement suffisant pour 1 VM sur le projet !

Création du subnet

Dans ce block CIDR de /24 qui me donne une plage de 256 addresses IP, je le fragmente en un sous-domaine en /28 ce qui me donne une plage de 16 IP.

(Question: combien de sous-domaines en /28 je peux créer dans le block CIDR en /24 ? Réponse : Dans un block CIDR de /24 avec plage de 256 adresses IP je peux créer 16 sous-réseaux /28 comprenant 16 adresses IP chacun)

J’aurais souhaitée créer un sous-domaine en /30 pour me donner que 4 addresses IP mais aws n’accepte pas au delà de 28/

Création du IGW (Internet GateWay)

C’est la passerelle par défaut de notre ensemble.

on l’attache au bon VPC

Création des routes tables

Nous allons créer les règles de routage pour l’ensemble du VPC. De base nous avons la route qui permet d’acceder dans tout le block CIDR /24 10.0.0.0/24 —> local

Nous allons rajouter, dans un premier temps, la route pour accéder à l’extérieur du réseau (c’est à dire Internet). Pour toute les routes correspondant à la destination 0.0.0.0/0 qui représente la totalité du trafic internet sortant, ce trafic sera dirigé via la Internet Gateway.

Tunnel VPN IKEv2/IPSec

Dans cette étape je vais créer la partie qui me concerne pour l’tablissement du tunnel VPN IKEv2/IPSec. Voici le chahier des charges fourni pour la création du tunnel:

Création du Custommer Gateways

On renseigne l’IP publique de notre partenaire dans l’autre bout du tunnel

Création du VPG

Puis on nomme notre VPG (Virtual Private Gateway) et on l’attache à notre VPC

Création de la connection VPN

Static IP préfixes correspond aux plages IP qui pourront avoir accès a votre site à travers du tunnel. Dans notre cas 192.168.22.188/30 est le LAN de notre partenaire 10.0.0.0/28 est notre LAN

Au niveau des Tunnel Options, vous rentrerez la PSK (Pré Shared Key) qui permet l’authentification du Tunnel VPN

A la fin de ces étapes, aws, crée 2 tunnels VPN avec 2 IP différentes. Dans mon cas j’ai partagé uniquement la deuxième IP. Vous pouvez partager les 2 et avoir plus de redondance. Si un tunnel n’est plus actif le deuxième prends le relais.

Modifier la table de routage

Vous devez modifier la table de routage du VPC pour que les paquets a destination de 192.168.22.188/30 (réseau LAN de l’autre bout du tunnel) passent par la VPG (Virtual Private Gateway)

La règle sera la suivante: 192.168.22.188/30 —→ vgw-xxxxxxxx

Création du Reverse Proxy

Il ne nous reste que créer et paramétrer le reverse proxy qui sera responsable de modifier les domaines dans les requêtes API.

imaginons que le endpoint API officiel soit: api.company.com/edp/products nous ne pouvons acceder à cet endpoint que par VPN. Or si je suis a mon domicile il m’est impossible d’acceder a cet API. J’ai donc besoin d’un intermédiaire qui lui sera bien connecté au VPN et en même temps sera connecté a internet. Donc, ce reverse proxy, fera le pont, (le messager) entre le VPN en mon domicile grace a mon nom de domaine.

Création d’une VM Ubuntu

On va aller chercher dans le catalogue AMI un Ubuntu 22.04 ou 24.04 en 64-bit (x86)

Donnez lui un nom

Choissisez une intsance t2.micro

crééez une paire de clés (privé, publique). Si vous utilisez Putty comme client SSH utilisez .ppk si vous utilisez le CMD ou un terminal bash utilisez .pem

le fichier va télécharger sur votre ordinateur. gardez-le précizeusement car sans lui vous ne pourrez pas vous connecter a votre VM.

Au niveau des Network Settings: Choissez le bon VPC et subnet puis créez un nouveau groupe de sécurité avec seulement 2 règles.

SSH depuis votre IP publique pour administrer votre VM

et HTTPS anywhere pour laisser passer les packets de vos requettes API

Vous pouvez rajouter ICMP pour réaliser des pings si besoin et tester les tunnel VPN avec votre partennaire.

Puis lancez la création de l’instance:

on attribue une adresse IP externe fixe a notre VM avec Elastic IP

et associez cette IP a votre nouvelle instance (VM).

Paramétrer le notre nom de domaine:

Dans cette étape, nous devons faire pointer notre nom de sous-domaine vers l’IP publique de notre VM.

Pourcela il faut se rendre dans l’interface de votre bureau d’enregistrement de domaines (OVH, Route53, gandi,…) trouvez la zone DNS et créez une entrée de type A avec le sous doimaine de voter choix (ex: apitest.lousques.com) qui pointe vers l’IP de votre VM

Configurer la VM

Une fois ces étapes accomplies et la VM démarrée on va se connecter a celle-ci au travers d’un terminal avec la commande suivante:

ssh -i /chemin/vers/votre/cle.pem utilisateur@adresse-ip-ou-nom-de-domaine

exemple: ssh -i c:\Downloads\ubuntu-key.pem ubuntu@32.15.65.22

ubuntu est le nom utilisateur de votre VM

On va commencer par mettre a jour la VM avec cette commande:

sudo apt update

on installe nginx qui fera office de reverse proxy sudo apt install nginx

Nous allons immédiatement créer un backup du fichier default se trouvant dans /etc/nginx/sites-vailable/default avec cette commande **sudo cp default default.bak**

Installation de Certbot pour certificat SSL

sudo apt install python3-certbot-nginx

certbot --version

Obtenir et installer le Certificat SSL:

sudo certbot --nginx -d apitest.louisques.fr

Renseignez votre adresse email et répondez poar oui / non a certaines questions.

Modification du fichier de configuration Nginx

Nous allons maintenant transformer nginx en reverse proxy. Retournez sue le ficher default sur /etc/ngnix/sites-available/default et ouvrez le :

sudo nano default

remplacez apitest.louisques.fr par votre sous-domaine

server {
listen 80;
server_name apitest.louisques.fr;
return 301 https://$host$request_uri;
}

server {
listen 443 ssl;
server_name apitest.louisques.fr;

ssl_certificate /etc/letsencrypt/live/apitest.louisques.fr/fullchain.pem; # Managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/apitest.louisques.fr/privkey.pem; # Managed by Certbot

location / {
proxy_pass https://apitest.louisques.fr:
proxy_set_header Host apitest.louisques.fr;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;

}
}

enregistrez control^X YES et redémarrez le service nginx

sudo systemctl reload nginx

vérifie que les fichiers nginx sont lisibles et ne comportent pas d’erreur

sudo nginx -t

Si tout ok on passe à la dernière étape.

Modifier le fichier hosts

Modifier le fichier hosts de notre Ubuntu afin qui résolve la bonne adresse IP à partir de domaine fourni par le reverse proxy.

Toutes les étapes nécessaires a la réalisation de cette mission ont étés effectués. Normalement a ce stade, mon client peut réaliser des requêtes API de n’importe quel poste ou instance cloud en utilisant un sous-domaine personnalisé et recevoir la réponse.