coimbrap
/
projet_serveur_krkn
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Restructuration et vulgarisation

master
Pierre Coimbra 2020-02-21 14:54:26 +01:00
parent aa86186014
commit a2b0df16d8
No known key found for this signature in database
GPG Key ID: F9C449C78F6FAEE6
19 changed files with 218 additions and 46 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
applicatif/README.md
View File

@ -1,10 +1,10 @@
# 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.
1. [Répartition des services dans les zones](#)
2. [Zone WAN](#)
3. [Zone DMZ](#)
4. [Zone Proxy](#)
5. [Zone Interne](#)
6. [Zone CTF](#)
7. [Zone "Sale"](#)
# Table des matières
1. [Répartition des services dans les zones](repartition_en_zones.md)
2. [Zone WAN](zone_wan/README.md)
3. [Zone DMZ](zone_dmz/README.md)
4. [Zone Proxy](zone_proxy/README.md)
5. [Zone Interne](zone_interne/README.md)
6. [Zone CTF](zone_ctf/README.md)

90
applicatif/repartition_en_zones.md Normal file
View File

@ -0,0 +1,90 @@
# 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.
## Services Frontend
Les services Frontend sont directement accessible 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
- Bridge WAN VLAN 10 (WAN)
- Bridge Admin VLAN 100 (ADMIN)
Pour OPNSense
- Bridge Interne VLAN 10 (DMZ)
### Zone DMZ
Cette zone regroupe les services qui nécessite 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
- Bridge Interne VLAN 10 (DMZ)
- Bridge Admin VLAN 100 (ADMIN)
Pour HAProxy
- Bridge Interne VLAN 20 (PROXY)
- Bridge Interne VLAN 40 (CTF)
Pour Bind9
- Bridge Interne VLAN 20 (PROXY)
- Bridge Interne VLAN 30 (INT)
- Bridge Interne VLAN 40 (CTF)
Pour Squid
- Bridge Interne VLAN 20 (PROXY)
- Bridge Interne VLAN 30 (INT)
- Bridge Interne VLAN 40 (CTF)
- Bridge Interne VLAN 50 (EXT)
## 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.
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
- 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.
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.
- 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...).
Les services de la zone INT devront avoir les interfaces réseau suivante
- 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
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.
- CTFd qui servira d'interface utilisateur pour les CTF.
Les services de la zone CTF devront avoir les interfaces réseau suivante
- 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.
Les services de la zone DIRTY devront avoir les interfaces réseau suivante
- Bridge Interne VLAN 50 (DIRTY)
- Bridge Admin VLAN 100 (ADMIN)

17
applicatif/zone_ctf/README.md
View File

@ -1,2 +1,15 @@
# Présentation de la zone CTF
Vous trouverez ici toute la documentation relative au fonctionnement et à la configuration de la zone CTF. Cela comprend le reverse proxy CTF, l'environnement Web, l'environnement Système et CTFd.
# Zone CTF
Vous trouverez ici toute la documentation relative au fonctionnement et à la configuration de la zone CTF.
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
- Bridge Interne VLAN 40 (CTF)
- Bridge Admin VLAN 100 (ADMIN)
# Table des matières
1. [Reverse Proxy NGINX](nginx_ctf.md)
2. [Environnment Web](environnement_web.md)
3. [Environnment Système](environnement_systeme.md)
4. [CTFd](#)

29
applicatif/zone_dmz/README.md Normal file
View File

@ -0,0 +1,29 @@
# Zone DMZ
Vous trouverez ici toute la documentation relative au fonctionnement et à la configuration de la DMZ.
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
- Bridge Interne VLAN 10 (DMZ)
- Bridge Admin VLAN 100 (ADMIN)
Pour HAProxy
- Bridge Interne VLAN 20 (PROXY)
- Bridge Interne VLAN 40 (CTF)
Pour Bind9
- Bridge Interne VLAN 20 (PROXY)
- Bridge Interne VLAN 30 (INT)
- Bridge Interne VLAN 40 (CTF)
Pour Squid
- Bridge Interne VLAN 20 (PROXY)
- Bridge Interne VLAN 30 (INT)
- Bridge Interne VLAN 40 (CTF)
- Bridge Interne VLAN 50 (EXT)
# Table des matières
1. [HAProxy](haproxy.md)
2. [Serveur DNS](#)
3. [Proxy pour les contenants](#)

32
applicatif/zone_route/haproxy.md → applicatif/zone_dmz/haproxy.md
View File

@ -1,8 +1,8 @@
# Gestion du flux post-firewall
## Présentation des containers
Deux containers Debian 10 identiques, un sur Alpha l'autre sur Bêta avec deux interfaces
Deux containers Debian 10 identiques, un sur Alpha l'autre sur Bêta avec deux interfaces
- Sur Alpha le container HAProxy a comme IP 10.0.0.3/24 sur ROUTE (eth0) 10.0.1.3/24 sur CTF (eth1)
- Sur Beta le container HAProxy a comme IP 10.0.0.4/24 sur ROUTE 10.0.1.4/24 sur CTF
L'option Firewall PVE des interfaces est désactivée
@ -19,7 +19,7 @@ Trois objectifs pour la gestion du flux post-firewall
Voici les choix techniques faits afin de répondre à ces objectifs
- Pour le load balancing entre les deux reverse proxy Nginx, on utilisera HAProxy.Le lien sécurisé sera entre l'utilisateur de HAProxy qui soumettra ensuite des requêtes HTTP à un des reverse proxy Nginx.
- Pour la redondance du proxy entre les deux nodes, on utilisera keepalived et la technologie VRRP pour garantir la disponibilité du proxy via une ip virtuelle.
- Pour la redondance du proxy entre les deux nodes, on utilisera keepalived et la technologie VRRP pour garantir la disponibilité du proxy via une ip virtuelle.
- Pour la vérification du certificat client - uniquement si le client veut se connecter au panel Proxmox- on fera une première frontend à la couche 4 (TCP) pour les connexions https qui rediregera les connexions vers le panel sur une frontend dédié et le reste vers une frontend par défaut.
- Pour les certificats SSL, nous allons utiliser Let's Encrypt avec un serveur Nginx local dédié à l'obtention des certificats et des scripts pour le dépoiement sur les deux containers HAProxy.
- La séparation des flux entre les deux reverse public et le reverse ctf ce fera au niveau de la seconde frontend par défaut tout comme le filtrage des requêtes par nom de domaine.
@ -74,13 +74,13 @@ systemctl enable nginx
```
Pour la vérification du certificat du client, la méthode est dans la git. Il faut placer le ca.crt dans /home/hasync/pve.crt et ajouter le CN autorisé dans /home/hasync/allowed_cn.txt
### Configuration
### Configuration
Voilà une rapide explication de la configuration faite
- Une première frontend (all-web-in) de type TCP en écoute sur le port 443 qui vérifie si les requêtes tcp sont bien SSL et redirige tout vers la frontend principale via un proxy sauf les requêtes vers la panel Proxmox qui sont redirigées vers la frontend admin via un proxy.
- La frontend principale (user-web-in) de type http écoute sur le ports 80 et le proxy évoqué plus haut. Filtrage des requêtes ne respectant pas le nom de domaine et forçage du https sans www sinon rejet du packet. Redirection des requêtes Let's Encrypt vers un serveur Nginx local dédié aux certifications sinon séparation du flux avec d'un côté une backend s'occupant du load balancing entre les deux reverse proxy Nginx public et de l'autre une backend redirigeant vers le reverse proxy ctf à l'aide du nom de domaine.
- La frontend principale (user-web-in) de type http écoute sur le ports 80 et le proxy évoqué plus haut. Filtrage des requêtes ne respectant pas le nom de domaine et forçage du https sans www sinon rejet du packet. Redirection des requêtes Let's Encrypt vers un serveur Nginx local dédié aux certifications sinon séparation du flux avec d'un côté une backend s'occupant du load balancing entre les deux reverse proxy Nginx public et de l'autre une backend redirigeant vers le reverse proxy ctf à l'aide du nom de domaine.
#### /etc/haproxy/haproxy.cfg
#### /etc/haproxy/haproxy.cfg
```
global
log /dev/log local0
@ -119,7 +119,7 @@ frontend all-web-in
use_backend is-admin if { req_ssl_sni -i pve.sessionkrkn.fr }
use_backend is-admin if { req_ssl_sni -i rspamd.sessionkrkn.fr }
default_backend is-user
frontend user-web-in
mode http
bind *:80 interface eth0
@ -138,7 +138,7 @@ frontend user-web-in
redirect scheme https code 301 if !{ ssl_fc } authorized_host !host_letsencrypt !mail
use_backend nginx-ctf if ctf_host !host_letsencrypt !mail
use_backend letsencrypt if host_letsencrypt !mail
use_backend letsencrypt if host_letsencrypt !mail
use_backend reverse-nginx if authorized_host !ctf_host OR mail
default_backend drop-http
@ -151,11 +151,11 @@ frontend admin-in
use_backend reverse-nginx if { ssl_fc_has_crt } is_auth rspamd
use_backend pve-interface if { ssl_fc_has_crt } is_auth pve
default_backend drop-http
backend is-admin
mode tcp
server admin-in abns@haproxy-admin send-proxy-v2
backend is-user
mode tcp
server admin-in abns@haproxy-user send-proxy-v2
@ -209,7 +209,7 @@ server {
systemctl restart nginx.service
systemctl restart haproxy.service
```
### Obtention des premiers certificats et déploiement
### Obtention des premiers certificats et déploiement
```
certbot certonly --webroot -w /home/hasync/letsencrypt-requests/ -d sub.sessionkrkn.fr
```
@ -219,7 +219,7 @@ Voici un script pour mettre en place les certificats Let's Encrypt au bon endroi
#!/bin/bash
rm -f /etc/letsencrypt/live/README
rm -rf /etc/ssl/letsencrypt/*
for domain in $(ls /etc/letsencrypt/live); do
for domain in $(ls /etc/letsencrypt/live); do
cat /etc/letsencrypt/live/$domain/privkey.pem /etc/letsencrypt/live/$domain/fullchain.pem > /etc/ssl/letsencrypt/$domain.pem
done
scp -r /etc/ssl/letsencrypt/* root@10.0.0.3:/etc/ssl/letsencrypt
@ -252,7 +252,7 @@ vrrp_script chk_haproxy {
interval 2
weight 2
}
vrrp_instance VI_1 {
interface eth0
state MASTER
@ -276,7 +276,7 @@ vrrp_script chk_haproxy {
interval 2
weight 2
}
vrrp_instance VI_1 {
interface eth0
state MASTER
@ -308,7 +308,7 @@ Voilà un script d'automatisation à mettre sur les deux containers
if [ "$(ip a | grep -c "10.0.0.5")" -ge 1 ]; then
certbot renew
rm -rf /etc/ssl/letsencrypt/*
for domain in $(ls /etc/letsencrypt/live); do
for domain in $(ls /etc/letsencrypt/live); do
cat /etc/letsencrypt/live/$domain/privkey.pem /etc/letsencrypt/live/$domain/fullchain.pem > /etc/ssl/letsencrypt/$domain.pem
done
scp -r /etc/ssl/letsencrypt/* hasync@<ip_autre_ct>:/etc/ssl/letsencrypt
@ -320,4 +320,4 @@ Le script est stocké dans /home/hasync/renew.sh, voici la crontab à ajouter (c
0 4 */15 * * /bin/sh /home/hasync/renew.sh >/dev/null 2>&1
```
C'est tout pour la configuration de HAProxy, la prochaine étape est la mise en place des trois reverses proxy.
C'est tout pour la configuration de HAProxy, la prochaine étape est la mise en place des trois reverses proxy.

0
applicatif/zone_route/schema_route.png → applicatif/zone_dmz/schema_route.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 143 KiB

After

Width:  |  Height:  |  Size: 143 KiB

14
applicatif/zone_interne/README.md Normal file
View File

@ -0,0 +1,14 @@
# 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.
## Réseau
Les services de la zone PROXY devront avoir les interfaces réseau suivante
- Bridge Interne VLAN 20 (PROXY)
- Bridge Interne VLAN 30 (INT)
- Bridge Admin VLAN 100 (ADMIN)
# Table des matières
1. [LDAP](ldap.md)
2. [Serveur Mail](mail.md)

0
applicatif/zone_krkn/ldap.md → applicatif/zone_interne/ldap.md
View File

0
applicatif/zone_krkn/mail.md → applicatif/zone_interne/mail.md
View File

2
applicatif/zone_krkn/README.md
View File

@ -1,2 +0,0 @@
# Présentation de la zone KRKN
Vous trouverez ici toute la documentation relative au fonctionnement et à la configuration de la zone KRKN. Cela comprend tous les containers des services publics (Nextcloud, Gitea...) et les services internes nécessaires au fonctionnement des services publics comme l'annuaire LDAP.

14
applicatif/zone_proxy/README.md Normal file
View File

@ -0,0 +1,14 @@
# Zone PROXY
Vous trouverez ici toute la documentation relative au fonctionnement et à la configuration applicative des services de la zone PROXY.
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
- Bridge Interne VLAN 20 (PROXY)
- Bridge Interne VLAN 30 (INT)
- Bridge Admin VLAN 100 (ADMIN)
# Table des matières
1. [Reverse Proxy NGINX](nginx_principal.md)
2. [Relais mails](#)

0
applicatif/zone_route/nginx_public.md → applicatif/zone_proxy/nginx_principal.md
View File

2
applicatif/zone_route/README.md
View File

@ -1,2 +0,0 @@
# Présentation de la zone ROUTE
Vous trouverez ici toute la documentation relative au fonctionnement et à la configuration de la zone ROUTE. Cela comprend les deux HAProxy et les deux reverses proxy public nginx.

12
applicatif/zone_wan/README.md Normal file
View File

@ -0,0 +1,12 @@
# Zone WAN
Vous trouverez ici toute la documentation relative au fonctionnement et à la configuration applicative des services de la zone WAN.
Cela comprend les pare-feu et les hyperviseurs. C'est cette zone qui aura un accès direct à l'extérieur.
## Réseau
Les services DMZ devront avoir les interfaces réseau suivante
- Bridge WAN VLAN 10 (WAN)
- Bridge Admin VLAN 100 (ADMIN)
Pour OPNSense
- Bridge Interne VLAN 10 (DMZ)

3
proxmox/README.md
View File

@ -1,7 +1,8 @@
# Documentation de l'installation Proxmox
Vous trouverez ici toute la documentation relative au déploiement de Proxmox.
1. [Introduction à la virtualisation](#)
# Table des matières
1. [Introduction à la virtualisation](introduction_a_la_virtualisation.md)
2. [Installation des hyperviseurs](#)
3. [Systèmes de fichiers et sauvegardes](#)
4. [Cluster](#)

3
proxmox/cluster/README.md
View File

@ -1,3 +0,0 @@
# Mise en place du cluster
Vous trouverez ici toute la documentation relative à la mise en place du multicast pour le corosync, du cluster Proxmox et de l'instance de quorum.

13
proxmox/introduction_a_la_virtualisation.md
View File

@ -1,22 +1,21 @@
# 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 »). Pour faire simple c’est une plateforme de virtualisation directement installé sur le serveur.
Contrairement à un hyperviseur de type 2 (VirtualBox par exemple), celui-ci n’exécute pas dans un autre OS. Il 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 adapté à la virtualisation.
Donc proxmox permet la virtualisation de plusieurs machine au sein d’un seul serveur. Il est aussi possible de monter deux ou plus serveur en cluster.
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.
## 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érer 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.
- 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.
Pour notre infrastructure nous utiliserons dès que possible des containers LXC. Cependant pour les environnements CTF nécessitant Docker et pour OPNSense nous utiliserons des VMs KVM.
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.
## Qualité de Proxmox
Voilà un petit aperçu des fonctionnalité 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.

8
reseau/topologie_globale.md
View File

@ -1,9 +1,13 @@
# 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.
## Réseau WAN
Le réseau WAN permettra de faire le lien entre l'extérieur, les pare-feu et les hyperviseurs.
## Réseau Interne
Le réseau interne sera séparé en 4 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.
@ -13,6 +17,8 @@ Le réseau interne sera séparé en 4 zones privées.
- 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.
- 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.
## Réseau Administation

11
reseau/topologie_reseau_virtuel.md
View File

@ -12,7 +12,8 @@ Pour chacune des zones (INT ou CTF) il y a deux types de VM/CT,
## Les switchs virtuel
- Un switch Administation pour toute les tâches d'administration avec comme lien extérieur eth2
- Un switch WAN pour le lien entre l'extérieur, les pares-feu et les hyperviseurs avec comme lien extérieur eth0.
- Un switch Administation pour toute les tâches d'administration avec comme lien extérieur eth2.
- Un switch Interne qui devra gérer, avec des VLANs, l'accès (filtré) à internet des services qui ne sont pas directement derrière le FW (Nextcloud, Git, Serveur Web...) en séparant le tout en plusieurs zones et les services qui sont directement derrière le FW (HAProxy, Proxy des services, Mail et DNS). Avec comme lien extérieur un bond entre eth1 et eth3.
## Communication des switchs entre les nodes
@ -21,7 +22,7 @@ Tout les hyperviseurs auront une pâte sur le VLAN 100 sur chaque switch pour le
## Services Frontend
Concrètement les containers concernés auront des ports d'entrée DNAT vers eux ce qui signifie qu'ils seront accessible depuis internet à travers le firewall. C'est le cas de HAProxy, des Mails, du serveur DNS et du Proxy des services.
Concrètement les containers concernés auront des ports d'entrée DNAT vers eux ce qui signifie qu'ils seront accessible depuis internet à travers le firewall. C'est le cas de HAProxy, du serveur DNS et du Proxy des services.
Tout ces CT auront obligatoirement une pâte sur la VLAN 10 et une VLAN backend du switch Interne.
@ -29,11 +30,11 @@ Tout ces CT auront obligatoirement une pâte sur la VLAN 10 et une VLAN backend
Les containers ou VMs concerné ne seront pas accessible depuis internet cependant certain seront accessible par l'intermédiaire de HAProxy (entre autres).
Cette parti sera découpé en plusieures zones,
- PROXY sur la VLAN 20 qui contiendra les reverses proxy public,
Cette parti sera découpé en plusieurs zones,
- PROXY sur la VLAN 20 qui contiendra les reverses proxy public et le relais mail,
- INT sur la VLAN 30 qui contiendra tout les services de la partie krhacken,
- CTF sur la VLAN 40 qui contiendra le reverse proxy CTF et les environnement CTF,
- EXT sur la VLAN 50 qui contiendra les environnement de test.
- DIRTY sur la VLAN 50 qui contiendra les environnement de test.
## Partie Internet