Explication de la partie réseau et rectificatifs
Pierre Coimbra
parent
58f143471e
commit
ee247565d4
|
|
@ -3,19 +3,19 @@
|
|||
Documentation par Pierre Coimbra.
|
||||
|
||||
## Motivation du projet
|
||||
D'abord, l'idée est d'héberger tous les outils utilisés par le club (Web, NextCloud,Git...) afin d'avoir un contrôle total sur les services que nous utilisons. Ensuite, nous voudrions mettre en place une structure capable d'accueillir des environnements de CTF correctement cloisonnée des services permanents du club.
|
||||
D'abord, l'idée est d'héberger tous les outils utilisés par le club (Web, NextCloud,Git...) afin d'avoir un contrôle total sur les services que nous utilisons. Ensuite, nous voudrions mettre en place une structure capable d'accueillir des environnements de CTF correctement cloisonnés par rapport aux services permanents du club.
|
||||
|
||||
## Porteurs du projet
|
||||
- P. Coimbra
|
||||
- D. Pressensé
|
||||
|
||||
## La philosophie
|
||||
Le fait de reprendre le contrôle physique sur les infrastructures techniques utilisées au sein du club s'inscrit dans une démarche volontaire. Cela nous permettra d'élargir le champs de nos connaissances sur des problématiques concrètes.
|
||||
Le fait de reprendre le contrôle physique sur les infrastructures techniques utilisées au sein du club s'inscrit dans une démarche volontaire. Cela nous permettra d'élargir le champ de nos connaissances sur des problématiques concrètes.
|
||||
|
||||
L'indépendance financière et la pérennité sont des points clefs dans un projet d'une telle ampleur un petit club étudiant. Ainsi le fait que nous ne soyons plus dépendants d'un service payant chez OVH, nous libère de beaucoup de contraintes à la fois pécuniaires et organisationnelles. La documentation et la transmission des connaissances sera primordiale.
|
||||
L'indépendance financière et la pérennité sont des points clefs dans un projet d'une telle ampleur pour un petit club étudiant. Ainsi, le fait que nous ne soyons plus dépendants d'un service payant chez OVH nous libère de beaucoup de contraintes à la fois pécuniaires et organisationnelles. La documentation et la transmission des connaissances seront primordiales.
|
||||
|
||||
## Les responsabilités
|
||||
Nous sommes conscients que dans un tel projet, le plus dur n'est pas de monter l'infrastructure, mais de la maintenir au fil des années. Les responsabilités seront donc gérées de manière extrêmement strictes, avec plusieurs niveaux d'accès. Il faudra en effet différencier le poste du webmestre qui ne pourra agir que sur la partie applicative, de celui de l'administrateur système qui aura l'accès global. De grands pouvoirs appelant de grandes responsabilités, les adminsys en poste auront la
|
||||
Nous sommes conscients que dans un tel projet, le plus dur n'est pas de monter l'infrastructure, mais de la maintenir au fil des années. Les responsabilités seront donc gérées de manière extrêmement strictes, avec plusieurs niveaux d'accès. Il faudra en effet différencier le poste de webmestre, qui ne pourra agir que sur la partie applicative, de celui de l'administrateur système qui aura l'accès global. De grands pouvoirs appelant de grandes responsabilités, les adminsys en poste auront la
|
||||
charge de former leur successeurs.
|
||||
|
||||
# Table des matières
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
# Applicatif
|
||||
Vous trouverez ici toute la documentation relative à la partie applicative. Les services sont découpés en plusieurs zones qui sont décrite dans le premier point. L'accès au réseau des services de cette zone est décrit dans la partie réseau, il est donc impératif de mettre en place le réseau avant de s'occuper de l'applicatif.
|
||||
Vous trouverez ici toute la documentation relative à la partie applicative. Les services sont découpés en plusieurs zones qui sont décrites dans le premier point. L'accès au réseau des services est décrit dans la partie réseau, il est donc impératif de mettre en place le réseau avant de s'occuper de l'applicatif.
|
||||
|
||||
# Table des matières
|
||||
1. [Répartition des services dans les zones](repartition_en_zones.md)
|
||||
|
|
|
|||
|
|
@ -1,17 +1,17 @@
|
|||
# Répartition des services en zones
|
||||
|
||||
Les services seront réparti en plusieurs zones à la manière du découpage du réseau. Il est donc recommandé d'avoir compris l'infrastructure réseau avant de lire cette partie.
|
||||
Les services seront répartis en plusieurs zones à la manière du découpage du réseau. Il est donc recommandé d'avoir compris l'infrastructure réseau avant de lire cette partie.
|
||||
|
||||
|
||||
## Services Frontend
|
||||
|
||||
Les services Frontend sont directement accessible depuis internet derrière OPNSense.
|
||||
Les services Frontend sont directement accessibles depuis internet derrière OPNSense.
|
||||
|
||||
### Zone WAN
|
||||
|
||||
Cette zone regroupe les pare-feux et les hyperviseurs.
|
||||
|
||||
Les services DMZ devront avoir les interfaces réseau suivante
|
||||
Les services DMZ devront avoir les interfaces réseau suivantes :
|
||||
- Bridge WAN VLAN 10 (WAN)
|
||||
- Bridge Admin VLAN 100 (ADMIN)
|
||||
|
||||
|
|
@ -21,14 +21,14 @@ Pour OPNSense
|
|||
|
||||
### Zone DMZ
|
||||
|
||||
Cette zone regroupe les services qui nécessite un accès direct à internet.
|
||||
Cette zone regroupe les services qui nécessitent un accès direct à internet.
|
||||
|
||||
C'est le cas de,
|
||||
- HAProxy, le proxy/loadbalanceur qui filtre les accès aux services depuis l'extérieur.
|
||||
- Bind9, le serveur DNS qui servira à la fois de résolveur interne et de zone DNS pour le domaine krhacken.org.
|
||||
- Squid, le proxy filtrant qui s'occupe de gérer l'accès à internet des conteneurs/VM
|
||||
|
||||
Les services DMZ devront avoir les interfaces réseau suivante
|
||||
Les services DMZ devront avoir les interfaces réseau suivantes :
|
||||
- Bridge Interne VLAN 10 (DMZ)
|
||||
- Bridge Admin VLAN 100 (ADMIN)
|
||||
|
||||
|
|
@ -50,45 +50,45 @@ Pour Squid
|
|||
## Services Backend
|
||||
|
||||
### Zone PROXY
|
||||
Cette zone est une sorte de DMZ de DMZ, c'est à dire qu'elle se place entre la DMZ et la zone INT. Elle acceuille les services faisant le lien entre la Frontend et la backend.
|
||||
Cette zone est une sorte de DMZ de DMZ, c'est à dire qu'elle se place entre la DMZ et la zone INT. Elle accueille les services faisant le lien entre la Frontend et la backend.
|
||||
|
||||
C'est le cas de,
|
||||
C'est le cas de
|
||||
- NGINX qui servira de reverse proxy http
|
||||
- Proxmox Mail Gateway, le relais entre l'extérieur et le serveur mail en backend qui s'occupe aussi de filtrer les mails (antispam et antivirus).
|
||||
|
||||
Les services de la zone PROXY devront avoir les interfaces réseau suivante
|
||||
Les services de la zone PROXY devront avoir les interfaces réseau suivantes :
|
||||
- Bridge Interne VLAN 20 (PROXY)
|
||||
- Bridge Interne VLAN 30 (INT)
|
||||
- Bridge Admin VLAN 100 (ADMIN)
|
||||
|
||||
### Zone INT
|
||||
Cette zone regroupe les services sensibles permanents soit tout sauf ce qui concerne les tests et les CTF. Elle contient uniquement des services backend.
|
||||
Cette zone regroupe les services sensibles permanents, donc tout sauf ce qui concerne les tests et les CTF. Elle contient uniquement des services backend.
|
||||
|
||||
C'est le cas de,
|
||||
- L'annuaire LDAP (slapd), qui permettra d'avoir un compte unique pour accéder à tous nos services, avec des groupes limitant l'accès à certain services.
|
||||
C'est le cas de
|
||||
- L'annuaire LDAP (slapd) qui permettra d'avoir un compte unique pour accéder à tous nos services, avec des groupes limitant l'accès à certains services.
|
||||
- Du serveur mail qui sera en lien avec le relais mail présent dans le zone PROXY.
|
||||
- Tout les autres services plus classique (serveurs web, cloud, git...).
|
||||
- Tous les autres services plus classiques (serveurs web, cloud, git...).
|
||||
|
||||
Les services de la zone INT devront avoir les interfaces réseau suivante
|
||||
Les services de la zone INT devront avoir les interfaces réseau suivantes :
|
||||
- Bridge Interne VLAN 30 (INT)
|
||||
- Bridge Admin VLAN 100 (ADMIN)
|
||||
|
||||
### Zone CTF
|
||||
Cette zone regroupe les différents services en rapport avec la partie CTF
|
||||
Cette zone regroupe les différents services en rapport avec la partie CTF.
|
||||
|
||||
C'est le cas de
|
||||
- NGINX, qui servira de reverse proxy dédié à la partie CTF.
|
||||
- VM avec du Docker pour les environnement Web et Système.
|
||||
- NGINX qui servira de reverse proxy dédié à la partie CTF.
|
||||
- VM avec du Docker pour les environnements Web et Système.
|
||||
- CTFd qui servira d'interface utilisateur pour les CTF.
|
||||
|
||||
Les services de la zone CTF devront avoir les interfaces réseau suivante
|
||||
Les services de la zone CTF devront avoir les interfaces réseau suivantes :
|
||||
- Bridge Interne VLAN 40 (CTF)
|
||||
- Bridge Admin VLAN 100 (ADMIN)
|
||||
|
||||
### Zone DIRTY
|
||||
|
||||
Cette zone regroupe rien de spécial à part d'éventuels containers de test. Elle ne sera d'ailleurs pas documenté ici.
|
||||
Cette zone ne regroupe rien de spécial mis à part d'éventuels containers de test. Elle ne sera d'ailleurs pas documentée ici.
|
||||
|
||||
Les services de la zone DIRTY devront avoir les interfaces réseau suivante
|
||||
Les services de la zone DIRTY devront avoir les interfaces réseau suivantes :
|
||||
- Bridge Interne VLAN 50 (DIRTY)
|
||||
- Bridge Admin VLAN 100 (ADMIN)
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ Vous trouverez ici toute la documentation relative au fonctionnement et à la co
|
|||
Cela comprend le reverse proxy CTF, l'environnement Web, l'environnement Système et CTFd.
|
||||
|
||||
## Réseau
|
||||
Les services de la zone CTF devront avoir les interfaces réseaux suivante
|
||||
Les services de la zone CTF devront avoir les interfaces réseaux suivantes :
|
||||
- Bridge Interne VLAN 40 (CTF)
|
||||
- Bridge Admin VLAN 100 (ADMIN)
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ Vous trouverez ici toute la documentation relative au fonctionnement et à la co
|
|||
Cela comprend les deux HAProxy, le serveur DNS et le proxy pour l'accès à internet des contenants.
|
||||
|
||||
## Réseau
|
||||
Les services DMZ devront avoir les interfaces réseau suivante
|
||||
Les services DMZ devront avoir les interfaces réseau suivantes :
|
||||
- Bridge Interne VLAN 10 (DMZ)
|
||||
- Bridge Admin VLAN 100 (ADMIN)
|
||||
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
# Zone INT
|
||||
Vous trouverez ici toute la documentation relative au fonctionnement et à la configuration applicative des services de la zone INT.
|
||||
|
||||
Cela comprend tous les containers des services sensible permanents (Nextcloud, Gitea...) et les services internes nécessaires au fonctionnement des services sensible comme l'annuaire LDAP.
|
||||
Cela comprend tous les containers des services sensibles permanents (Nextcloud, Gitea...) et les services internes nécessaires au fonctionnement des services sensibles comme l'annuaire LDAP.
|
||||
|
||||
## Réseau
|
||||
Les services de la zone PROXY devront avoir les interfaces réseau suivante
|
||||
Les services de la zone PROXY devront avoir les interfaces réseau suivantes :
|
||||
- Bridge Interne VLAN 20 (PROXY)
|
||||
- Bridge Interne VLAN 30 (INT)
|
||||
- Bridge Admin VLAN 100 (ADMIN)
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ Vous trouverez ici toute la documentation relative au fonctionnement et à la co
|
|||
Cela comprend tous les services faisant le lien entre la frontend et la backend (Reverse NGINX et Relais Mail).
|
||||
|
||||
## Réseau
|
||||
Les services de la zone PROXY devront avoir les interfaces réseau suivante
|
||||
Les services de la zone PROXY devront avoir les interfaces réseau suivantes :
|
||||
- Bridge Interne VLAN 20 (PROXY)
|
||||
- Bridge Interne VLAN 30 (INT)
|
||||
- Bridge Admin VLAN 100 (ADMIN)
|
||||
|
|
|
|||
|
|
@ -2,9 +2,9 @@
|
|||
|
||||
### Infrastructure matérielle
|
||||
|
||||
Du côté infrastructure, nous disposons d'un rack 1U avec deux PC à l'intérieur possédant chacun 24Go de DDR3-ECC et un Xeon x5670 6 Coeurs cadencé à 2.93 GHz. Côté stockage, nous allons mettre en place un RAID1 ZFS avec deux disque par PC (les données du premier disque seront aussi présente sur le second) ainsi le stockage sera répliqué pour éviter toute perte de données.
|
||||
Du côté infrastructure, nous disposons d'un rack 1U avec deux PC à l'intérieur possédant chacun 24Go de DDR3-ECC et un Xeon x5670 6 Coeurs cadencé à 2.93 GHz. Côté stockage, nous allons mettre en place un RAID1 ZFS avec deux disques par PC (les données du premier disque seront aussi présentes sur le second) ainsi le stockage sera répliqué pour éviter toute perte de données.
|
||||
|
||||
Les 2 nodes du serveurs, que nous appellerons Alpha et Beta, auront Proxmox comme hyperviseur et seront en cluster grâce à Proxmox.
|
||||
Les 2 nodes du serveur, que nous appellerons Alpha et Beta, auront Proxmox comme hyperviseur et seront en cluster grâce à Proxmox.
|
||||
|
||||
### Infrastructure logicielle
|
||||
|
||||
|
|
@ -13,9 +13,9 @@ Les containers/VMs sensibles seront répliqués entre les deux nodes
|
|||
|
||||
L'infrastructure réseau du club s'articulerait de la manière suivante (sur chaque node) :
|
||||
- Un bloc pare-feu / routeur (OPNSense).
|
||||
- Un répartiteur de charge qui permettra de répartir les requêtes web entre le reverse proxy de la partie CTF et ceux de la partie Club (HAProxy).
|
||||
- Un répartiteur de charge qui permettra de répartir les requêtes web entre le reverse proxy de la partie CTF et les reverse proxy de la partie Club (HAProxy).
|
||||
- Les reverse proxy (NGINX) de la partie Club redirigeront les requêtes vers les serveurs web internes (Site Web, Cloud...).
|
||||
- Le reverse proxy (NGINX) de la partie CTF redirigera les requêtes vers les différents environnement CTF (CTFd, Challenges Web...).
|
||||
- Le reverse proxy (NGINX) de la partie CTF redirigera les requêtes vers les différents environnements CTF (CTFd, Challenges Web...).
|
||||
|
||||
#### Services permanents
|
||||
Les containers/VMs permettant l'accès à ces services ne sont pas détaillés ici.
|
||||
|
|
@ -32,21 +32,20 @@ Avec en plus,
|
|||
- Un service de messagerie instantanée du type Mattermost.
|
||||
- Et d'autres services...
|
||||
|
||||
Ce qui permettrait d'auto-héberger tout les services du club.
|
||||
Ce qui permettrait d'auto-héberger tous les services du club.
|
||||
|
||||
#### Environnements CTF
|
||||
L'objectif est de remplacer la banque de challenge du club stockée actuellement sur un poste en B141. Celui-ci n'est pas documenté, ce qui réduit les modifications que nous pouvons y apporter.
|
||||
|
||||
A partir des sources des challenges actuels une nouvelle infrastructure CTF prendra forme, elle s'organisera de la manière suivante :
|
||||
- Un premier CTFd avec tous les challenges du club utilisés pour les OpenCTF.
|
||||
- Un autre CTFd que nous utiliserons pour les sessions en externe comme par exemple pour la session 0.
|
||||
- Un autre CTFd que nous utiliserons pour les sessions en externe, comme par exemple pour la session 0.
|
||||
- Une VM avec différents environnements Docker temporaires pour les challenges système.
|
||||
- Une VM avec différents environnements Docker pour les challenges Web.
|
||||
|
||||
## Gestion du serveur en interne
|
||||
|
||||
Pour la gestion en interne du serveur, nous nous organiserions de la manière suivante,
|
||||
|
||||
- Seules deux personnes du bureau auront le rôle d'administrateur système, soit tout les droits sur le serveur.
|
||||
- Le responsable technique du club aura le rôle du webmestre, il pourra intervenir sur les services comme le site web, le cloud... Cependant il ne pourra pas toucher à l'infrastructure autour.
|
||||
- Tous les membres actifs du club y auront accès auront accès aux services web.
|
||||
Pour la gestion en interne du serveur, nous nous organiserions de la manière suivante :
|
||||
- Seules deux personnes du bureau auront le rôle d'administrateur système, soit tous les droits sur le serveur.
|
||||
- Le responsable technique du club aura le rôle du webmestre, il pourra intervenir sur les services comme le site web, le cloud... Cependant, il ne pourra pas toucher à l'infrastructure autour.
|
||||
- Tous les membres actifs du club auront accès aux services web.
|
||||
|
|
|
|||
|
|
@ -1,13 +1,34 @@
|
|||
# Mise en place du cluster entre nos deux nodes
|
||||
Il faut avoir mis en place le réseau avant de mettre les deux nodes en cluster.
|
||||
|
||||
Les nodes seront accessible grâce au DNS interne via
|
||||
Un lien externalisé entre Alpha et Beta est déjà en place grâce à un Int Port sur le VLAN 30 du switch administration.
|
||||
|
||||
Les nodes seront accessibles grâce au DNS interne via :
|
||||
- alpha.krhacken.org -> 10.0.5.1
|
||||
- beta.krhacken.org -> 10.0.5.2
|
||||
|
||||
La configuration des hostnames n'est normalement pas nécessaire car faite par le DNS interne. Cependant, il est préférable de la faire pour éviter les problèmes en cas de chute du DNS.
|
||||
|
||||
### /etc/hosts
|
||||
|
||||
##### Sur Alpha
|
||||
```
|
||||
alpha.krhacken.org
|
||||
beta.krhacken.org
|
||||
127.0.0.1 localhost.localdomain localhost
|
||||
X.X.X.X alpha.krhacken.org alpha pvelocalhost
|
||||
#Corosync
|
||||
10.0.5.1 alpha-corosync.krhacken.org alpha-corosync
|
||||
10.0.5.2 beta-corosync.krhacken.org beta-corosync
|
||||
```
|
||||
|
||||
Un lien externalisé entre Alpha et Beta est déjà en place.
|
||||
##### Sur Beta
|
||||
```
|
||||
127.0.0.1 localhost.localdomain localhost
|
||||
Y.Y.Y.Y beta.krhacken.org beta pvelocalhost
|
||||
#Corosync
|
||||
10.0.5.1 alpha-corosync.krhacken.org alpha-corosync
|
||||
10.0.5.2 beta-corosync.krhacken.org beta-corosync
|
||||
```
|
||||
Le multicast entre Alpha et Beta est désormais accessible via des hostnames.
|
||||
|
||||
### Création du cluster
|
||||
Nous allons maintenant créer le cluster Sigma depuis Alpha,
|
||||
|
|
@ -18,4 +39,6 @@ On ajoute Beta au cluster Sigma directement depuis Beta
|
|||
```
|
||||
pvecm add alpha-corosync --link0 beta-corosync
|
||||
```
|
||||
Notre cluster Sigma est maintenant créé et corosync utilise une interface différente de celle utilisée pour les communications avec l'extérieur.
|
||||
Notre cluster Sigma est maintenant créé et corosync utilise la VLAN 30 du switch administration pour communiquer.
|
||||
|
||||
Il est nécessaire de mettre rapidement en place l'instance de quorum pour éviter d'avoir des problèmes au seins du cluster.
|
||||
|
|
|
|||
|
|
@ -1,24 +1,26 @@
|
|||
# Installation des hyperviseurs
|
||||
|
||||
Proxmox étant un hyperviseur de type 1 il possède son propre OS, c'est donc ça que nous devons installer sur les deux nodes du serveur.
|
||||
Proxmox étant un hyperviseur de type 1, nous allons l'installer sur les deux nodes du serveur.
|
||||
|
||||
Pour cette installation nous partons du principe que les deux nodes on accès à internet soit via une IP publique soit via une réseau privée. Cela ne change rien car nous modifierons la configuration réseau par la suite.
|
||||
Pour cette installation, nous partons du principe que les deux nodes ont accès à internet soit via une IP publique soit via un réseau privé. Cela ne change rien car nous modifierons la configuration réseau par la suite.
|
||||
|
||||
Pour l'installation il faut
|
||||
- Une clé USB
|
||||
- Deux disques dur de même taille pour chaque node
|
||||
Pour l'installation il faut :
|
||||
- Une clé USB,
|
||||
- Deux disques durs de même taille pour chaque node.
|
||||
|
||||
## Installation de Proxmox
|
||||
Procurez-vous la dernière version de Proxmox, attention l'installation initiale à été faire sous Proxmox 6.
|
||||
Procurez-vous la dernière version de Proxmox. Attention, l'installation initiale à été faite sous Proxmox 6.
|
||||
|
||||
Voilà le [lien](https://www.proxmox.com/en/downloads/category/iso-images-pve) de l'installateur
|
||||
|
||||
A vous de rendre une clé bootable avec cet iso.
|
||||
|
||||
### Sur la première node (Alpha)
|
||||
Mettez la clé USB sur un des ports USB de la première nodes (celle de droite), branchez un clavier et un écran puis démarrer l'installation.
|
||||
- Mettre la clé USB sur l'un des ports USB de la première node (celle de droite),
|
||||
- Brancher un clavier et un écran puis
|
||||
- Démarrer l'installateur en allumant la node.
|
||||
- Choisir "Install Proxmox VE" et accepter l'EULA.
|
||||
|
||||
Choissisez Install Proxmox VE et acceptez l'EULA.
|
||||
#### Dans Proxmox Virtualization Environment
|
||||
|
||||
Target Harddisk -> Options
|
||||
|
|
@ -43,16 +45,16 @@ Disk Setup
|
|||
#### Management Network Configuration
|
||||
- Hostname (FQDN) -> alpha.krhacken.org
|
||||
|
||||
Normalement un IP est automatiquement attribué. Si ce n'est pas le cas à vous de le faire.
|
||||
Normalement une IP est automatiquement attribuée. Si ce n'est pas le cas, à vous de le faire.
|
||||
|
||||
#### Summary
|
||||
Vérifier la cohérence et lancer l'installation.
|
||||
|
||||
### Sur la deuxième node (Beta)
|
||||
Même procédure, il faut juste dans "Management Network Configuration" remplacer le Hostname par **beta.krhacken.org**
|
||||
Même procédure, dans "Management Network Configuration" il faut juste remplacer le Hostname par **beta.krhacken.org**
|
||||
|
||||
## Préparation des hyperviseurs
|
||||
La procédure est la même sur les deux nodes. Elle peux être faites via SSH (recommandé) ou sur l'interface d'administration **https://IP:8006**
|
||||
La procédure est la même sur les deux nodes. Elle peut être faite via SSH (recommandé) ou sur l'interface d'administration **https://IP:8006**
|
||||
|
||||
### Mise à jour
|
||||
```
|
||||
|
|
@ -61,21 +63,21 @@ apt-get full-upgrade
|
|||
```
|
||||
|
||||
### Templates LXC
|
||||
Mise à jours de la liste
|
||||
Mise à jour de la liste
|
||||
```
|
||||
pveam update
|
||||
```
|
||||
Liste les templates disponible
|
||||
Liste les templates disponibles
|
||||
```
|
||||
pveam available
|
||||
```
|
||||
Téléchargement le la dernière debian system
|
||||
Téléchargement de la dernière debian system
|
||||
```
|
||||
pveam download local debian-10.0-standard_10.0-1_amd64.tar.gz
|
||||
```
|
||||
|
||||
### Images VM
|
||||
Nous aurons besoin de VM OPNSense (Pare-Feu) et de VM debian, il faut donc télécharger les derniers ISO disponible
|
||||
Nous aurons besoin de VM OPNSense (Pare-Feu) et de VM debian, il faut donc télécharger les derniers ISO disponibles.
|
||||
|
||||
#### OPNSense
|
||||
VM nécessaire car c'est une distribution Free-BSD
|
||||
|
|
|
|||
|
|
@ -1,26 +1,26 @@
|
|||
# Introduction à la virtualisation
|
||||
|
||||
Proxmox est un hyperviseur de type 1 (« bare metal »). Pour faire simple c’est une plateforme de virtualisation directement installé sur le serveur.
|
||||
Proxmox est un hyperviseur de type 1 (bare metal). C’est une plateforme de virtualisation directement installée sur le serveur.
|
||||
|
||||
Contrairement à un hyperviseur de type 2 (VirtualBox par exemple), proxmox ne s'exécute pas dans un autre OS mais dispose de son propre OS adapté à la virtualisation.
|
||||
Contrairement à un hyperviseur de type 2 (VirtualBox par exemple), Proxmox ne s'exécute pas dans un autre OS mais dispose de son propre OS (basé sur Debian) adapté à la virtualisation.
|
||||
|
||||
Donc proxmox permet la virtualisation de plusieurs machine au sein d’un seul serveur. Il est aussi possible de mettre plusieurs serveur sous Proxmox en cluster. Dans le cas d'un cluster il est possible d'utiliser les fonction Haute Disponibilité de Proxmox qui permettent entre autres de migrer des contenants d'une node à l'autre en cas de chute de l'un d'entre elles.
|
||||
Donc, Proxmox permet la virtualisation de plusieurs machines au sein d’un seul serveur. Proxmox nous permettra aussi des mettre les deux nodes du rack en cluster permettant entre autre de migrer des contenants d'une node à l'autre en cas de chute de l'une d'elles grâce aux fonctions de Haute Disponibilité de Proxmox.
|
||||
|
||||
## Technologie de virtualisation
|
||||
|
||||
Proxmox propose deux types de virtualisation
|
||||
- KVM qui est une technologie de virtualisation similaire à ce qui est offert par VirtualBox. Tout le matériel est émulé par l'hyperviseur. Ainsi, le système d'exploitation croit s'exécuter sur une vraie machine physique. Les ressource alloué sont considéré comme totalement utilisé par Proxmox.
|
||||
- LXC qui utilise l'isolement pour séparer l'exécution de chaque machine. En comparaison à KVM, le matériel n'est pas émulé, il est partagé par le système hôte. Ainsi, chaque machine virtuelle utilise le même noyau. Seule les ressources vraiment utilisé par le container sont considérer comme utilisé par Proxmox.
|
||||
Proxmox propose deux types de virtualisation :
|
||||
- Une technologie de virtualisation (KVM) similaire à celle qui est offerte par VirtualBox. Tout le matériel est émulé par l'hyperviseur, ainsi le système d'exploitation croit s'exécuter sur une machine physique. Les ressources allouées sont considérées comme totalement utilisées par Proxmox. Si la VM a 2Go de RAM, l'hyperviseur lui alloue en permanence 2Go de RAM.
|
||||
- Une technologie de conteneurisation (LXC) qui utilise l'isolement pour séparer l'exécution de chaque environnement virtuel. En comparaison à KVM, le matériel n'est pas émulé, il est partagé par le système hôte, ainsi tous les containers utilisent le même noyau. Seules les ressources vraiment utilisées par le container sont considérées comme utilisées par Proxmox. Si on alloue 2Go de RAM au container et qu'il en utilise un seul, l'hyperviseur ne lui alloue qu'un 1Go.
|
||||
|
||||
Pour notre infrastructure nous utiliserons le plus possible des containers LXC. Cependant pour les environnements CTF nécessitant Docker et pour OPNSense nous utiliserons des VM KVM.
|
||||
Pour notre infrastructure, nous utiliserons le plus possible des containers LXC. Cependant, pour les environnements CTF nécessitant Docker et pour le pare-feu (OPNSense), nous utiliserons des VM KVM.
|
||||
|
||||
## Qualité de Proxmox
|
||||
Voilà un petit aperçu des fonctionnalité de Proxmox
|
||||
Voici un petit aperçu des fonctionnalités de Proxmox :
|
||||
- Création de containers LXC et de VM en quelques clics.
|
||||
- Possibilité de modifier les ressources allouées aux contenants (RAM, disques, nombres d’interfaces réseau, VLANs...)
|
||||
- La gestion des stockages (disques dur machines, images iso, templates LXC,...) est très simple est très bien intégré à l'interface web de Proxmox.
|
||||
- L’interface permet une gestion complète des machines : Shell, éteindre, démarrer, redémarrer...
|
||||
- Gestion de l’ensemble des VM depuis une seule interface web.
|
||||
- Gestion des utilisateurs, de groupes d’utilisateurs et management de droits d’accès à des machines.
|
||||
- Gestion de l’hyperviseur lui-même : Redémarrage, accès shell, monitoring réseau et charge cpu, RAM...
|
||||
- La migration des contenants entre les nodes d'un cluster est également simple et rapide.
|
||||
- Gestion des stockages (disques durs des machines, images iso, templates LXC,...) très simple et très bien intégrée à l'interface web.
|
||||
- Gestion complète des machines : Shell, éteindre, démarrer, redémarrer...
|
||||
- Gestion de l’ensemble des machines depuis une seule interface web.
|
||||
- Gestion des utilisateurs, de groupes d’utilisateurs et management des droits d’accès aux machines.
|
||||
- Gestion de l’hyperviseur lui-même : Redémarrage, accès shell, monitoring réseau et charge CPU, RAM...
|
||||
- Migration des contenants entre les nodes d'un cluster simple et rapide.
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
# Introduction à OpenvSwitch
|
||||
|
||||
Pour l'infrastructure réseau nous utiliserons OpenvSwitch.
|
||||
Pour l'infrastructure réseau, nous utiliserons OpenvSwitch.
|
||||
|
||||
OpenvSwitch est une alternative aux bridges Linux classique. Il permet de créer des switchs (L2/L3) virtuel au seins de Proxmox qui peuvent communiquer entre eux via un lien trunk et qui gèrent très bien les VLANs.
|
||||
OpenvSwitch est une alternative aux bridges Linux classiques. Il permet de créer des switchs (L2/L3) virtuels au sein de Proxmox. Ces switchs virtuels gèrent très bien les VLANs. OpenvSwitch permet aussi à plusieurs switchs de communiquer entre eux via un lien trunk (GRE, VXLAN...).
|
||||
|
||||
## Explication rapide du fonctionnement
|
||||
|
||||
- OVS Bridge, c'est comme un switch, mais en virtualisé sur lequel on peu branché des CT et VM sur des VLANs et qui peux communiquer avec un autre Bridge via un tunnel GRE. Pour notre usage le bridge n'aura pas d'IP sur l'hôte.
|
||||
- OVS Bond, permet d'attacher un groupe d'interface physique à un Bridge OVS ie. un groupe d'interface réseau à un switch virtuel.
|
||||
- OVS IntPort, pas possible de bridge des VMs ou des CT dessus, il permet à l'hôte de se brancher au Bridge et d'avoir une IP et éventuellement une VLAN.
|
||||
Fonctionnalités principales d'OpenvSwitch :
|
||||
- OVS Bridge peut être comparé à un switch virtuel sur lequel on peut brancher des CT et VM sur des VLANs et qui peut communiquer avec un autre switch (bridge) via un tunnel GRE. Pour notre usage, le bridge n'aura pas d'IP sur l'hôte.
|
||||
- OVS Bond permet d'attacher un groupe d'interfaces physiques (cartes réseau) à un Bridge OVS. Ce groupe d'interfaces physiques est considéré comme une seule interface virtuelle par le switch. Si deux cartes réseau forment un Bond, leur bande passante est additionnée et si l'une d'entre elles casse, l'autre prend le relais.
|
||||
- OVS IntPort permet à l'hôte de se brancher au Bridge, d'avoir une IP et éventuellement une VLAN mais il est impossible de brancher des VMs ou des CT dessus.
|
||||
|
|
|
|||
|
|
@ -1,28 +1,28 @@
|
|||
# Topologie globale de l'infrastructure
|
||||
Le réseau sera découpé en deux sous réseau matérialisé par des switchs virtuel. Le réseau interne accessible directement depuis l'extérieur et le réseau d'administation accessible uniquement via un VPN.
|
||||
Le réseau sera découpé en deux sous-réseaux matérialisés par des switchs virtuels : le réseau interne accessible directement depuis l'extérieur et le réseau d'administration accessible uniquement via un VPN.
|
||||
|
||||
## Réseau WAN
|
||||
|
||||
Le réseau WAN permettra de faire le lien entre l'extérieur, les pare-feu et les hyperviseurs.
|
||||
Le réseau WAN permettra de faire le lien entre l'extérieur, les pare-feux et les hyperviseurs.
|
||||
|
||||
## Réseau Interne
|
||||
|
||||
Le réseau interne sera séparé en 5 zones privées.
|
||||
Le réseau interne sera séparé en 5 zones privées :
|
||||
|
||||
- DMZ qui sera située juste après le firewall et qui contiendra les loadbalancer (HAProxy) et le serveur DNS.
|
||||
- DMZ qui sera située juste après le firewall et qui contiendra les loadbalanceurs (HAProxy) et le serveur DNS.
|
||||
|
||||
- PROXY qui sera placé juste après la DMZ et qui contiendra les reverses proxy pour les services autres que les environnements CTF ainqi qu'une Mail Gateway pour faire un relai entre l'extérieur et le serveur mail. Ce relai permettra de filtré les mails.
|
||||
- PROXY qui sera placée juste après la DMZ et qui contiendra les reverses proxy pour les services autres que les environnements CTF ainsi qu'une Mail Gateway pour faire un relai entre l'extérieur et le serveur mail. Ce relai permettra de filtrer les mails.
|
||||
|
||||
- INT qui contiendra les containers des services permanents. La liaison entre INT et PROXY se fera à travers les reverses proxy NGINX et la Mail Gateway.
|
||||
- INT qui contiendra les containers des services permanents. La liaison entre INT et PROXY se fera à travers les reverse proxy NGINX et la Mail Gateway.
|
||||
|
||||
- CTF qui sera la zone dédiée au reverse proxy CTF et aux containers/VMs des environnements CTF. Le lien avec l'extérieur se ferra directement au niveau de la DMZ via HAProxy.
|
||||
- CTF qui sera la zone dédiée au reverse proxy CTF et aux containers/VMs des environnements CTF. Le lien avec l'extérieur se fera directement au niveau de la DMZ via HAProxy.
|
||||
|
||||
- DIRTY qui contiendra les containers des services en test
|
||||
- DIRTY qui contiendra les containers des services en test.
|
||||
|
||||
Les requêtes arriveront sur le pare-feu qui effectura un premier filtrage et transmettra les requêtes sur les ports 80 et 443 à un des loadbalancer, c'est le loadbalancer qui décidera ensuite si la requête sera retransmise à l'un des reverses de la zone INT ou au reverse de la zone CTF.
|
||||
Les requêtes arriveront sur le pare-feu qui effectuera un premier filtrage et transmettra les requêtes sur les ports 80 et 443 à un des loadbalanceurs, c'est le loadbalanceur qui décidera ensuite si la requête sera retransmise à l'un des reverse proxy de la zone INT ou au reverse proxy de la zone CTF.
|
||||
|
||||
## Réseau Administation
|
||||
## Réseau Administration
|
||||
|
||||
L'accès au réseau administration se fera grâce à un VPN. Depuis le réseau administration on pourra accéder librement à tout les services hyperviseurs compris. Cela pourra par exemple permettre de mettre en place un système de monitoring.
|
||||
L'accès au réseau administration se fera grâce à un VPN. Depuis le réseau administration, on pourra accéder librement à tous les services hyperviseurs compris. Cela pourra par exemple permettre de mettre en place un système de monitoring.
|
||||
|
||||
De son côté l'accès à l'interface d'administration de Proxmox se fera aussi par la voie classique. En cas de connexion à pve.krhacken.org, HAProxy vérifiera le certificat client et son CN avant de rediriger vers un des deux panels.
|
||||
De son côté, l'accès à l'interface d'administration de Proxmox se fera aussi par la voie classique. En cas de connexion à pve.krhacken.org, HAProxy vérifiera le certificat client et son CN avant de rediriger vers un des deux panels.
|
||||
|
|
|
|||
Loading…
Reference in New Issue