From d99792c5c8205e2e362565c7c94c77ef0f458881 Mon Sep 17 00:00:00 2001
From: Matisse DEKEISER <matisse.dekeiser.etu@univ-lille.fr>
Date: Fri, 17 Jan 2025 00:49:20 +0100
Subject: [PATCH] =?UTF-8?q?Modifications=20et=20ajouts=20reverse=20proxy,?=
=?UTF-8?q?=20corrections,=20partie=205=20=C3=A0=20finir?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
---
README.md | 9 +-
.../4-element-proxy/install-element-web.md | 8 +-
.../4-element-proxy/install-reverse-proxy.md | 120 ++++++++++++++----
procedures/5-final-architecture/README.md | 10 +-
.../5-final-architecture/current-issue.md | 2 +-
.../final-architecture.md | 2 +-
6 files changed, 113 insertions(+), 38 deletions(-)
diff --git a/README.md b/README.md
index ad94ac1..15e12fc 100644
--- a/README.md
+++ b/README.md
@@ -46,4 +46,11 @@ Afin de procéder à une installation correcte de Synapse, l'ensemble des procé
### [Sommaire](./procedures/4-element-proxy/README.md)
- [4.1: Installation de Element Web](./procedures/4-element-proxy/install-element-web.md)
-- [4.2: Installation d'un reverse proxy](./procedures/4-element-proxy/install-reverse-proxy.md)
\ No newline at end of file
+- [4.2: Installation d'un reverse proxy](./procedures/4-element-proxy/install-reverse-proxy.md)
+
+# 🏗️ PARTIE 5: Migration et configuration de l'architecture finale
+
+### [Sommaire](./procedures/5-final-architecture/README.md)
+
+- [5.1: Problème de notre architecture actuelle et explication de l'architecture finale](/procedures/5-final-architecture/current-issue.md)
+- [5.2: Configuration de l'architecture finale](/procedures/5-final-architecture/final-architecture.md)
\ No newline at end of file
diff --git a/procedures/4-element-proxy/install-element-web.md b/procedures/4-element-proxy/install-element-web.md
index b0e8242..09d0b58 100644
--- a/procedures/4-element-proxy/install-element-web.md
+++ b/procedures/4-element-proxy/install-element-web.md
@@ -58,7 +58,7 @@ Pour cela, rendez vous dans `/etc/element-web` puis modifiez le fichier `config.
Ensuite, dans `/etc/nginx/sites-available`, créez le fichier `element` avec le contenu suivant:
-```
+```nginx
server {
listen 8080;
server_name matrix;
@@ -83,9 +83,11 @@ server {
Vous devez maintenant lier le site au dossier `sites-enabled` de nginx, en créant un lien symbolique de votre configuration nginx pour Element vers `sites-enabled`:
-`sudo ln -s /etc/nginx/sites-available/element-web /etc/nginx/sites-enabled/`
+```bash
+user@matrix $ sudo ln -s /etc/nginx/sites-available/element-web /etc/nginx/sites-enabled/
+```
-Vérifiez la configuration de nginx:
+Vérifiez la configuration de nginx au cas où il y aurait des erreurs:
```bash
user@matrix $ sudo nginx -t
diff --git a/procedures/4-element-proxy/install-reverse-proxy.md b/procedures/4-element-proxy/install-reverse-proxy.md
index 5886cd5..8677734 100644
--- a/procedures/4-element-proxy/install-reverse-proxy.md
+++ b/procedures/4-element-proxy/install-reverse-proxy.md
@@ -1,48 +1,114 @@
# 4.2: Installation d'un reverse proxy
+## ❓ Choix du reverse proxy
-## Choix du reverse proxy
+| Critère | **nginx** | **Traefik** | **HAProxy** |
+|----------------------------------------|-----------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------|
+| **Performance (requêtes simultanées)** | Performance élevée pour une faible latence. | Bonne performance, moins optimal pour des charges lourdes. | Très haute performance, conçu pour des charges massives (exemple: entreprises). |
+| **Gestion du chiffrement TLS/SSL** | Configuration manuelle via OpenSSL. | Gestion automatique du chiffrement TLS/SSL via Let's Encrypt. | Configuration manuelle via OpenSSL. |
+| **Load balancing** | Algorithmes classiques (round-robin, least connections, sticky sessions...). | Algorithmes classiques (round-robin, random, least request...) | Algorithmes classiques et avancés (round-robin, HDR, static-RR, RDP...) |
+| **Facilité de configuration** | Configuration simple, peut devenir complexe dans le cas d'infrastructures plus avancées. | Configuration facile pour les environnements conteneurisés (Docker, Kubernetes) à l'aide de l'intégration automatique (Terraform, Ansible...).. | Configuration puissante mais complexe. |
+| **Support des contenus statiques** | Conçu pour la gestion et le service de contenus statiques. | Support limité des contenus statiques. | Aucun support direct des contenus statiques. |
+| **Haute disponibilité** | Support de la haute disponibilité à l'aide d'outils externes (Keepalived, Pacemaker...) | Options disponibles dans sa configuration pour Docker/Kubernetes. | Conçu pour la haute disponibilité à l'aide d'outils avancés (Keepalived, VRRP...). |
+| **Flexibilité et fonctionnalités** | Serveur web intégré, modules externes... | Adapté pour les microservices conteneurisés (Docker, Kubernetes...). | Extrêmement configurable, adapté pour les scénarios/infrastructures avancées. |
+| **Sécurité** | SSL/TLS, contrôle d'accès IP (white/blacklisting), WAF (Web Application Firewall), rate limiting... | SSL/TLS, gestion dynamique des certificats de chiffrement, contrôle d'accès IP, WAF, isolation des services... | SSL/TLS, mitigation DDoS, contrôle d'accès IP, WAF, validation et filtrage des requêtes... |
+| **Support des protocoles** | HTTP(S), HTTP/2, WebSocket... | HTTP(S), HTTP/2, WebSocket, TCP... | HTTP(S), HTTP/2, TCP, UDP... |
+Dans le cadre de ce projet, nous utiliserons `nginx`, pour les raisons suivantes:
+- Nous n'avons pas besoin de solutions aussi avancées que HAProxy.
+- Nous n'utilisons pas de technologies de conteneurisation telles que Docker ou Kubernetes.
+- Étant donné que nous utilisons déjà `nginx` comme serveur web, nous serons plus à l'aise avec sa configuration comparé à d'autres outils de reverse proxying.
-| Critère | **Nginx** | **Apache HTTP Server avec mod_proxy** | **HAProxy** |
-|----------------------------------|------------------------------------------|---------------------------------------------------|---------------------------------------|
-| **Performance (requêtes simultanées)** | Très élevé, optimisé pour gérer un grand nombre de connexions simultanées | Moins performant que Nginx pour les requêtes simultanées, surtout pour les fichiers statiques | Exceptionnel, conçu pour gérer des milliers de connexions simultanées |
-| **Gestion du chiffrement TLS/SSL** | Excellente gestion du TLS/SSL avec faible surcharge | Bonne gestion du TLS/SSL avec `mod_ssl` | Gestion centralisée du TLS/SSL avec faible surcharge |
-| **Load balancing** | Supporte le load balancing basique (round-robin, least connections, etc.) | Supporte le load balancing via `mod_proxy_balancer` mais moins flexible | Très avancé, options de load balancing et health checks sophistiquées |
-| **Facilité de configuration** | Simple à configurer pour des cas classiques | Configuration flexible mais complexe pour des cas avancés | Configuration complexe, mais idéale pour les environnements de haute disponibilité |
-| **Support des contenus statiques** | Excellente gestion des fichiers statiques (HTML, CSS, JS) | Moins performant pour les contenus statiques comparé à Nginx | Pas conçu pour servir des contenus statiques |
-| **Haute disponibilité (HA)** | Bonne prise en charge de la haute disponibilité, notamment en combinaison avec un load balancer externe | Peut être configuré pour la haute disponibilité, mais moins performant que Nginx ou HAProxy | Excellente prise en charge de la haute disponibilité avec gestion des pannes |
-| **Flexibilité et fonctionnalités** | Moins flexible que Apache pour les configurations avancées | Très flexible grâce aux nombreux modules, mais plus complexe | Flexible pour le load balancing et la gestion de la haute disponibilité, mais limité pour les autres configurations |
-| **Sécurité** | Très sécurisé, notamment pour masquer les serveurs internes et gérer le chiffrement | Sécurisé, mais nécessite plus de configuration pour certains aspects de sécurité | Excellente sécurité grâce au contrôle de l'accès et aux possibilités de filtrage |
-| **Support des protocoles** | Principalement HTTP/HTTPS, mais supporte également WebSocket | HTTP, HTTPS, FTP, AJP, et autres via des modules | Principalement HTTP/HTTPS, avec un focus sur le load balancing |
-| **Utilisation typique** | Serveur web performant + reverse proxy pour applications web classiques | Serveur web traditionnel avec capacité de reverse proxy pour des configurations complexes | Reverse proxy et load balancer dans des environnements à fort trafic ou haute disponibilité |
+## 1. Déployer une nouvelle machine virtuelle
+Avant tout, nous devons déployer une toute nouvelle machine virtuelle, dédiée uniquement pour le reverse proxy.
-Ici nous allons donc utiliser `nginx` (???????)
+Nous la nommerons `rproxy`, et elle aura pour adresse IP `10.42.x.2`.
-## Etape 1 : Reinstaller une machine virtuelle
+Pour cela, veuillez suivre les procédures de création et de configuration de machines virtuelles vues précédemment:
+- [1.3: Création et gestion de la machine virtuelle](../1-virtual-machine/create-virtual-machine.md)
+- [1.5: Configuration réseau et mise à jour](../1-virtual-machine/setup-virtual-network.md)
+- [2.1: Modifier le nom d'hôte de la machine virtuelle](../2-configuration-services/change-hostname.md)
-Avant tout, nous devons reinstaller une nouvelle machine virtuelle que nous nommerons `proxy` est qui aura pour adresse ip `10.42.x.2`. Pour cela, consultez [1.3: Création et gestion de la machine virtuelle](../1-virtual-machine/create-virtual-machine.md) et [1.5: Configuration réseau et mise à jour](../1-virtual-machine/setup-virtual-network.md)
+Il est également conseillé de suivre les procédures suivantes:
+- [1.6: Création d'alias de connexion SSH](../1-virtual-machine/ssh-alias.md) (pour se connecter plus facilement au serveur de reverse proxy)
+- [2.2: Installer sudo pour l'utilisation de commandes en tant qu'administrateur](../2-configuration-services/sudo.md) (pour configurer `nginx` plus facilement)
-## Etape 2 : Installer un serveur Nginx
+## 2. Installer le serveur `nginx`
-Maintenant, il faut installer sur cette machine un serveur Nginx, qui redirigera les requetes vers notre autre serveur.
+Maintenant que la nouvelle machine virtuelle est créée et configurée, il faut installer sur cette machine un serveur `nginx`, qui redirigera les requêtes vers notre instance Matrix.
-Pour cela, consultez [3.1 : Mise en place de l'accès au service HTTP sur la VM](../3-synapse/http-service-vm.md)
+Pour cela, consultez la procédure sur l'installation de `nginx`:
+- [3.1 : Mise en place de l'accès au service HTTP sur la VM](../3-synapse/http-service-vm.md)
-## Etape 3
+## 3. Configuration du reverse proxy
-## Etape x : Redirection de port
+Une fois `nginx` installé, nous allons configurer le reverse proxy pour rediriger les requêtes vers notre instance de Matrix.
-Modifier votre config ssh `~/.ssh/config` pour que l'ancienne machine virtuelle ne soit plus directement accessible sur le port 8008 de la machine physique.
+Créez un nouveau fichier `matrix` dans `/etc/nginx/sites-available` à l'aide de votre éditeur de texte (en tant qu'administrateur) avec le contenu suivant:
-Pour cela, supprimez cette ligne de la configuration `vm` :
+```bash
+user@rproxy $ sudo nano /etc/nginx/sites-available/matrix
+```
-> LocalForward 9090 10.42.154.1:80
+```nginx
+server {
+ listen 9090;
-Puis, ajoutez cette ligne pour que le reverse proxy soit accessible sur le port `9090` de la machine physique dans la configuration `rproxy`.
+ server_name rproxy;
-> LocalForward 9090 10.42.154.2:80
+ location / {
+ proxy_pass http://10.42.155.1:8008;
+ proxy_set_header Host $host;
+ proxy_set_header X-Real-IP $remote_addr;
+ proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
+ }
+}
+```
+
+Une fois le fichier créé, liez le fichier de configuration du reverse proxy au dossier `sites-enabled` de `nginx`:
+
+```bash
+user@rproxy $ sudo ln -s /etc/nginx/sites-available/matrix /etc/nginx/sites-enabled
+```
+
+Vérifiez la configuration de nginx au cas où il y aurait des erreurs:
+
+```bash
+user@rproxy $ sudo nginx -t
+```
+
+Puis redémarrez le service nginx:
+
+```bash
+user@rproxy $ sudo systemctl restart nginx
+```
+
+## 4. Configuration du tunnel SSH
+
+Sur la machine hôte, modifiez le contenu du fichier de configuration ssh (`~/.ssh/config`) pour que le service Matrix ne soit plus accessible directement depuis le port 8008 de la machine virtuelle `matrix`.
+
+Pour cela, supprimez cette ligne de la configuration `vm`:
+
+```
+ LocalForward 9090 localhost:80
+```
+
+Puis, ajoutez une configuration supplémentaire pour la machine `rproxy`:
+
+```
+Host rproxy
+ Hostname 10.42.x.2
+ User user
+ ProxyJump virt
+ LocalForward 9090 localhost:9090
+```
+
+Une fois les changements opérés et sauvegardés, reconnectez-vous à la machine virtuelle `rproxy` via votre alias.
+
+Si tout a bien été configuré, vous pouvez vérifier si le service Matrix est bien accessible sur l'adresse [http://localhost:9090](http://localhost:9090).
+
+
- Page précédente: [4.1 Installation de Element Web](./install-element-web.md)
-- Page suivante: [Sommaire (partie 5)]()
\ No newline at end of file
+- Page suivante: [Sommaire (partie 5)](/procedures/5-final-architecture/README.md)
\ No newline at end of file
diff --git a/procedures/5-final-architecture/README.md b/procedures/5-final-architecture/README.md
index 353dc08..084787c 100644
--- a/procedures/5-final-architecture/README.md
+++ b/procedures/5-final-architecture/README.md
@@ -1,13 +1,13 @@
<div style="text-align: center;">
-<h1 style="border: none; margin: 0">🚀 PARTIE 5 : Migration et configuration de l'architecture finale</h1>
+<h1 style="border: none; margin: 0">🏗️ PARTIE 5 : Migration et configuration de l'architecture finale</h1>
</div>
# Sommaire
-- [5.1 Problème de notre architecture actuelle et explication de l'architecture finale](./current-issue.md)
-- [5.2 Configuration de l'architecture finale](./final-architecture.md)
+- [5.1: Problème de notre architecture actuelle et explication de l'architecture finale](./current-issue.md)
+- [5.2: Configuration de l'architecture finale](./final-architecture.md)
<hr>
-- Page précédente: [a ajouter]()
-- Page suivante: [a ajouter]()
\ No newline at end of file
+- Page précédente: [Installation d'un reverse proxy](/procedures/4-element-proxy/install-reverse-proxy.md)
+- Page suivante: [Problème de notre architecture actuelle et explication de l'architecture finale](current-issue.md)
\ No newline at end of file
diff --git a/procedures/5-final-architecture/current-issue.md b/procedures/5-final-architecture/current-issue.md
index 2cb9908..e404802 100644
--- a/procedures/5-final-architecture/current-issue.md
+++ b/procedures/5-final-architecture/current-issue.md
@@ -1,4 +1,4 @@
-# 5.1 : Problèmes de notre architecture actuelle et présentation de l’architecture finale
+# 5.1: Problèmes de notre architecture actuelle et présentation de l’architecture finale
À ce stade, notre déploiement regroupe tous les services sur une seule machine virtuelle, à l’exception du reverse proxy. Bien que fonctionnelle, cette configuration présente des limitations majeures qui justifient une refonte de l’architecture.
diff --git a/procedures/5-final-architecture/final-architecture.md b/procedures/5-final-architecture/final-architecture.md
index e2979e6..ad94dc0 100644
--- a/procedures/5-final-architecture/final-architecture.md
+++ b/procedures/5-final-architecture/final-architecture.md
@@ -1,4 +1,4 @@
-# 5.2 : Configuration de l’architecture finale
+# 5.2: Configuration de l’architecture finale
Cette section détaille les étapes nécessaires pour configurer l’architecture distribuée, en répartissant les services (Synapse, Element, Reverse Proxy) sur des machines virtuelles distinctes.
--
GitLab