Catégorie : Non classé

Pas de commentaire

Création d’un routeur et pare-feu pour un serveur ESXi avec l’appliance pfSense

  de

Lorsque je suis passé de Proxmox VE qui est un hyperviseur basé sur Debian à vSphere ESXi, il m’a fallu trouver une nouvelle solution pour faire du routage d’adresses vers mes machines virtuelles car je ne veux pas utiliser une adresse IP par machine virtuelle. Si Proxmox VE permet cela nativement car basé sur Debian il possède iptables, ESXi n’a rien par défaut. Cependant, grâce à pfSense, il est possible d’ajouter cette fonctionnalité, pour peu que l’on soit en mesure d’avoir une deuxième IP différente de celle de l’ESXi à affecter (chez les prestataires louant des serveurs, une telle IP est généralement appelée une IP failover).

pfSense est une appliance faisant office – entre autres – de pare-feu, de routeur, de serveur DHCP, de serveur DNS, etc. basée sur BSD. Il existe une version gratuite que l’on peut récupérer sur le site web officiel. Dans cet article, je vais donc expliquer comment utiliser pfSense pour faire du NAT sur un serveur ESXi.

J’ai réalisé ces manipulations sur un serveur vSphere ESXi de test en version 6.0u2 – avec une licence gratuite. Je pars du principe que vous avez un minimum de connaissances de l’interface web ou du vClient, par conséquent je ne vais pas systématiquement réaliser des captures d’écran ou détailler le chemin à effectuer pour trouver où effectuer les réglages. Les captures d’écran peuvent être agrandies en cliquant dessus pour une meilleure visibilité.

1. Préparation côté vSphere

Le rôle de l’appliance va être de capter le trafic venant de l’internet pour le bloquer ou le rediriger vers les machines virtuelles hébergées. On va donc avoir deux vSwitch : un qui va servir pour le LAN, dans lequel nous placerons toutes les machines virtuelles ainsi que l’appliance pfSense, et un autre vSwitch qui servira pour le WAN, sur lequel seule l’appliance sera connectée.

Etant donné qu’il est évidemment nécessaire que le vSwitch WAN soit celui qui soit relié physiquement à la carte réseau du serveur, celui qui est créé par défaut par vSphere sera le vSwitch WAN. Il faut donc créer un nouveau vSwitch qui sera celui pour le LAN.

On valide en laissant les options par défaut, et on arrive normalement à quelque chose comme ceci – j’ai renommé l’étiquette du WAN afin qu’elle soit plus lisible.

Il faut maintenant récupérer l’ISO de pfSense, téléchargeable sur le site officiel. Une fois le fichier récupéré, on l’envoie sur le datastore puis on crée la machine virtuelle. pfSense occupe très très peu de ressources : 1 vCPU, 512 Mo de RAM et un disque virtuel de 8 Go suffisent. Lors de la création, le type d’OS à sélectionner sera « Free BSD ».

Ne pas oublier d’ajouter une deuxième carte réseau à l’appliance. Sous BSD, em0 sera le WAN et em1 le LAN.

Ensuite, il est nécessaire de modifier les paramètres de la machine virtuelle avant de la démarrer et d’installer le système. En effet, sur la carte WAN, nous allons déclarer l’adresse MAC de l’adresse IP que nous allons affecter à pfSense. Dans le cadre d’un serveur loué chez OVH par exemple, nous allons prendre une IP failover et utiliser l’adresse MAC de celle-ci. La carte LAN gardera une adresse MAC automatique gérée par vSphere.

L’adresse MAC de notre carte WAN sera celle de l’IP failover ou du matériel possédant cette IP.

Ensuite, il suffit de monter l’ISO depuis le datastore et de connecter le lecteur optique virtuel pour pouvoir démarrer la machine et laisser l’autoboot de pfSense agir.

2. Installation de pfSense

En démarrant pfSense, l’installeur va démarrer automatiquement si le mode rescue n’est pas sélectionné. Le premier écran permet de configurer rapidement l’installation.

