Planet Libre
#Gnu/Linux, Planet Libre, pfsense
IP FAILOVER MULTIPLES - DEDIBOX - PFSENSE - ESXi
Depuis quelques années j'utilise une Dédibox pour héberger mes machines virtuelles sous VMWare ESXi6.5
J'ai deux types de VM
- Des VM portant directement une IP Failover Online
- Des VM portant une IP dans un réseau Privé derrière un Firewall PFSense ( aussi une VM)
Cela est assez pratiques, les VM portant des IP Failover sont des serveurs accessibles en direct
sur Internet portant des services Open.
L'avantage est que je peux porter des multiples services Web sur les port 80 et 443 sans faire du NAT
Sauf que le problème est que ces VM sont très peu protégées ( seulement le pare feu Linux)
A contrario des VM derrière le PFSense qui bénéficie de toutes les protections.
Actuellement
J'ai donc étudié la possibilité de pouvoir passer toutes mes VM derrière le PFSENSE
Cela permettra d'avoir un filtrage Fin et de bénéficier de tous les services PFSENSE ( IPS par exemple)
Pour Cela plusieurs prérequis qui'il a fallut lever:
- Comment porter plusieurs IP Failover sur une seule interface de mon PFSENSE???
- Comment porter 1 seul adresse MAC avec plusieurs IP Failover
- Comment paramétrer PFSENSE pour assigner des IP Failover à certaines VM et pas d'autres.
La Cible
Modifier l'adresse MAC de votre IP Failover pour utiliser une MAC Partagée qui sera porté par une VM
- Eteindre votre VM
- Se connecter sur l'interface Online
- Editer votre mac adress actuelle
- Supprimer votre Mac address
- Une fois suprimée et mise à jour
- Editer la mac et choisissez "Utiliser une Adresse Mac Existante
- Chosir la mac adresse qui porte déjà la patte WAN de votre VM PFSENSE
A partir de là tous paquet à destination de votre IP Failover sera dirigé vers l'adresse MAC partagée portée par votre VM PFSENSE.
Sur PFSENSE:
- Ajouter une IP Virtuelle de type IP Alias ( Votre IP Faiolver que vous voulez migrer) en /32
sur le WAN
- On voit ici 2 IP failover portées par mon pfsense ( en plus de l'ip failover assignée à l'interface WAN)
Occupons nous du NAT :
- Notre VM ne portera plus directement l'IP Failover mais une ip Privée dans le réseau LAN PRIV ( 192.168.100.0/24)
- Nous allons choisir l'adresse IP 192.168.100.130
NAT ENTRANT
Pour cela nous allons dire à PFSENSE que tout ce qui arrive à destination de l'IP Failover sera redirigé vers 192.168.100.130
- Dans Firewall / NAT / 1:1
NAT SORTANT
Pour cela nous allons dire à PFSENSE que tout ce qui sort depuis 192.168.100.130 est natté avec l'IP Failover
- Dans Firewall / NAT / Outbound
Ici on voit que 192.168.100.130 et 192.168.100.110 sortiront avec 2 ip failover différentes
Le reste sortira avec l'adresse WAN par défaut ( qui est aussi une failover)
Le Filtrage
Pour commencer faire une règle de filtrage Simple qui ouvre tout sur l'IP privée de la VM
Sur la Machine Virtuelle qui portait auparavant l'ip Failover
- Sur votre VM qui portait auparavant votre IP Failover.
- Modifier son paramétrage pour etre dans le réseau Privé et ne plus utiliser le Vswitch public
- Redemarrer la VM
- Modifier ces paramètres IP pour ne plus porter l'IP failover mais une IP Privée 192.168.100.130
- Avant
- Après
-Redémarrer la VM
- Après le reboot tout ping aussi bien l'adresse Pivée que Publique ( failover)
- On peut même tester le NAT Unbound
Exemple d'un wget sur un serveur apache externe, on voit bien notre ip publique failover s'afficher dans les logs
Voilà , il vous reste à affiner vos règle de filtrages ( souvenez vous nous avions tout ouvert !! )
N'ouvrez que le necessaire. ( pour ma part par exemple SSH et HTTP)
Je vous conseille d'utiliser les ALIAS qui permettent de relier un objet à une adresse IP
Pratique, pas besoin de se rappeler des IP
11 juillet 2019
Aucun commentaire
#Gnu/Linux, Planet Libre, nas linux qnap openmediavault
Mise en place des Snapshots avec BTRFS et Open Media Vault
Ce NAS contient tous mes documents non structurés.
J'ai bien sur de la backup quotidienne via le formidable outil Urbackup
Même si Urbackup est souple, j'ai eut besoin de pouvoir avoir une souplesse et une granularité de restauration plus souple.
Ayant la plupart du temps un poste client sous Windows, j'ai eu envie de pouvoir utiliser la notion de "versions précedentes."
C'est assez simple à mettre en oeuvre quand on à un serveur de fichier sous Windows.
Mais avec un serveur de fichier Gnu/Linux OMV comment faire ???
En glanant les informations sur le net, j'ai vu que c'était possible via les fonctionnalités
du système de fichiers BTRFS !!!
J'ai donc décidé de mettre en place cela sur un disque de mon NAS et de rendre
cela un peu automatisé.
Plusieurs étapes:
Formatage du disque : File Systeme BTRFS ( prononcé butterFS)Le disque en question est /dev/sdc
Le formater en BTRFS et le monter
A partir de là vous avez un FS en BTRFS
La particularité de BTRFS est qu'il permet de vréer des subvolumes
Ces subvolumes, sans être des disques blocs à proprement parlés
Pourront être utitilisé par l'OS commes des disques.
avec la commande mount, vous pouvez voir sous quel nom
est monté votre FS
Pou rmoi par exemple:
#mount
/dev/sdc1 on /srv/dev-disk-by-label-NASLV1 type btrfs (rw,relatime,space_cache,subvolid=5,subvol=/
Création du subvolume:
Création du partage SMB utilisant ce subvolume dans OMV:btrfs subvolume create
/srv/dev-disk-by-label-NASLV1/
@NASLV1
lister les subvolume:
root@nas:/srv/dev-disk-by-id-scsi-1ATA_ST1000DM003-1CH162_S1DE8V17-part1/NASLV2# btrfs subvolume list /srv/dev-disk-by-label-NASLV1/
ID 257 gen 1071 top level 5 path @NASLV1
Vous voyez que votre subvolume @NASLV1 peut etre selectionné directement comme un disque !!
Création du subvolume de snapshot:
De la même nanière on crée un subvolume pour les futurs snapshots.
btrfs subvolume create
/srv/dev-disk-by-label-NASLV1/
@NASLV1/.snapshots
#/srv/dev-disk-by-id-scsi-1ATA_ST1000DM003-1CH162_S1DE8V17-part1/NASLV2# btrfs subvolume list /srv/dev-disk-by-label-NASLV1/
ID 257 gen 1071 top level 5 path @NASLV1
ID 258 gen 1053 top level 257 path @NASLV1/.snapshots
Modification des options de partages pour que les snapshots soient visibles dans Windows:
Dans "options supplémentaires" du partage omv
Ajouter :
vfs objects = shadow_copy2
shadow:format = @GMT_%Y.%m.%d-%H.%M.%S
shadow:sort = desc
shadow:snapdir = .snapshots
Cela va permettre à Windows de peupler "versions précédentes"
Création d'un snapshot de test:
# btrfs subvolume snapshot /srv/dev-disk-by-label-NASLV1/@NASLV1 /srv/dev-disk-by-label-NASLV1/@NASLV1/.snapshots/@GMT_`date +%Y.%m.%d-%H.%M.%S`
Ce qui donne en retour
Create a snapshot of '/srv/dev-disk-by-label-NASLV1/@NASLV1' in '/srv/dev-disk-by-label-NASLV1/@NASLV1/.snapshots/@GMT_2018.11.13-23.32.28
Montons le partage sous Windows et vérifions l'onglet "versions précedentes."
Nos snapshots sont apparus
si on montre les fichiers cachés on voit aussi notre .snapshots
Programmons les snapshots et la rétention de nos snapshots.
Je n'ai rien trouvé d'automatisé pour créer les snapshots régulièrement et les purger.
J'ai donc créer quelques scripts pour automatiser cela:
take-btrfs-snap.sh
#!/bin/bash
pathsubvol="/srv/dev-disk-by-label-NASLV1/@NASLV1"
pathsnap="$pathsubvol/.snapshots"
snapname="@GMT_`date +%Y.%m.%d-%H.%M.%S`"
btrfs subvolume snapshot $pathsubvol $pathsnap/$snapname
purge-btrfs-snap.sh ( supprime les snapsshots de + de 7 jours)
#!/bin/bash
#Max Age of snapshots in days
agesnapday="7"
#Path snapshots
pathsnap="/srv/dev-disk-by-label-NASLV1/@NASLV1"
#Delete old snapshot
find $pathsnap -mindepth 1 -maxdepth 10 -mtime +$agesnapday -name "@GMT_*" -exec btrfs subvolume delete {} \;
list-btrfs-vol.sh
#!/bin/bash
pathsubvol="/srv/dev-disk-by-label-NASLV1/@NASLV1"
#pathsnap="$pathsubvol/.snapshots"
#snapname="@GMT_`date +%Y.%m.%d-%H.%M.%S`"
btrfs subvolume list $pathsubvol
usage-btrfs-snap.sh ( basé sur btrfs-du qu'il faudra installer)
#!/bin/bash
pathsubvol="/srv/dev-disk-by-label-NASLV1/@NASLV1"
btrfs-du $pathsubvol
Attention pour utiliser btrfs-du il faut activer les quotas sur votre subvolume
btrfs quota enable /srv/dev-disk-by-label-NASLV1/@NASLV1/
Il suffit d'ajouter ces commandes en tant que Tache planifiés sur OMV
J'ai décidé de faire 2 snapshots par jours à 00h00 et 12h00
Et tous les jours purger les snapshots de + de 7 jours
Vous pouvez maintenant avoir accès à des versions antérieurs de vos dossiers/fichiers
Et les copier/coller simplement
Edit 26-11-2018
Je me suis rendu compte au bout de 7 jours que mon script de purge effacait tous les snapshots.
La raison est simple : Les snapshots garde tous la date de leur dossier parent !!!!
Il faut le savoir
On ne peut donc pas se baser sur le find mtime pour effacer les snapshots.
J'ai donc revu ma façon de fonctionner:
- Ajout du temps unix en seconde dans le nom de mes snapshots
- Adaptation du script pour se baser sur un calcul du temps unix
- Adaption des options de partages smb
Les nouveaux scripts :
take-btrfs-snap.sh
#!/bin/bash
pathsubvol="/srv/dev-disk-by-label-NASLV1/@NASLV1"
pathsnap="$pathsubvol/.snapshots"
snapname="@GMT_`date +%Y.%m.%d-%H.%M.%S-%s`"
urge-btrfs-snap.sh ( supprime les snapsshots de + de 7 jours)
#!/bin/bash
#Max Age of snapshots in days
agesnapday="7"
agesnapsec=$(($agesnapday * 86400))
date=$(date +%s)
agesnaplimit=$(($date - $agesnapsec))
logfile=/var/log/snap.log
echo > $logfile
snaplistfile=/tmp/snaplist.txt
#Path snapshots
pathsnap="/srv/dev-disk-by-label-NASLV1/@NASLV1"
ls $pathsnap/.snapshots/ | grep GMT > $snaplistfile
listnap=$(cat $snaplistfile)
#echo $listnap
for i in $listnap
do
agesnap=$(echo $i | awk -F"-" '{print $3}')
if (("$agesnap" < "$agesnaplimit"))
then
echo "snapshot $i superieur a $agesnapday Jour" >> $logfile
echo "supression de $i" >> $logfile
btrfs subvolume delete $pathsnap/.snapshots/$i
else
echo "snapshot $i inferieur a $agesnapday Jour" >> $logfile
echo "pas de supression de $i" >> $logfile
fi
done
Adptation du share smb dans OMV pour prendre en compte le changement de nom
vfs objects = shadow_copy2
shadow:format = @GMT_%Y.%m.%d-%H.%M.%S-%s
shadow:sort = desc
shadow:snapdir = .snapshots
14 novembre 2018
Aucun commentaire