PRA low-cost et malin

Lionel -

Les mois et années passés ont vu plusieurs incidents graves dans les data centers. On pense bien sur à OVH, mais pas que et malgré toutes les mesures prises par les hébergeurs sérieux, aucun ne peut garantir une sécurité à 100 %. Donc quand le business de l'entreprise dépend de ses serveurs, ce qui est de plus en plus le cas, il faut prévoir un plan de secours afin de pouvoir survivre. Et cela passe généralement pas de multiples sauvegardes, celles offertes par l'hébergeur, mais également des sauvegardes totalement indépendantes et faites chez un autre hébergeur qui sera géographiquement le plus éloigné du premier. On pourra également externaliser ces secondes sauvegardes vers un troisième data center à l'étranger, mais si la fin du monde est décrétée je n'aurais pas vraiment de solution car Elon Musc ne propose pas encore de data center dans l'espace...

Un des outils le plus utilisé en entreprise c'est Veeam Backup & Recovery (il y en a d'autres). Si ce logiciel est souvent utilisé pour sauvegarder des hyperviseurs (VMWare et Hyper-V), on oublie parfois qu'il est également possible de de s'en servir pour sauvegarder des postes de travail, des serveurs physiques ou des instances (instances qui sont souvent des VM propriétaires proposées par les hébergeurs). Tout ce qui suit est possible avec la version proposée gratuitement par Veeam, et c'est ce que l'on va utiliser dans le cadre d'un PRA low-cost et malin !

Pour résumer on parle de PRA (plan de reprise d'activité, après sinistre) quand il s'agit mettre en œuvre la reprise d'activité à l'aide de procédures et d'architecture préalablement mise en place (des sauvegardes et de quoi les restaurer), et de PCA (plan de continuité d'activité) quand la continuité de l'activité est transparente grâce à une infrastructure répliquée bien plus complexe et couteuse. Tout dépend des enjeux et des moyens (plus de détails ici, là et ailleurs...).

Veeam Backup & Recovery

Pour sauvegarder les VM d'un hyperviseur avec Veeam B&R c'est très simple et ça se fait en deux clics de souris. Par contre pour sauvegarder nos machines physiques ça va être un peu plus compliqué, il faudra déployer un agent et communiquer en IP via un VPN si elles ne sont pas sur le même réseau.

site-to-site

Dans le cas qui suit les machines sont chez OVH et exposés directement sur Internet (je sais c'est pas bien et on va s'en occuper). La solution la plus simple est bien sur d'ouvrir les ports nécessaires, mais l'idée étant justement de sécuriser l'existant, on va commencer par sécuriser ce que l'on ajoute, et donc passer par un VPN. Cela permettra par la suite de ne pas toucher à la configuration même si on décide de ne plus exposer ces serveurs directement et de faire transiter le flux par une passerelle et un firewall.

J'ai testé 3 solutions, en commençant par Zérotier qui était présent. L'objectif étant de disposer d'un tunnel fiable et rapide entre le serveur à sauvegarder et le serveur Veeam.

  • Zerotier : fiable mais débits très aléatoires. Je suis étonné car j'ai l'habitude de ce SD-VPN.
  • Tailsacale : fiable, les débits sont meilleurs mais pas exceptionnels. Même remarque.
  • Wireguard : (en natif, en opposition à Tailscale qui est basé sur WG) fiable, le débit est excellent et occupe bien la bande passante disponible. Le cas échéant on peut ajuster le MTU.
  • Je n'ai pas testé en IPSec ni OpenVPN mais ça doit faire le job.

Tout ce petit monde travaillant en UDP, on verra plus loin le sproblèmes avec les anti DDOS.

Wireguard

J'ai fait au plus simple. On installe le client sur toutes les machines et on crée la configuration. Pour les fainéants on peut aussi créer la configuration sur ce site. Le serveur Veeam fait office de serveur Wiregard.

Le serveur

On ouvre le port 51820 sur le firewall local et on redirige celui-ci sur la passerelle ou le routeur dont il dépend.

[Interface]
Address = 10.10.10.1/24
ListenPort = 51820
PrivateKey = eKMxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=

[Peer]
PublicKey = 71exxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=
PresharedKey = Lpixxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=
AllowedIPs = 10.10.10.2/32