Les options par défaut vont bien, bien qu’il soit possible de configurer le clavier, cela n’importe peu car une fois le système redémarré, nous allons rebasculer sur un clavier en-us. A l’étape suivante, nous allons choisir la « Quick / Easy Install » et le « Standard Kernel ». Ensuite, nous allons redémarrer. Par défaut, l’accès à l’interface d’administration est 192.168.1.1 et les logins admin / pfsense. Après le premier redémarrage, le système va se préconfigurer, cela peut prendre quelques minutes. A l’issue, il est possible de configurer l’appliance via le web ou via la console. L’installation est terminée lorsque nous arriverons sur cet écran post-boot.

C’est le moment de vérifier que tout est bien configuré. Normalement le WAN ressort sur l’interface em0 (sur VMware, cela doit être la carte WAN, situé sur le vSwitch0, avec l’adresse MAC de l’IP failover, la première carte de la machine) et le LAN ressort sur l’interface em1 (carte LAN, situé sur le vSwitch que nous avons créé au début, avec une MAC automatique, la deuxième carte de la machine).

3. Configuration de base de pfSense

Attention : la console de pfSense utilise un clavier en-us. Il est possible de changer la disposition du clavier en accédant au shell, cependant étant donné le peu de manipulations à faire en console, nous allons rester sur ce type de clavier.

La première chose à faire une fois l’écran accessible est de configurer les deux cartes. Même si l’interface LAN possède la bonne IP, nous allons faire une passe sur les deux. Nous allons donc saisir 1 comme option, et répondre à quelques questions :

  1. Création de VLAN : cela n’est pas important au départ, et peut très bien attendre la configuration par le web. Nous allons donc répondre « No » pour l’instant.
  2. L’interface pour le WAN nous est demandée. Il s’agit donc de notre première carte réseau sur la machine, donc em0 pour pfSense.
  3. L’interface pour le LAN nous est demandée : em1.
  4. Nous n’avons pas d’autres interfaces, nous laissons le champ vide et validons.
  5. Une confirmation est demandée : il suffit de valider.

Un petit temps de traitement est nécessaire et on retombe normalement sur l’écran principal. Nous allons maintenant configurer les adresses des deux interfaces.

En premier, l’interface WAN.

Il nous faut renseigner l’adresse IP WAN (l’IP failover, ou celle reliée à l’adresse MAC que nous avons saisi auparavant), le masque de sous-réseau et enfin la passerelle. Dans le cas d’une IP failover, il est fort probable que la passerelle soit l’IP en .254 à la fin. Ensuite, à moins d’avoir une IPv6, la seconde partie peut être passée – sinon, le même raisonnement que pour l’IPv4 est à appliquer. Ensuite, il est demandé si l’on veut basculer l’interface web sur du HTTP au lieu du HTTPS.

On revient ensuite à l’écran de base et nous allons répéter cette configuration mais pour la deuxième interface.

La configuration de la carte LAN est plus simple. 192.168.1.1 devient la passerelle pour les autres VM.

Il est possible d’activer le DHCP sur l’interface LAN à la fin de la configuration. Etant donné que nous allons installer une seule machine virtuelle sur la plateforme, cela a peu d’importance. Si l’option est sélectionnée, alors la plage d’adresses que le serveur pourra attribuer est demandée. La configuration de base est terminée, pfSense fonctionne.

4. Pour aller un peu plus loin

Nous allons déployer une machine virtuelle toute simple afin de tester le bon fonctionnement de pfSense et accéder à l’interface web bien plus pratique que le shell BSD. Une machine virtuelle fonctionnant sous Debian GNU/Linux fera parfaitement l’affaire. La petite image « netinst » pèse moins de 300 Mo et nécessite une connexion internet pour s’installer : le test idéal.

Une seule carte réseau pour la VM, celle du LAN.

Je ne vais pas faire une passe sur l’installation d’un système Debian. Cependant, l’installateur a bien pu configurer la machine virtuelle automatiquement grâce au DHCP que j’ai activé – sans cela, il aurait fallu saisir une adresse IP – par exemple 192.168.1.2 – et pfSense offre bien internet à la VM qui a pour IP de sortie notre IP failover, car les paquets sont téléchargés depuis les miroirs de Debian au fil de l’installation :

L’image « netinst » de Debian a besoin d’internet pour récupérer les paquets qui ne font pas partie du système de base. La machine a donc bien accès au net.

