Pourquoi nous avons développé une cible iSCSI Windows native en Rust pour les restaurations Zero-Knowledge
Dans l'espace de la reprise après sinistre (Disaster Recovery), l'« Instant Mount » (montage instantané) est une fonctionnalité standard. La capacité de prendre un flux de sauvegarde distant et de l'exposer instantanément comme une lettre de lecteur local sur une machine Windows est essentielle pour remettre une entreprise en ligne et minimiser le RTO (Recovery Time Objective).
La plupart des fournisseurs de sauvegarde résolvent ce problème en intégrant des pilotes de disques virtuels tiers — comme ImDisk ou WNBD — dans leurs agents. Ce sont des pilotes en mode noyau (fichiers .sys) qui s'intègrent profondément dans la pile de stockage de Windows.
Chez StateWarden®, notre architecture est régie par un mandat strict : Zéro Dépendance Externe. Nous refusons de polluer le noyau de l'hôte avec des pilotes tiers. L'installation de modules de noyau externes introduit des risques de sécurité importants, des frictions lors du déploiement et une instabilité potentielle du système (BSOD).
Plus important encore, StateWarden est un système 100 % Zero-Knowledge. Les sauvegardes sont fortement dédupliquées et cryptées (AES-256-GCM) au niveau des blocs avant même de quitter le client. Les clés de décryptage ne quittent jamais la machine hôte. Si nous voulons monter instantanément une sauvegarde distante de 2 To, nous ne pouvons pas la télécharger et la décrypter dans un fichier temporaire — cela va à l'encontre du principe Zero-Knowledge et détruit les performances.
Le texte en clair (plaintext) ne doit exister qu'en mémoire RAM, exactement au moment où le système d'exploitation demande un secteur spécifique.
Pour y parvenir sans pilotes personnalisés, nous avons choisi la voie la plus difficile, mais la plus pure sur le plan architectural : Nous avons construit un serveur cible iSCSI entièrement conforme à partir de zéro, écrit entièrement en Rust, intégré directement dans l'agent StateWarden.
Windows possède un initiateur iSCSI natif intégré. En parlant son langage via une interface de boucle locale (loopback), nous avons pu diffuser des blocs depuis nos propres centres de données, les décrypter en RAM à la volée, et les servir nativement à la pile de stockage Windows.
Voici ce qu'il faut pour construire une cible de stockage en mode bloc à partir de zéro et apprivoiser la pile de stockage Windows, notoirement impitoyable.
Naviguer dans la rigueur de Windows iSCSI
Le protocole iSCSI (RFC 3720) encapsule des commandes SCSI complexes dans des unités de données de protocole (PDU) sur TCP. L'initiateur iSCSI de Windows fait exceptionnellement bien son travail, mais il est incroyablement strict. Un seul octet mal placé ou une légère déviation de la machine à états entraîne une défaillance silencieuse : l'initiateur abandonne simplement la connexion TCP (os error 10054) sans aucune explication.
Lors de notre implémentation initiale, l'initiateur Windows réussissait la négociation de connexion complexe (login handshake) et découvrait notre cible virtuelle. Mais au moment où il essayait d'interroger le disque, la connexion mourait violemment.
Le traçage des paquets a révélé le moment exact de l'échec : Windows envoyait une commande REPORT LUNS (0xA0). Notre serveur Rust la traitait parfaitement et attachait les données de charge utile directement au PDU SCSI Response (0x21).
Selon la RFC, un PDU SCSI Response ne doit contenir que des codes d'état (comme SUCCESS ou CHECK CONDITION). Il ne peut pas transporter de données de lecture. Toutes les données réelles doivent être envoyées via un PDU dédié SCSI Data-In (0x25). L'initiateur Windows a vu des octets de charge utile attachés à une trame d'état, l'a classé comme une corruption de protocole fatale, et a instantanément déclenché un TCP RST (Reset).
Refactoriser notre constructeur de paquets pour séparer le flux de données et définir correctement les indicateurs F (Final) et S (Status present) sur la trame Data-In a stabilisé la connexion.
Gestion de la fragmentation des PDU
Même avec un protocole conforme, les analyses approfondies du système de fichiers provoquaient des interruptions de connexion intermittentes. La percée est venue lors de l'analyse des paramètres de connexion iSCSI.
Pendant la négociation, Windows négocie une longueur maximale de segment de données de réception (MaxRecvDataSegmentLength typiquement 256 Ko). Cependant, lors de la lecture de grandes structures Master File Table (MFT), Windows émet des lectures SCSI de 512 Ko ou plus. Notre implémentation initiale a tenté d'envoyer l'intégralité de la charge utile de 512 Ko dans un seul PDU Data-In. Windows a vu le paquet surdimensionné, a réalisé qu'il dépassait les limites négociées, et a instantanément détruit le socket.
Nous avons dû réécrire notre logique de flux Data-In pour fragmenter automatiquement les requêtes de lecture SCSI massives en une séquence de PDU plus petits et conformes, fragmentés précisément selon les limites négociées par l'initiateur, en effectuant le décryptage et le mappage de déduplication à la volée sur plusieurs paquets.
Falsifier la géométrie NTFS en mémoire
Avec le protocole réseau solidifié, l'initiateur Windows s'est finalement connecté en douceur. Un nouveau disque est apparu dans la gestion des disques de Windows. Mais l'explorateur Windows a refusé de l'ouvrir, qualifiant le système de fichiers de "RAW".
Notre cible servait les octets exacts décryptés de la partition NTFS sauvegardée. Pourquoi Windows ne pouvait-il pas la lire ?
Le problème résidait dans la géométrie physique de la sauvegarde originale. Lorsque l'agent StateWarden sauvegarde un lecteur Windows en direct, il interroge l'API FSCTL_GET_NTFS_VOLUME_DATA pour déterminer la taille exacte du système de fichiers.
Cependant, cette API Windows rapporte la taille du volume à l'exclusion du secteur final. Ce secteur final contient le secteur d'amorçage du volume de sauvegarde (Backup VBR). Un système Windows en direct ne se soucie pas de cette troncature, mais le pilote ntfs.sys validant un disque nouvellement monté exige absolument que le VBR principal (à LBA 0) et le VBR de sauvegarde (à la fin du disque) correspondent parfaitement. Parce que notre flux de sauvegarde manquait de ce dernier secteur, Windows a rejeté l'ensemble du système de fichiers comme corrompu.
Nous avons conçu une correction en temps réel dans notre backend de streaming. Notre MbrWrapperBackend met maintenant en cache le VBR principal à la volée, calcule les véritables limites physiques de la partition, et injecte dynamiquement un VBR de sauvegarde synthétique exactement à la fin du flux en mémoire. Nous complétons (paddings) efficacement la géométrie parfaitement avant de la présenter à l'initiateur iSCSI.
Le gain architectural
Avec la géométrie NTFS exacte restaurée et les charges utiles réseau parfaitement fragmentées, le disque virtuel se monte instantanément. L'erreur "RAW" a disparu, et des gigaoctets de données fortement cryptées et dédupliquées provenant de nos centres de données sont immédiatement navigables dans l'explorateur Windows.
Chaque fois que vous double-cliquez sur un fichier, l'agent StateWarden récupère les blocs dédupliqués exacts du nœud de stockage distant, les décrypte en RAM en utilisant les clés détenues localement, et les transmet via la connexion iSCSI en boucle locale au système d'exploitation.
Construire une cible de stockage en mode bloc à partir de zéro est douloureux, mais le gain architectural est massif. Nous fournissons des capacités Bare-Metal "Instant Mount" de niveau entreprise nativement, avec une sécurité Zero-Knowledge absolue, et sans polluer le noyau de l'utilisateur avec des pilotes tiers. Nous ne prenons pas de raccourcis en ce qui concerne l'intégrité du système hôte.
Nous nous attendons tout à fait à ce que les fournisseurs traditionnels tentent de rétro-concevoir et de répliquer cette architecture sans pilote après avoir lu ceci. Ils sont les bienvenus pour essayer. Mais une implémentation iSCSI native n'est qu'un seul composant du moteur StateWarden. Ce n'est qu'une des dizaines de décisions architecturales exclusives — de notre cryptographie en couches PrimeKEM à nos heuristiques de défense active Vigil — qui surpassent fondamentalement les offres actuelles du marché. Nous ne construisons pas seulement un outil de sauvegarde ; nous concevons le nouveau standard de la résilience des données.