[Peer]
PublicKey = m7xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=
PresharedKey = EB5xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=
AllowedIPs = 10.10.10.3/32

[Peer]
PublicKey = IkOxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=
PresharedKey = 9cDxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=
AllowedIPs = 10.10.10.4/32

Client

Dans un premier temps on utilise le client en mode interactif, mais il est possible de l'activer en mode service.

[Interface]
Address = 10.10.10.6/24
ListenPort = 51820
PrivateKey = cKyxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=

[Peer]
PublicKey = 6kvxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=
PresharedKey = 5zHxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=
AllowedIPs = 10.10.10.0/24
Endpoint = x.x.x.x:51820       // IP Publique du serveur

A partir de là on doit pouvoir depuis le client faire un ping sur le serveur en 10.10.10.1. Mais dans le cas qui nous préoccupe il faut également que le serveur communique avec le client et donc ajouter des règles sur le firewall du serveur à sauvegarder.

On commence par s'assurer l'interface Wireguard est en profil privé, on visualise l'état avec :

PS C:\Users\Administrator> Get-NetConnectionProfile

Qui nous retourne :

Name             : Internet
InterfaceAlias   : Ethernet
InterfaceIndex   : 1
NetworkCategory  : Public
IPv4Connectivity : Internet
IPv6Connectivity : NoTraffic

Name             : WG-Veeam
InterfaceAlias   : WG-Veeam
InterfaceIndex   : 19
NetworkCategory  : Public
IPv4Connectivity : NoTraffic
IPv6Connectivity : NoTraffic

Ici notre interface Wireguard est sur le profil public et on va la passer en privé avec :

PS C:\Users\Administrator> Set-NetConnectionProfile -InterfaceIndex 19 -NetworkCategory Private

On peut maintenant depuis le serveur B&R vérifier par un ping que l'on accède bien au client, mais surtout que l'on accède bien au client en ouvrant un partage administratif : touche WIN/R \\10.10.10.3\admin$ou mieux de tester ça en PowerShell :

PS C:\Users\administrator> Test-NetConnection -ComputerName srv-distant.tld -port 445

Et si c'est tout bon ça va nous retourner :

ComputerName     : srv-distant.tld
RemoteAddress    : 10.10.10.11
RemotePort       : 445
InterfaceAlias   : WireGuard-PS
SourceAddress    : 10.10.10.1
TcpTestSucceeded : True

Si c'est le cas on peut passer au déploiement de l'Agent depuis Veeam Backup & Recovery.