pfSense fonctionne donc très bien, puisqu’il est accessible et que l’appliance a fourni une adresse IP à ma machine virtuelle. On peut donc désormais se connecter à l’interface d’administration et passer par le petit assistant de configuration. Normalement, tout a été configuré par nos soins via la console – rien n’est à modifier pour l’instant. Enfin, à la fin, il est conseillé de changer le mot de passe d’administration.

Une fois libre, il est possible d’accéder à tout un tas de paramètres différents, mais nous allons seulement nous intéresser à la partie NAT dans ce billet, car les possibilités de pfSense sont très larges (sur mon infra perso, je m’en sers également comme serveur DHCP et DNS, par exemple). En allant dans Firewall > NAT, il est possible de créer des règles de redirection de ports. Par exemple, si je veux accéder en RDP à une machine VM Windows, il me suffit de créer une règle et de demander la redirection des bons ports :

Si 192.168.1.12 est l’IP de ma machine Windows, tout ce qui arrive sur le port 3389 de l’interface WAN (donc l’IP failover) est redirigé vers le port 3389 de ma machine Windows. Une fois la règle enregistrée, la configuration de pfSense doit être validée pour qu’elle rentre en action.

Pour faire un test de bon fonctionnement, je vais ouvrir le port 22 et le rediriger vers la VM.

L’écran de NAT de pfSense. Il est possible de catégoriser et de trier toutes les règles.

Une fois la configuration appliquée, il ne me reste plus qu’à ouvrir un client SSH et à tenter de me connecter.

La connexion est ouverte, je suis bien connecté en SSH sur ma VM depuis une machine extérieure.

Et voilà 😉

Afin de clore cet article, deux autres petites choses :

  • Il existe un paquet BSD pour les vmtools afin que la machine s’interface mieux avec ESXi. Dans System > Package Manager, il suffit de rechercher Open-VM-Tools et d’installer le paquet.
  • Dans Diagnostics > Backup & Restore, il est possible de faire un export XML de toute la configuration de pfSense. Cette sauvegarde est importante car en cas de crash, il est possible depuis l’install de pfSense de lui donner ce fichier XML pour que toute la configuration soit restaurée à l’identique.
L’écran des baux DHCP (Status > DHCP Leases), à partir duquel on peut transformer un bail temporaire en une réservation.
Pas de commentaire

J’ai testé C14, le service d’archivage d’Online

  de

Il y a un peu moins de 2 mois, je me faisais cambrioler, perdant mon ordinateur, ainsi que mon disque dur de sauvegarde TimeMachine. Heureusement, étant sous macOS et utilisateur d’iCloud, j’ai pu conserver l’intégralité de mes fichiers.

N’étant jamais à l’abri d’une perte de données du côté des serveurs d’Apple, d’un piratage de compte ou d’une mauvaise manipulation, j’ai voulu m’abonner à un service d’archivage de fichiers, me permettant de conserver mes documents les plus importants. Cependant, ces services sont souvent dimensionnés pour les entreprises ou coûteux en fonction du volume de données – il faut croire que pour l’instant, un système de stockage en ligne comme Dropbox, Onedrive ou Amazon Drive suffisent pour la majorité des utilisateurs.

Mais si il s’agit de simple stockage de fichiers en ligne sans aucune garantie de quel type, des services comme C14 d’Online ou Amazon Glacier sont orientés vers la sauvegarde et l’archivage légal. C’est exactement ce que je recherchais : un espace de stockage sécurisé, avec des garanties contractuelles, et des tarifs qui restent tout à fait raisonnables tant qu’on s’en sert pas comme un cloud standard avec des modifications, des uploads et downloads à tout va. Une sauvegarde de dernier recours si une situation comme celle-ci avait à se reproduire.

Je me suis donc orienté vers la solution d’Online, nommée C14, car moins chère que les concurrents principaux, et moins complexe à la compréhension tarifaire souvent orientée entreprise chez la concurrence. La création d’un compte est gratuite ; cependant un moyen de paiement est nécessaire pour utiliser le service car je suis facturé en fonction de l’utilisation que j’en fais.

Hiérarchiquement, on possède des coffres-forts, qui sont comme des gros répertoires. Leur création est gratuite.

Et ensuite, les archives en elles-même, qui sont les bases de la facturation. On y stocke – presque – autant que l’on veut (à la limite de 40 To par coffre-fort). Chaque opération sur ces archives est facturée.

