master
Pierre Coimbra 2019-10-28 17:25:36 +01:00
parent 85cff090cc
commit f368b61e12
13 changed files with 107 additions and 114 deletions

View File

@ -1,2 +1,2 @@
# Documentation du réseau de Kr[HACK]en
Vous trouverez ici toute la documentation relative à la mise configuration des interfaces réseau, du firewall. Ainsi que le schéma global de l'infrastructure réseau.
Vous trouverez ici toute la documentation relative à la configuration des interfaces réseau, du firewall ainsi que le schéma global de l'infrastructure réseau.

View File

@ -43,4 +43,4 @@ XX X | Firewal
+--------------------------------------------------------------------------------------------------------------------------------+
Canal de communication
entre les deux hyperviseur
entre les deux hyperviseurs

View File

@ -1,3 +1,2 @@
# Configuration des interfaces
Vous trouverez ici toute la documentation relative à la configuration des interfaces de chaqu'une des nodes.
Vous trouverez ici toute la documentation relative à la configuration des interfaces de chacune des nodes.

View File

@ -1,9 +1,9 @@
# Mise en place des interfaces de Alpha
Nous allons ici mettre en place toutes les interfaces de Alpha à l'exception du bridge entre Alpha et Beta et du multicast pour le corosync qui utiliserons respectivement _eth1_ et _eth2_
Ici, nous allons mettre en place toutes les interfaces de Alpha à l'exception du bridge entre Alpha et Beta et du multicast pour le corosync qui utiliseront respectivement _eth1_ et _eth2_
## Configuration des interfaces
Nous disposons de deux cartes réseau avec chaqu'une deux ports ethernet. Nous allons utiliser ici _eth0_ qui sera l'interface relié à internet.
Nous disposons de deux cartes réseau avec chacune deux ports ethernet. Nous allons utiliser ici _eth0_ qui sera l'interface reliée à internet.
### /etc/network/interfaces
```
@ -41,4 +41,4 @@ iface vmbr2 inet static
post-up echo 1 > /proc/sys/net/ipv4/ip_forward
```
Nous avons configuré les interfaces de Alpha. _vmbr0_ est un bridge sur _eth0_ et _vmbr1_ et _vmbr2_ sont des interfaces virtuelles géré avec shorewall.
Nous avons configuré les interfaces de Alpha. _vmbr0_ est un bridge sur _eth0_ et _vmbr1_ et _vmbr2_ sont des interfaces virtuelles gérées avec shorewall.

View File

@ -1,6 +1,6 @@
# Mise en place des interfaces de Beta
Nous allons ici mettre en place toutes les interfaces de Beta à l'exception du bridge entre Alpha et Beta et du multicast pour le corosync qui utiliserons respectivement _eth0_ et _eth2_.
Ici, nous allons mettre en place toutes les interfaces de Beta à l'exception du bridge entre Alpha et Beta et du multicast pour le corosync qui utiliseront respectivement _eth0_ et _eth2_.
## Configuration des interfaces
Nous allons seulement mettre en place des interfaces virtuelles.
@ -29,4 +29,4 @@ iface vmbr2 inet static
post-up echo 1 > /proc/sys/net/ipv4/ip_forward
```
Nous avons configuré les interfaces de Beta. _vmbr1_ et _vmbr2_ sont des interfaces virtuelles géré avec shorewall.
Nous avons configuré les interfaces de Beta. _vmbr1_ et _vmbr2_ sont des interfaces virtuelles gérées avec shorewall.

View File

@ -1,6 +1,6 @@
# Mise en place d'un bridge de Alpha à Beta pour l'accès à internet
Nous allons ici mettre en place un bridge entre Alpha et Beta. Seul Alpha disposera d'une IP publique et d'un accès à internet. Alpha joura le rôle de routeur en fournissant à Beta un accès à internet à travers son firewall.
Ici, nous allons mettre en place un bridge entre Alpha et Beta. Seul Alpha disposera d'une IP publique et d'un accès à internet. Alpha jouera le rôle de routeur en fournissant à Beta un accès à internet à travers son firewall.
## Configuration des interfaces
Nous allons configurer la carte réseau eth1 sur Alpha et eth0 sur Beta pour mettre en place le bridge.
@ -35,7 +35,7 @@ iface vmbr0 inet static
bridge_stp off
bridge_fd 0
post-up echo 1 > /proc/sys/net/ipv4/ip_forward
```
Nous avons maintenant un bridge entre Alpha et Beta. La configuration du firewall pour que le bridge soit opérationnel se trouve dans _infra/shorewall_
Nous avons maintenant un bridge entre Alpha et Beta. La configuration du firewall pour que le bridge soit opérationnel se trouve dans _infra/shorewall_