Attention : Lors du déploiement de l'agent Veeam celui ci va créer des règles de firewall générique qui autorisent le trafic sur toutes les interfaces et tous les profils. A minima il faut restreindre ces règles sur le profil privé, en ce qui me concerne j'ai choisit de les effacer et de créer des règles plus restrictives via PowerShell (il suffit d'exécuter ce code en PS en mode admin) :

[System.Collections.ArrayList]$rules = @()

$rule = @{
    DisplayName = "# Veeam Installer Service (In)";
    Description = "Inbound rule for Veeam B&R Server";
    Group = "Veeam Networking";
    Direction = "Inbound";
    Profile = "Private";
    Enabled = "True";
    Action = "Allow";
    Program = "C:\Windows\Veeam\Backup\VeeamDeploymentSvc.exe";
    Protocol = "TCP";
    LocalPort = "Any";
    RemotePort = "Any";
    RemoteAddress = "10.10.10.1";
}
$rules.Add($rule) > $null

$rule = @{
    DisplayName = "# Veeam Installer Service (Veeam Agent for Microsoft Windows) (In)";
    Description = "Inbound rule for Veeam B&R Server";
    Group = "Veeam Networking";
    Direction = "Inbound";
    Profile = "Private";
    Enabled = "True";
    Action = "Allow";
    Program = "C:\Program Files\Veeam\Endpoint Backup\VeeamDeploymentSvc.exe";
    Protocol = "TCP";
    LocalPort = "Any";
    RemotePort = "Any";
    RemoteAddress = "10.10.10.1";
}
$rules.Add($rule) > $null

$rule = @{
    DisplayName = "# Veeam Data Mover x64 (Veeam Agent for Microsoft Windows) (In)";
    Description = "Inbound rule for Veeam B&R Server";
    Group = "Veeam Networking";
    Direction = "Inbound";
    Profile = "Private";
    Enabled = "True";
    Action = "Allow";
    Program = "C:\Program Files\Veeam\Endpoint Backup\x64\VeeamAgent.exe";
    Protocol = "TCP";
    LocalPort = "Any";
    RemotePort = "Any";
    RemoteAddress = "10.10.10.1";
}
$rules.Add($rule) > $null

$rule = @{
    DisplayName = "# Veeam Agent for Microsoft Windows Service (In)";
    Description = "Inbound rule for Veeam B&R Server";
    Group = "Veeam Networking";
    Direction = "Inbound";
    Profile = "Private";
    Enabled = "True";
    Action = "Allow";
    Program = "C:\Program Files\Veeam\Endpoint Backup\Veeam.EndPoint.Service.exe";
    Protocol = "TCP";
    LocalPort = "Any";
    RemotePort = "Any";
    RemoteAddress = "10.10.10.1";
}
$rules.Add($rule) > $null

$rules | ForEach-Object {
  New-NetFirewallRule @_
}

Veeam Agent

Important :

  • Pour déployer l'agent et sauvegarder le serveur il faut disposer du bon compte Windows de la machine à sauvegarder. Idéalement le compte adminsitrator d'origine, même s'il a été renommé pour des questions de sécurité (voir la note ici). Il doit être possible de contourner ce problème et utiliser un autre compte, mais j'avoue ne pas avoir perdu ce temps, je me suis contenté de réactiver ce compte d'origine et de le renommer.
  • Il est également important que le serveur sur lequel est installé l'agent puisse voir le serveur Veeam B&R par son nom DNS réel. Donc si ce n'est pas le cas on crée un enregistrement dans le fichier host de la machine à sauvegarder avec le nom idoine :
  • 10.10.10.1   veeam-serveur.domaine.tld (le vrai nom du serveur)
  • Pour plus de clarté je vous conseille également coté serveur Veeam de créer des enregistrements dans le fichier host pour désigner vos client plutot que par leur adresse IP :
  • 10.10.10.2   serveur-1.client.veeam (ici le nom est fictif et ne servira qu'à avoir un visuel plus clair dans B&R)
  • 10.10.10.3   serveur-2.client.veeam

Dans Veeam B&R / Inventory / Physical Infrastructure on crée un groupe de protection (Protection Group) dans lequel on ajoute un premier serveur à sauvegarder, par exemple : serveur-1.client.veeam. En validant Veeam va procéder au déploiement de l'agent. Il sera ensuite possible d'éditer ce groupe et y ajouter d'autres serveurs à protéger.

Si tout se passe bien on peut effacer les règles de firewall créer par l'agent et déployer nos propres règles (voir plus haut).

On peut maintenant créer un job de sauvegarde Veeam B&R et lancer une première sauvegarde. Je ne vais pas vous la faire step by step, les docs de Veeam sont plutôt bien faites et d'autres blogs décrivent le processus.

La restauration

Veeam offre plusieurs possibilités de restauration :

  • Dans le cloud (Amazon EC2, Azure, Google CE...),
  • Restauration de certains fichiers ou bases SQL de la machine,
  • Restauration de volumes ou exportation de disques virtuels

Mais on va se concentrer sur deux autres possibilités :

  • Le recovery via l'agent : on crée un media de recovery, on boote avec celui ci sur le serveur à restaurer et on lance la restauration avec les bonnes information.
  • Le mode instant recovery qui lui va nous permettre de restaurer la machine sur un hyperviseur dans une VM. C'est le mode le plus facile à mettre en œuvre dans le cadre d'un PRA. Cela sous entend que l'on dispose d'un hyperviseur de secours avec les ressources nécessaires, même si elles peuvent être plus réduites dans le cadre d'un plan de secours.

Instant Recovery

C'est le mode qui sera utilisé dans le cadre de la mise en œuvre de type PRA, souvenez vous : au feu ! Mon serveur chez OVH a été détruit, il n'est pas restaurable par les moyens classiques chez OVH, il me faut donc activer le plan de secours afin de poursuivre l'exploitation.

Les besoins :

  • Un hyperviseur (ici VMWare ESXi) proche de l'infrastructure de sauvegarde (c'est mieux car plus rapide) avec les ressources nécessaires à l'exécution du serveur à restaurer en urgence. Cet hyperviseur sera suffisant s'il s'agit juste de démarrer la machine restaurée et y accéder de façon ponctuelle. Par contre si cette machine doit être remise en production il faudra disposer d'un hyperviseur de production.
  • Un hyperviseur de production sur lequel basculer la machine.
  • Attention : de nos jours on peut se dire que des fournisseurs comme Scaleway ou OVH sont capables de provisionner un serveur en quelques minutes et qu'installer un VMWare en prendra quelques une de plus. C'est valable en temps normal, mais s'il y a le feu quelques part la situation sera certainement tout autre. La bonne pratique consiste donc à :
  • Soit provisionner et maintenir un ou plusieurs hyperviseurs de secours qui tournent à blanc ou sont arrêtées et auquel cas seul le stockage est facturé (Elastic Metal chez Scaleway par exemple).
  • Soit sous utiliser des hyperviseurs existant afin de laisser de la place pour une restauration PRA en urgence. Cette solution présente l'avantage de disposer d'un hyperviseur très performant dans son mode de production normal (car sous utilisé) et d'être certain de son fonctionnement en cas de besoin (en opposition à une machine en sommeil que l'on aura oublié de maintenir.).
  • Tout cela dépend bien entendu de l'architecture globale et des priorités dont il faut tenir compte.
  • Enfin, tt on ne le rappellera jamais assez, dans tous les cas tout doit être parfaitement documenté en partant du principe que dans le cas d'un besoin urgent les intervenants IT réguliers ne seront peut être pas disponibles et qu'un tiers sera à l'ouvre. Il devra donc disposer de toutes les informations nécessaires et d'un plan détaillé.