Je vais y créer une archive pour y déposer des fichiers. J’y choisis le nom, une description, puis plusieurs paramètres dont l’intérêt dépend de la criticité des fichiers que je vais y déposer. Je laisse les paramètres standard car ils suffisent à mon usage. Le transfert en SFTP est rapide et le plus simple.

Une fois que l’archive est créée, un login et un mot de passe temporaire SFTP m’est fourni : comme je l’ai choisi précédemment, cet accès est ouvert pendant 2 jours. Au-delà des 2 jours, l’archive se verrouille et enclenche la tarification, ce qui signifie que je n’ai plus accès directement à ces fichiers à moins de demander le désarchivage. Celui-ci fonctionne de la même manière : en fonction des paramètres choisis, un accès est ouvert et je peux y récupérer les fichiers (ou en déposer de nouveaux). Tout le trafic qui passe au moment où l’archive est ouverte n’est pas facturé.

Un système de versioning existe : cela signifie qu’un désarchivage et un réarchivage ne supprime pas l’archive. Une deuxième est créée, avec un timestamp différent, afin de pouvoir conserver un delta de données si nécessaire. Il est également possible de forcer l’archivage si l’on ne souhaite pas attendre la fin du délai.

Les opérations se font plutôt rapidement, il s’agit généralement de quelques minutes pour des archives de petites tailles, mais cela peut prendre plus de temps pour des archives importantes (débit annoncé par Online : 650 Mo/seconde).

Chaque archive possède son historique, qui peut être exporté en CSV. A chaque opération, le coût en annoncé. Les fichiers dedans sont cryptés, et Online utilise une clé propre à chaque archive liée à votre compte pour décrypter les fichiers. Pour plus de sécurité, il est possible de demander à Online de ne pas se souvenir de clé permettant de décrypter les fichiers, mais en contrepartie, la clef sera demandée pour chaque opération, il convient donc bien de la garder en sécurité quelque part sinon l’archive sera inexploitable.

En 2 mois, les services m’ont coûté… 5 centimes HT par mois. Il est vrai que je n’ai pas énormément de données stockées (environ 10 Go de photos, archives de travail, documents personnels, factures…), ce qui bénéficie à ce prix très faible. Pour l’instant, je n’ai pas de reproches à faire à ce service, qui servira essentiellement si jamais mon ordinateur ainsi que mon disque de sauvegarde sont dérobés et que j’ai un problème d’accès à mes données sur iCloud suite à un piratage. Mais depuis mon cambriolage, la peur de perdre les données était très présente car 2 des 3 emplacements n’étaient plus accessibles. Pour quelques centimes par mois, je suis plus serein. Les vrais plus de l’offre d’Online par rapport à la concurrence étant la simplicité de l’interface et la compréhension de la tarification. Le prix plus faible se paye par rapport au nombre plus faibles de datacenter sur lesquels stocker les données, et peut-être des performances plus faibles, mais je n’ai ici pas moyen réel de vérifier, ou encore un support moins accessible.

Pas de commentaire

VMware et Powershell : contrôle de l’état des vmtools et des disques orphelins

  de

Suite à quelques cas de vmtools qui tombaient en carafe sur des serveurs Windows en clientèle, j’ai eu l’idée de réaliser un petit script personnel afin de contrôler l’état des vmtools sur un ESXi ou un vCenter, et de remonter une alerte par email si jamais ils ne sont pas dans leur état normal.

On reçoit donc un courriel si les vmtools ne sont pas : en cours d’exécution, à jour ou installés. Par défaut, le script renvoie comme vmtools en erreur les machines qui sont éteintes car le serveur ne peut les joindre. C’est pourquoi il est nécessaire lors du contrôle d’exclure les machines éteintes.

 

Add-PSSnapin VMware.VimAutomation.Core
Add-PSSnapin VMware.PowerCLI
$From = "admin-vmw@localhost"
$To = "supervision@localhost"
$Smtp = "smtp.localdomain"
$ESXServer = "esxi.localdomain"
$ESXUser = "service"
$ESXPwd = "P@ssw0rd"

Connect-VIServer $ESXserver -User $ESXUser -Password $ESXPwd