View File

@ -1,3 +1,2 @@
# Configuration du Firewall
Vous trouverez ici toute la documentation relative à la configuration de Shorewall telle que décrite dans le schéma de l'infrastructure réseau.
Vous trouverez ici toute la documentation relative à la configuration de Shorewall telle que décrite dans le schéma de l'infrastructure réseau.

View File

@ -1,6 +1,6 @@
# Mise en place du firewall de Alpha
Nous avons une interface _eth1_ pour le routage de la connexion avec beta, une interface _eth2_ pour le corosync, une interface virtuelle _vmbr0_ qui bridge sur _eth0_ pour l'accès à internet et deux interfaces virtuelle _vmbr1_ et _vmbr2_ qui ne bridge pas vers l'extérieur, le bridge va se faire avec shorewall.
Nous avons une interface _eth1_ pour le routage de la connexion avec beta, une interface _eth2_ pour le corosync, une interface virtuelle _vmbr0_ qui bridge sur _eth0_ pour l'accès à internet et deux interfaces virtuelles _vmbr1_ et _vmbr2_ qui ne bridgent pas vers l'extérieur, le bridge va se faire avec Shorewall.
## Installation de Shorewall
```
@ -16,31 +16,31 @@ Shorewall est maintenant installé
Garder le fichier d'origine
### /etc/shorewall/interfaces
Associations des interfaces du système avec les zones du parefeu
Associations des interfaces du système avec les zones du pare-feu
```
?FORMAT 2
#ZONE INTERFACE OPTIONS
int eth1 tcpflags,nosmurfs,bridge,logmartians,routefilter
coro eth2 tcpflags,nosmurfs,logmartians
net vmbr0 tcpflags,nosmurfs,bridge,routefilter,logmartians,routeback
krkn vmbr1 tcpflags,nosmurfs,bridge,routefilter,logmartians,routeback
ext vmbr2 tcpflags,nosmurfs,bridge,routefilter,logmartians,routeback
int eth1 tcpflags,nosmurfs,bridge,logmartians,routefilter
coro eth2 tcpflags,nosmurfs,logmartians
net vmbr0 tcpflags,nosmurfs,bridge,routefilter,logmartians,routeback
krkn vmbr1 tcpflags,nosmurfs,bridge,routefilter,logmartians,routeback
ext vmbr2 tcpflags,nosmurfs,bridge,routefilter,logmartians,routeback
```
### /etc/shorewall/policy
Définition de la politique globale du pare-feu
```
#SOURCE DEST POLICY LOGLEVEL
$FW net ACCEPT
$FW int ACCEPT
$FW coro ACCEPT
krkn net ACCEPT
ext net ACCEPT
int net ACCEPT
$FW net ACCEPT
$FW int ACCEPT
$FW coro ACCEPT
krkn net ACCEPT
ext net ACCEPT
int net ACCEPT
ext krkn DROP info
net all DROP info
all all REJECT info
ext krkn DROP info
net all DROP info
all all REJECT info
```
@ -55,38 +55,36 @@ Définition des exceptions aux règles définies dans le fichier policy
?SECTION UNTRACKED
?SECTION NEW
Invalid(DROP) net all tcp
Invalid(DROP) net all tcp
DNS(ACCEPT) $FW net
Ping(ACCEPT) all $FW
Ping(ACCEPT) all $FW
#Connexion SSH vers et depuis Beta et extérieur
SSH(ACCEPT) int $FW
SSH(ACCEPT) net all
SSH(ACCEPT) $FW int
SSH(ACCEPT) int $FW
SSH(ACCEPT) net all
SSH(ACCEPT) $FW int
#Nécessaire pour l'initialisation du corosync
ACCEPT coro $FW icmp
ACCEPT coro $FW icmp
ACCEPT $FW krkn icmp
ACCEPT $FW ext icmp
ACCEPT $FW net icmp
ACCEPT $FW krkn icmp
ACCEPT $FW ext icmp
ACCEPT $FW net icmp
ACCEPT krkn int tcp 80,443
ACCEPT krkn ext tcp 80,443
ACCEPT net $FW tcp 8006
ACCEPT krkn int tcp 80,443
ACCEPT krkn ext tcp 80,443
ACCEPT net $FW tcp 8006
```
### /etc/shorewall/snat
Configuration SNAT permettant de faire du "masquerading", ainsi les paquets qui sortent des CT LXC ont comme IP source, l'IP de l'interface externe _eth0_.
Configuration SNAT permettant de faire du "masquerading", ainsi les paquets qui sortent des containers ont comme IP source l'IP de l'interface externe _eth0_.
```
#ACTION SOURCE DEST
MASQUERADE vmbr1 vmbr0
MASQUERADE vmbr1 eth1
MASQUERADE vmbr2 vmbr0
MASQUERADE eth1 vmbr0
MASQUERADE vmbr1 vmbr0
MASQUERADE vmbr1 eth1
MASQUERADE vmbr2 vmbr0
MASQUERADE eth1 vmbr0
```
### /etc/shorewall/zones
Définition des zones et de leur type.
Définition des zones et de leurs types.
```
#ZONE TYPE
fw firewall
@ -97,4 +95,4 @@ coro ipv4
int ipv4
```
Le firewall de Alpha est maintenant configuré comme décrit dans le shéma global du réseau.
Le firewall de Alpha est maintenant configuré comme décrit dans le schéma global du réseau.