Restauration en mode Instant Recovery

Dans Veeam B&R on fait une clic droit sur la sauvegarde choisie  et on lance Instant Recovery

Il faut choisir :

  • Un hyperviseur local
  • Le nom (de la VM ESXi) de la machine qui apparaitra dans l’inventaire
  • Un datastore de redirection NFS si on de dispose pas de suffisamment de place sur le serveur sur lequel est installé Veeam (c’est généralement le cas)
  • Il ne fait pas cocher le démarrage automatique. Important car avant de démarrer une première fois et d’entameer le processus P2V il faudra ajuster les ressources.
  • On ajuste les ressources (RAM + nombre de CPU disponible sur le serveur de montage et le serveur de destination final). Le réseau se fera plus tard et dans un premier temps il vaut mieux désactiver l'interface internet afin que les éventuels VPN ne montent pas.
  • On lance la VM (sans s’y connecter si on souhaite la passer en production)
  • Quand elle est disponible sur ESX on fait un clic droit dans Instant Recovery : Migrate to Production :
  • On choisit le serveur ESX de destination ainsi que le datastore
  • On attends : ça peut être long selon la taille de la machine.
  • Quand c’est terminé la VM sera lancée et apparaitra avec le nom choisit dans l’admin ESX.
  • On se connecte en mode console et on lance l’installation des VMWare Tools depuis l’admin ESX.
  • Redémarrage. Pour gagner un reboot on peut aussi arrêter la VM
  • On choisit la carte VMX3 plus performante que la E1000 de base.
  • On ajuste la RAM et le nombre de CPU
  • On redémarre la VM et on lance la console
  • On ajuste les services au besoin (et on désactive s’il s’agit d’une restauration de test)
  • On ajuste les réglages réseau (DHCP ou IP statique) de la carte réseau
  • On ajuste au besoin les réglages réseau virtuels (Zerotier, Tailscale). (on désactive avant s’il s’agit d’une restauration de test) (reset ZT)
  • On désinstalle l’Agent Veeam qui ne sert plus à rien dans une VM.
  • On peu maintenant se connecter en admin RDP
  • On ajuste l’accès client depuis le firewall

Le serveur peut maintenant passer en production.

DDOS

AGENT

AGENT INTEGRATION

Je l'ai faite courte et rien ne remplace l'expérience. Et clairement quand on se lance dans la mise en œuvre d'une infrastructure de PRA, ce qui va prendre du temps, et donc couter de l'argent, ce sont les restaurations de test qu'il faudra planifier à intervalles très réguliers. Fastidieux mais indispensable.