$VMArray = Get-VM
foreach ($VM in $VMArray)
    {
    $VMPoweredOn = $VM.PowerState
    $toolsStatus = $VM.ExtensionData.Guest.ToolsStatus
    if ($toolsStatus -ne "toolsOK" -and $VMPoweredOn -eq "PoweredOn")
        {
        $MailString = "Bonjour, les vmtools sur la machine '$VM' remontent avec le statut inhabituel suivant : '$toolsStatus'."
        Send-MailMessage -From $From -To $To -Subject "vmtools en statut anormal sur $VM" -SmtpServer $Smtp -Body $MailString
        }
    }

Cela permet alors de pouvoir être plus réactif sur le bon fonctionnement des vmtools et d’éviter d’avoir des soucis de drivers réseau ou d’interface avec d’autres applications. Ce script est disponible dans une version commentée en cliquant sur mon miroir de téléchargement. A noter que pour ce script comme pour le suivant, un seul module Powershell est nécessaire mais en fonction de la version de PowerCLI installée, le nom de celui-ci peut changer.

Le deuxième script que j’ai écrit permet de trouver les VMDK orphelins présents sur les datastores d’un vCenter ou d’un ESX. Il prend la liste des VMDK sur les datastore puis récupère la liste des disques rattachés à une machine virtuelle. Il fait ensuite la différence des deux disques et affiche la liste des différences. Avant de procéder à une suppression, tout de même vérifier si le VMDK n’a pas été désolidarisé pour une raison X ou Y, ou qu’il ne s’agit pas d’un snapshot.

Add-PSSnapin VMware.VimAutomation.Core
Add-PSSnapin VMware.PowerCLI

$vmdkds=@()
$vmdkvm=@()
Write-Host "Parsing all datastores and VMDKs. This might take a while.`r`n"
$dslist = Get-View -ViewType Datastore | select Name
foreach($ds in $dslist) {
	$vmdks = Get-HardDisk -Datastore $ds.Name
        foreach($vmdk in $vmdks) {
            $vmdkfilename = @{Filename = $vmdk.Filename}
            $vmdkentry = New-Object PSObject -Property $vmdkfilename
            $vmdkds+=$vmdkentry
        }
	}
    $vmlist = Get-View -ViewType VirtualMachine | select Name
    foreach($vm in $vmlist) {
        $vmdks = Get-HardDisk -VM $vm.Name
        foreach($vmdk in $vmdks) {
            $vmdkfilename = @{Filename = $vmdk.Filename}
            $vmdkentry = New-Object PSObject -Property $vmdkfilename
            $vmdkvm+=$vmdkentry 
        }
    }
Write-Host "Done. Now processing. Please wait.`r`n"
Compare-Object $vmdkvm $vmdkds -Property Filename | Where-Object { $_.SideIndicator -eq "=>" } | foreach-object { Write-Host $_.InputObject }

Vous pouvez également trouver ce script dans une version commentée sur ce lien provenant de mon miroir de téléchargement.

Pas de commentaire

Installation de TeamViewer 12 sur Debian Jessie

  de

Je voulais installer TeamViewer sur une machine Linux afin de prendre en main à distance ma machine chez moi.

Cependant, sur ma machine virtuelle qui est installée sous Debian Jessie avec un environnement graphique MATE, le paquet que l’on peut obtenir via le site de TeamViewer ne peut s’installer. En effet, le paquet est conçu pour une architecture i386 et mon Debian est une amd64.

Afin que le paquet puisse s’installer correctement, quelques petites commandes dans le terminal ainsi que l’installation de gdebi pour une meilleure gestion des dépendances du paquet sont nécessaires.

En su, ou alors en précédant les commandes de sudo, on va ajouter à dpkg l’installation de paquets en i386, puis installer gdebi qui pourra installer le paquet teamviewer et toutes les dépendances, car il y en a un paquet (vous aurez noté le jeu de mots…)

dpkg –add-architecture i386
apt-get install gdebi
gdebi teamviewer_12.0.71510_i386.deb

Et normalement, le paquet est installé. Si il y a des dépendances que ne peut résoudre gdebi, ce qui ne devrait pas arriver, il est possible de corriger cela avec la commande suivante :

apt-get install -f

Les dépendances seront corrigées et le paquet teamviewer installé. Il est désormais disponible au lancement.