View File

@ -1,6 +1,6 @@
# Mise en place du firewall de Beta
Nous avons une interface _eth2_ pour le corosync, une interface virtuelle _vmbr0_ qui bridge sur _eth0_ pour l'accès à internet et deux interfaces virtuelle _vmbr1_ et _vmbr2_ qui ne bridge pas vers l'extérieur, le bridge va se faire avec shorewall.
Nous avons une interface _eth2_ pour le corosync, une interface virtuelle _vmbr0_ qui bridge sur _eth0_ pour l'accès à internet et deux interfaces virtuelles _vmbr1_ et _vmbr2_ qui ne bridgent pas vers l'extérieur, le bridge va se faire avec Shorewall.
## Installation de Shorewall
```
@ -16,14 +16,14 @@ Shorewall est maintenant installé
Garder le fichier d'origine
## /etc/shorewall/interfaces
Associations des interfaces du système avec les zones du parefeu
Associations des interfaces du système avec les zones du pare-feu
```
?FORMAT 2
#ZONE INTERFACE OPTIONS
net vmbr0 tcpflags,nosmurfs,routefilter,bridge,routeback,logmartians
krkn vmbr1 tcpflags,nosmurfs,routefilter,bridge,routeback,logmartians
ext vmbr2 tcpflags,nosmurfs,routefilter,bridge,routeback,logmartians
coro eth3 tcpflags,nosmurfs,logmartians
net vmbr0 tcpflags,nosmurfs,routefilter,bridge,routeback,logmartians
krkn vmbr1 tcpflags,nosmurfs,routefilter,bridge,routeback,logmartians
ext vmbr2 tcpflags,nosmurfs,routefilter,bridge,routeback,logmartians
coro eth3 tcpflags,nosmurfs,logmartians
```
### /etc/shorewall/policy
@ -32,13 +32,13 @@ Définition de la politique globale du pare-feu
#SOURCE DEST POLICY LOGLEVEL RATE CONNLIMIT
$FW net ACCEPT
$FW coro ACCEPT
krkn net ACCEPT
$FW coro ACCEPT
krkn net ACCEPT
ext net ACCEPT
ext krkn DROP info
ext krkn DROP info
net all DROP info
all all REJECT info
all all REJECT info
```
@ -53,35 +53,34 @@ Définition des exceptions aux règles définies dans le fichier policy
?SECTION UNTRACKED
?SECTION NEW
Invalid(DROP) net all tcp
Invalid(DROP) net all tcp
DNS(ACCEPT) $FW net
Ping(ACCEPT) all $FW
SSH(ACCEPT) net all
Ping(ACCEPT) all $FW
SSH(ACCEPT) net all
ACCEPT $FW krkn icmp
ACCEPT $FW krkn icmp
ACCEPT $FW ext icmp
ACCEPT $FW net icmp
ACCEPT krkn ext tcp 80,443
ACCEPT net $FW tcp 8006
ACCEPT krkn ext tcp 80,443
ACCEPT net $FW tcp 8006
```
### /etc/shorewall/snat
Configuration SNAT permettant de faire du "masquerading", ainsi les paquets qui sortent des CT LXC ont comme IP source, l'IP de l'interface externe _eth0_.
Configuration SNAT permettant de faire du "masquerading", ainsi les paquets qui sortent des containers ont comme IP source l'IP de l'interface externe _eth0_.
```
#ACTION SOURCE DEST
MASQUERADE vmbr1 vmbr0
MASQUERADE vmbr2 vmbr0
MASQUERADE vmbr1 vmbr0
MASQUERADE vmbr2 vmbr0
```
### /etc/shorewall/zones
Définition des zones et de leur type.
Définition des zones et de leurs types.
```
#ZONE TYPE
fw firewall
net ipv4
krkn ipv4
krkn ipv4
ext ipv4
coro ipv4
```
Le firewall de Beta est maintenant configuré comme décrit dans le shéma global du réseau.
Le firewall de Beta est maintenant configuré comme décrit dans le schéma global du réseau.

View File

@ -1,3 +1,3 @@
# Mise en place de reverse proxy NGINX avec certificats SSL cerbot
# Mise en place de reverse proxy NGINX avec certificats SSL certbot
Vous trouverez ici toute la documentation relative à la mise en place de reverse proxy NGINX, à l'édition de certificat SSL et au renouvellement automatique de ces certificats.
Vous trouverez ici toute la documentation relative à la mise en place de reverse proxy NGINX, à l'édition de certificat SSL et au renouvellement automatique de ces certificats.

View File

@ -1,12 +1,12 @@
# Configuration type d'un reverse proxy NGINX
Nous allons voir ici comment configurer un reverse proxy NGINX dans deux cas,
Ici, nous allons voir comment configurer un reverse proxy NGINX dans deux cas,
- Si le container du service est sur la node principale (Alpha).
- Si le container du service n'est pas sur la node principale mais sur Beta.
Dans le premier cas nous redirigerons directement la requête sur le container du service à l'aide d'un reverse proxy NGINX configuré du le container NGINX de Alpha.
Dans le premier cas nous redirigerons la requête sur le container du service à l'aide d'un reverse proxy NGINX configuré sur le container NGINX de Alpha.
Dans le second cas nous redirigerons la requête sur Beta à l'aide d'un reverse proxy NGINX configuré sur le container NGINX de Alpha. Sur Beta la requête sera redirigé vers le container NGINX de Beta avec une règle DNAT.
Dans le second cas nous redirigerons la requête sur Beta à l'aide d'un reverse proxy NGINX configuré sur le container NGINX de Alpha. Sur Beta la requête sera redirigée vers le container NGINX de Beta avec une règle DNAT puis vers le container du service.
## Mise en place des DNAT
@ -44,18 +44,18 @@ On redémarre Shorewall
systemctl restart shorewall
```
## Dans tout les cas
### Instatalation de Certbot
## Dans tous les cas
### Installation de Certbot
On installe certbot qui est l'outils utilisé par Let's Encrypt pour obtenir des certificats SSL.
On installe certbot qui est l'outil utilisé par Let's Encrypt pour obtenir des certificats SSL.
```
apt-get install certbot
apt-get install python-certbot-nginx
```
Il faut configurer notre zone DNS pour que address.fr pointe vers l'adresse ip publique du cluster. La mention subdomain représente le sous domaine, s'il n'y en a pas laisser un blanc.
Il faut configurer notre zone DNS pour que _address.fr_ pointe vers l'adresse ip publique du cluster. La mention subdomain représente le sous-domaine, s'il n'y en a pas, laisser un blanc.
```
subdomain IN A 84.100.250.4
subdomain IN A ip_publique
```
## Configuration du reverse proxy NGINX pour une connexion sur un container présent sur Alpha.
@ -85,7 +85,7 @@ certbot --nginx -d address.fr
```
Choisir No redirect.
Maintenant que le certificat est générer on va remplacer la configuration du serveur web.
Maintenant que le certificat est généré, on va remplacer la configuration du serveur web.
```
nano /etc/nginx/conf.d/address.fr.conf
@ -100,7 +100,7 @@ server {
server {
listen 443 ssl;
server_name address.fr;
server_name address.fr;
location / {
proxy_pass http://ip_ct_alpha/;
proxy_set_header Host $http_host;
@ -119,7 +119,7 @@ server {
### Sur Alpha
On commence par configurer un serveur NGINX simple pour l'obtention du certificat. Se reverse proxy rediregera les requêtes sur _address.fr_ vers la container NGINX de la node Beta via DNAT.
On commence par configurer un serveur NGINX simple pour l'obtention du certificat. Ce reverse proxy redirigera les requêtes sur _address.fr_ vers le container NGINX de la node Beta via DNAT.
```
nano /etc/nginx/conf.d/address.fr.conf
@ -138,7 +138,7 @@ server {
```
### Sur Beta
On configure un serveur web qui va rediriger les requetes entrante sur Beta pour l'host "address.fr" vers le container de se site.
On configure un serveur web qui va rediriger les requêtes entrantes sur Beta avec comme host _address.fr_ vers le container du service associé à l'host.
```
nano /etc/nginx/conf.d/address.fr.conf
@ -162,7 +162,7 @@ certbot --nginx -d address.fr
```
Choisir No redirect.
Maintenant que le certificat est générer on va remplacer la configuration du serveur web.
Maintenant que le certificat est généré, on va remplacer la configuration du serveur web.
### Sur Alpha
@ -181,7 +181,7 @@ server {
server {
listen 443 ssl;
server_name address.fr;
server_name address.fr;
location / {
proxy_pass http://10.40.0.2/; #Ip de Beta sur le bridge Alpha/Beta
proxy_set_header Host $http_host;
@ -196,15 +196,15 @@ server {
}
```
## Renouvelement automatique des certificats SSL sur le container NGINX de Alpha
Tout les certificats SSL sont édité depuis le container NGINX de Alpha pour éviter d'avoir à les renouveler manuellement nous allons créer une tache de renouvellement automatique avec cron.
## Renouvellement automatique des certificats SSL sur le container NGINX de Alpha
Tous les certificats SSL sont édités depuis le container NGINX de Alpha. Pour éviter d'avoir à les renouveler manuellement, nous allons créer une tâche de renouvellement automatique avec une tâche cron.
On accède au fichier de configuration des tâches cron
```
crontab -e
```
On ajoute notre tache de renouvelement en fin de fichier
On ajoute notre tâche de renouvellement en fin de fichier
```
0 12 * * * /usr/bin/certbot renew --quiet
```
Ainsi les certificats se renouveleront automatiquement.
Ainsi les certificats se renouvelleront automatiquement.

View File

@ -1,48 +1,48 @@
# Mise en place du cluster entre nos deux nodes
Nous avons déjà mis en place :
- Proxmox VE 6 sur les deux nodes (Alpha et Beta)
- Un RAID1 ZFS sur chacune des nodes
- Un RAID1 ZFS sur chacune des nodes
## Préparation des deux nodes
Avant de monter le cluster il faut permettre aux deux nodes de communiquer localement pour cela nous allons rajouté une interface qui utilisera une carte réseau à part.
Avant de monter le cluster, il faut permettre aux deux nodes de communiquer localement. Pour cela, nous allons rajouter une interface qui utilisera une carte réseau à part.
### /etc/network/interfaces
L'interface eth0 est configurée pendant l'installation de Proxmox. Proxmox utilise la première carte réseau pour communiquer avec l'extérieur (eth0).
On va mettre en place une interface supplémentaire directement reliée à l'autre node sur la seconde carte réseau (eth3) pour ne pas altérer le débit fournis par la première.
*Pour avoir la liste des interfaces matérielles ont utilise ifconfig -a*
On va mettre en place une interface supplémentaire directement reliée à l'autre node sur la seconde carte réseau (eth3) pour ne pas altérer le débit fourni par la première.
*Pour avoir la liste des interfaces matérielles on utilise dmesg  | grep eth*
##### Depuis Alpha on ajoute
```
auto eth3
iface eth3 inet static
address 10.30.0.151
address 10.30.0.1
netmask 255.255.255.0
```
##### Depuis Beta on ajoute
```
auto eth3
iface eth3 inet static
address 10.30.0.152
address 10.30.0.2
netmask 255.255.255.0
```
Nous avons désormais un multicast en place entre Alpha et Beta ainsi les hyperviseurs dialogueront entre eux localement sur une interface et seront relié au net sur une autre interface. Matériellement il faut un cable croisé entre les deux ports correspondant à eth3.
Nous avons désormais un multicast en place entre Alpha et Beta. Ainsi les hyperviseurs dialogueront entre eux localement sur une interface et seront reliés au net sur une autre interface. Matériellement il faut un câble croisé entre les deux ports correspondant à eth3.
### /etc/hosts
##### Depuis Alpha
```
127.0.0.1 localhost.localdomain localhost
192.168.2.30 alpha.krhacken.org alpha pvelocalhost
# corosync
10.10.1.151 alpha-corosync.krhacken.org alpha-corosync
10.10.1.152 beta-corosync.krhacken.org beta-corosync
#Corosync
10.30.0.1 alpha-corosync.krhacken.org alpha-corosync
10.30.0.2 beta-corosync.krhacken.org beta-corosync
```
##### Depuis Beta
```
127.0.0.1 localhost.localdomain localhost
192.168.2.31 beta.krhacken.org beta pvelocalhost
10.10.1.151 alpha-corosync.krhacken.org alpha-corosync
10.10.1.152 beta-corosync.krhacken.org beta-corosync
#Corosync
10.30.0.1 alpha-corosync.krhacken.org alpha-corosync
10.30.0.2 beta-corosync.krhacken.org beta-corosync
```
Le multicast entre Alpha et Beta est désormais accessible via des hostnames.
@ -55,6 +55,4 @@ On ajoute Beta au cluster Sigma directement depuis Beta
```
pvecm add alpha-corosync --link0 beta-corosync
```
*Voir si il est nécessaire de redonder les ring en passif au cas ou le ring0 pète, surêment pas utile si c'est la même carte réseau*
Notre cluster Sigma est maintenant créée 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 une interface différente de celle utilisée pour les communications avec l'extérieur.

View File

@ -1,8 +1,8 @@
# Respect du quorum avec seulement deux nodes
La technologie corosync à besoin de minimum 3 votes (quorum) pour éviter les risques de splitbrain en cas de crash d'un des nodes.
La technologie corosync a besoin de 3 votes minimum pour avoir le quorum et éviter les risques de splitbrain en cas de crash d'une des nodes.
Nous ne disposons que de deux nodes, nous allons donc mettre en place un "Corosync External Vote". Il suffit d'un containers sur une autre machine que nous appelerons instance de quorum.
Nous ne disposons que de deux nodes, nous allons donc mettre en place un "Corosync External Vote". Il suffit d'un container sur une autre machine que nous appellerons instance de quorum.
## Mise en place de l'instance de quorum
@ -27,7 +27,7 @@ ssh-copy-id -i /root/.ssh/id_rsa root@ip_instance_quorum
```
## Ajout de l'instance au cluster sigma depuis Alpha
Maintenant que notre instance de quorum est configuré nous allons l'ajouter au cluster Sigma
Maintenant que notre instance de quorum est configurée, nous allons l'ajouter au cluster Sigma
```
pvecm qdevice setup <ip_instance_quorum>
```
@ -37,4 +37,4 @@ On vérifie que notre cluster contienne nos deux nodes et une instance de quorum
pvecm status
```
Nous avons maintenant trois votes, il y a donc suffisamment d'instance pour éviter le split-brain en cas de crash d'une nodes car même avec une nodes en moins le quorum sera respecté.
Nous avons maintenant trois votes, il y a donc suffisamment d'instances pour éviter le split-brain en cas de crash d'une node car, même avec une node en moins, le quorum sera respecté.