Partie Réseau
Pierre Coimbra
parent
1ce75c1586
commit
556d1a50b1
|
|
@ -28,10 +28,10 @@ charge de former leur successeurs.
|
|||
5. [Haute Disponibilitée](#)
|
||||
6. [Gestion de l'authentification](#)
|
||||
3. [Réseau](reseau)
|
||||
1. [Introduction à OpenvSwitch](#)
|
||||
2. [Topologie du réseau matériel](#)
|
||||
3. [Topologie du réseau virtuel](#)
|
||||
4. [Mise en place du réseau](#)
|
||||
1. [Introduction à OpenvSwitch](reseau/introduction_ovs.md)
|
||||
2. [Topologie du réseau matériel](reseau/topologie_reseau_physique.md)
|
||||
3. [Topologie du réseau virtuel](reseau/topologie_reseau_virtuel.md)
|
||||
4. [Mise en place du réseau](reseau/mise_en_place.md)
|
||||
4. [Applicatif](applicatif)
|
||||
1. [Répartition des services dans les zones](#)
|
||||
2. [Zone WAN](#)
|
||||
|
|
|
|||
|
|
@ -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 copiées 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 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.
|
||||
|
||||
Les 2 nodes du serveurs, que nous appellerons Alpha et Beta, auront Proxmox comme hyperviseur et seront en cluster grâce à Proxmox. Pour plus de détails sur Proxmox ce référer à la partie Proxmox.
|
||||
Les 2 nodes du serveurs, que nous appellerons Alpha et Beta, auront Proxmox comme hyperviseur et seront en cluster grâce à Proxmox.
|
||||
|
||||
### Infrastructure logicielle
|
||||
|
||||
|
|
@ -13,7 +13,7 @@ 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) :
|
||||
- OPNSense qui servira de Firewall de routeur.
|
||||
- HAProxy qui servira de loadbalanceur entre les reverses proxy
|
||||
- HAProxy qui servira de loadbalanceur entre les reverses proxy.
|
||||
- NGINX qui fera office de reverse proxy entre HAProxy et les serveurs web autre que ceux des environnements CTF.
|
||||
- Uniquement sur Beta, un reverse proxy NGINX qui servira de reverse proxy entre HAProxy et l'environnement CTF.
|
||||
|
||||
|
|
@ -36,7 +36,7 @@ L'objectif est de remplacer la banque de challenge du club stockée actuellement
|
|||
|
||||
L'infrastructure CTF du club s'organisera de la manière suivante :
|
||||
- Un premier CTFd avec tous les challenges actuels 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 ou il n'y a ni classement ni challenge récurrent.
|
||||
- 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.
|
||||
|
||||
|
|
@ -44,6 +44,6 @@ L'infrastructure CTF du club s'organisera de la manière suivante :
|
|||
|
||||
Pour la gestion en interne du serveur, nous nous organiserions de la manière suivante,
|
||||
|
||||
- Seulement deux personnes du bureau auront un accès total au serveur pour éviter tout problème d'administration. Les accès seront logés et les comptes nominatifs.
|
||||
- Pour ce qui est de l'accès aux services web, tous les membres actifs du club y auront accès, mais seul le responsable technique et les personnes s'occupant du serveur auront les droits d'administration.
|
||||
- Pour ce qui est de l'accès aux services CTF, seulement les responsables événements, technique et serveur y auront accès en tant qu'administrateurs, toutes les personnes participant à l'événement auront un accès à l'interface utilisateur du CTF, les accès à cette interface seront loggés.
|
||||
- Seulement deux personnes du bureau auront le rôle d'administrateur système soit un accès total au serveur. Limiter le nombre d'administrateur système permet d'éviter tout problème d'administration.
|
||||
- Le responsable technique aura le rôle du webmestre c'est à dire qu'il pourra intervenir sur les services comme le site web, le cloud... Cependant il ne pourra pas toucher à l'infrastructure réseau.
|
||||
- Pour ce qui est de l'accès aux services web, tous les membres actifs du club y auront accès.
|
||||
|
|
|
|||
|
|
@ -1 +1,8 @@
|
|||
# Réseau
|
||||
Vous trouverez ici toute la documentation relative à l'infrastructure réseau.
|
||||
|
||||
# Table des matières
|
||||
1. [Introduction à OpenvSwitch](introduction_ovs.md)
|
||||
2. [Topologie du réseau matériel](topologie_reseau_physique.md)
|
||||
3. [Topologie du réseau virtuel](topologie_reseau_virtuel.md)
|
||||
4. [Mise en place du réseau](mise_en_place.md)
|
||||
|
|
|
|||
|
|
@ -0,0 +1,10 @@
|
|||
# Introduction à 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.
|
||||
|
||||
Explication rapide du fonctionnement global d'OpenvSwitch,
|
||||
- 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.
|
||||
|
|
@ -1,67 +1,11 @@
|
|||
# Réseau
|
||||
|
||||
Chacune des nodes possède 4 interfaces réseau, pour des questions de redondance et de débit nous allons mettre 2 de ces interfaces en bond pour le réseau interne et la communication entre les deux serveurs.
|
||||
|
||||
- eth0 sur une interface simple utilisé uniquement par OPNSense via wan
|
||||
- eth2 formera le bridge OVS admin
|
||||
- eth1 et eth3 formerons le bond OVS bond0 sur le bridge OVS interne
|
||||
|
||||
Pour la gestion des bonds, vlans... nous utiliserons openvswitch
|
||||
|
||||
Explication rapide du fonctionnement global d'OpenvSwitch,
|
||||
|
||||
- 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 VXLAN ou un tunnel GRE. Pour notre usage le bridge n'aura pas d'IP sur l'hôte.
|
||||
- OVS Bond, permet d'attache 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 pour avoir une IP et éventuellement une VLAN.
|
||||
|
||||
|
||||
Pour chacune des zones (KRKN ou CTF) il y a deux types de VM/CT,
|
||||
|
||||
- Ceux qui sont directement accessible depuis internet derrière OPNSense c'est les services frontend.
|
||||
- Ceux qui sont accessible uniquement à travers une frontend c'est les services backend.
|
||||
|
||||
## Les switchs virtuel
|
||||
|
||||
- Un switch physique sur lequel sera branché les quatres interfaces des nodes et l'entité de quorum.
|
||||
- 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
|
||||
|
||||
Tout les hyperviseurs auront une pâte sur le VLAN 100 sur chaque switch pour le protocole GRE qui permet l'échange entre les switchs virtuel de chaque nodes.
|
||||
|
||||
## 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.
|
||||
|
||||
Tout ces CT auront obligatoirement une pâte sur la VLAN 10 et une VLAN backend du switch Interne.
|
||||
|
||||
## Services 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,
|
||||
- ROUTE sur la VLAN 20 qui contiendra les reverses proxy public,
|
||||
- KRKN 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.
|
||||
|
||||
## Partie Internet
|
||||
|
||||
Tout les containers et les VM Backend auront accès à internet via le proxy interne (en frontend). Pour cela ils auront tous une pâte sur la VLAN 80 du switch interne.
|
||||
|
||||
## Partie Administration
|
||||
|
||||
- Chaque hyperviseur ainsi que l'entité de Quorum aura une pâte sur la VLAN 10 du switch Administration pour le fonctionnement de Corosync.
|
||||
- Toutes les VM, tout les CT, les hyperviseurs et l'entité de Quorum auront une pâte sur la VLAN 20 du switch Administration pour les tâches d'administration via le VPN ou localement en cas d'urgence.
|
||||
- Chaque hyperviseur aura une pâte sur la VLAN 30 su switch Administration pour pfSync (HA du Firewall).
|
||||
|
||||
# Mise en place du Réseau
|
||||
Nous allons ici détaillé la configuration du réseau physique et virtuel. Il est préférable de lire la documentation sur leur topologie au préalable.
|
||||
|
||||
## Map des IPs principales.
|
||||
|
||||
Voilà les IPs attribuées aux services principaux qu'il faut impérativement respecter.
|
||||
### FrontEnd (Juste après le FW)
|
||||
- Firewall Alpha : 10.0.0.1
|
||||
- Firewall Bêta : 10.0.0.2
|
||||
- Firewall Beta : 10.0.0.2
|
||||
- Firewall VIP : 10.0.0.3
|
||||
- HAProxy Alpha : 10.0.0.4
|
||||
- HAProxy Beta : 10.0.0.5
|
||||
|
|
@ -69,14 +13,13 @@ Tout les containers et les VM Backend auront accès à internet via le proxy int
|
|||
- Proxy Interne : 10.0.0.7
|
||||
- Mail : 10.0.0.10
|
||||
|
||||
### ROUTE (Juste après la frontend)
|
||||
### PROXY (Juste après la frontend)
|
||||
- HAProxy Alpha : 10.0.1.1
|
||||
- HAProxy Beta : 10.0.1.2
|
||||
- Nginx Public Alpha : 10.0.1.3
|
||||
- Nginx Public Beta : 10.0.1.4
|
||||
|
||||
|
||||
### KRKN
|
||||
### INT
|
||||
- LDAP Alpha : 10.0.2.1
|
||||
- LDAP Bêta : 10.0.2.2
|
||||
- LDAP VIP : 10.0.2.3
|
||||
|
|
@ -84,7 +27,6 @@ Tout les containers et les VM Backend auront accès à internet via le proxy int
|
|||
- Nginx Public Beta : 10.0.2.5
|
||||
- [...] Voir DNS
|
||||
|
||||
|
||||
### CTF :
|
||||
- HAProxy Alpha : 10.0.3.1
|
||||
- HAProxy Beta : 10.0.3.2
|
||||
|
|
@ -119,6 +61,20 @@ Tout les containers et les VM Backend auront accès à internet via le proxy int
|
|||
- [...] Voir DNS
|
||||
|
||||
|
||||
# Réseau physique
|
||||
|
||||
La configuration et les branchement à faire sur le switch sera détaillé plus tard.
|
||||
|
||||
# Réseau virtuel
|
||||
Cette partie consiste à mettre en place OpenvSwitch sur les deux nodes.
|
||||
|
||||
## Installation
|
||||
Commune aux deux nodes
|
||||
```
|
||||
apt-get update
|
||||
apt-get install openvswitch-switch
|
||||
```
|
||||
|
||||
## Configuration de OpenvSwitch
|
||||
|
||||
### Pour Alpha (/etc/network/interfaces)
|
||||
|
|
@ -168,7 +124,7 @@ iface interne inet manual
|
|||
up ovs-vsctl --may-exist add-port interne gre1 -- set interface gre1 type=gre options:remote_ip='10.0.4.2'
|
||||
down ovs-vsctl --if-exists del-port interne gre1
|
||||
|
||||
|
||||
|
||||
#Admin Task
|
||||
allow-admin admintask
|
||||
iface admintask inet static
|
||||
|
|
@ -262,7 +218,7 @@ iface interne inet manual
|
|||
up ovs-vsctl --may-exist add-port interne gre1 -- set interface gre1 type=gre options:remote_ip='10.0.4.1'
|
||||
down ovs-vsctl --if-exists del-port interne gre1
|
||||
|
||||
|
||||
|
||||
#Admin Task
|
||||
allow-admin coro
|
||||
iface coro inet static
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 69 KiB |
|
|
@ -1,23 +1,22 @@
|
|||
# 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.
|
||||
|
||||
## Pour les connexions à la partie utilisateur
|
||||
## Réseau Interne
|
||||
|
||||
Le réseau local sera séparé en 3 zones privées.
|
||||
Le réseau interne sera séparé en 4 zones privées.
|
||||
|
||||
- ROUTE qui sera la DMZ situé juste après le firewall et qui contiendra les loadbalancer (HAProxy) et les reverse proxy public (NGINX).
|
||||
- DMZ qui sera située juste après le firewall et qui contiendra les loadbalancer (HAProxy) et le serveur DNS.
|
||||
|
||||
- KRKN qui contiendra les containers des services public et club la liaison entre KRKN et ROUTE se fera à travers les reverses proxy NGINX.
|
||||
- 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.
|
||||
|
||||
- CTF qui sera la zone dédiée au reverse proxy CTF et aux containers/VMs des environnements CTF.
|
||||
- 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.
|
||||
|
||||
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 KRKN ou au reverse de la zone CTF.
|
||||
- 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.
|
||||
|
||||
## Pour les connexions à la partie administration
|
||||
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.
|
||||
|
||||
L'accès à l'interface d'administration de Proxmox se fera 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.
|
||||
## Réseau Administation
|
||||
|
||||
L'accès au port 8006 (port par défaut de l'UI Proxmox) et au port 22 se fera par un VPN qui sera géré par le pare feu (OPNSense) sur la zone ADMIN.
|
||||
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.
|
||||
|
||||
Voilà un schéma (très simplifié) de la topologie globale du réseau (user et admin)
|
||||
|
||||
|
||||
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.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,9 @@
|
|||
# Topologie du réseau physique
|
||||
|
||||
Chacune des nodes possède 4 interfaces réseau, pour des questions de redondance et de débit nous allons mettre 2 de ces interfaces en bond pour le réseau interne et la communication entre les deux serveurs. Les deux interfaces restantes seront utilisées pour l'accès à internet et pour le réseau d'administration.
|
||||
|
||||
- eth0 sur une interface simple utilisé uniquement par OPNSense via WAN
|
||||
- eth2 formera le bridge OVS ADMIN
|
||||
- eth1 et eth3 formerons le bond OVS bond0 sur le bridge OVS interne
|
||||
|
||||
Pour faire communiquer entre elles les deux nodes il y aura un switch physique sur lequel sera branché les quatres interfaces des nodes et l'entité de quorum.
|
||||
|
|
@ -0,0 +1,46 @@
|
|||
# Topologie du réseau virtuel
|
||||
|
||||
Rappel:
|
||||
- eth0 sur un bridge OVS (WAN) accessible uniquement par OPNSense
|
||||
- eth2 formera le bridge OVS Admin
|
||||
- eth1 et eth3 formerons le bond OVS bond0 sur le bridge OVS Interne
|
||||
|
||||
Pour chacune des zones (INT ou CTF) il y a deux types de VM/CT,
|
||||
|
||||
- Ceux qui sont directement accessible depuis internet derrière OPNSense c'est les services frontend.
|
||||
- Ceux qui sont accessible uniquement à travers une frontend c'est les services backend.
|
||||
|
||||
## Les switchs virtuel
|
||||
|
||||
- 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
|
||||
|
||||
Tout les hyperviseurs auront une pâte sur le VLAN 100 sur chaque switch pour le protocole GRE qui permet l'échange entre les switchs virtuel de chaque nodes.
|
||||
|
||||
## 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.
|
||||
|
||||
Tout ces CT auront obligatoirement une pâte sur la VLAN 10 et une VLAN backend du switch Interne.
|
||||
|
||||
## Services 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,
|
||||
- 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.
|
||||
|
||||
## Partie Internet
|
||||
|
||||
Tout les containers et les VM Backend auront accès à internet via le proxy interne (en frontend). Pour cela ils auront tous une pâte sur la VLAN 80 du switch interne.
|
||||
|
||||
## Partie Administration
|
||||
|
||||
- Chaque hyperviseur ainsi que l'entité de Quorum aura une pâte sur la VLAN 10 du switch Administration pour le fonctionnement de Corosync.
|
||||
- Toutes les VM, tout les CT, les hyperviseurs et l'entité de Quorum auront une pâte sur la VLAN 20 du switch Administration pour les tâches d'administration via le VPN ou localement en cas d'urgence.
|
||||
- Chaque hyperviseur aura une pâte sur la VLAN 30 su switch Administration pour pfSync (HA du Firewall).
|
||||
Loading…
Reference in New Issue