Warum wir ein natives Windows-iSCSI-Target in Rust für Zero-Knowledge-Restores entwickelt haben

Im Bereich Disaster Recovery (DR) ist die Funktion "Instant Mount" absoluter Standard. Die Möglichkeit, einen Remote-Backup-Stream zu laden und ihn sofort als lokales Laufwerk auf einer Windows-Maschine bereitzustellen, ist entscheidend, um ein Unternehmen wieder online zu bringen und die RTO (Recovery Time Objective) zu minimieren.

Die meisten Backup-Anbieter lösen dies, indem sie Virtual-Disk-Treiber von Drittanbietern – wie ImDisk oder WNBD – in ihre Agenten bündeln. Dies sind Kernel-Mode-Treiber (.sys-Dateien), die sich tief in den Windows-Speicher-Stack einklinken.

Bei StateWarden® unterliegt unsere Architektur einem strengen Mandat: Keine externen Abhängigkeiten. Wir weigern uns, den Host-Kernel mit Treibern von Drittanbietern zu verunreinigen. Die Installation externer Kernel-Module birgt erhebliche Sicherheitsrisiken, Implementierungshürden und potenzielle Systeminstabilitäten (BSODs).

Noch wichtiger ist, dass StateWarden ein zu 100 % Zero-Knowledge-System ist. Backups werden auf Blockebene stark dedupliziert und verschlüsselt (AES-256-GCM), bevor sie den Client jemals verlassen. Die Entschlüsselungscodes verlassen niemals die Host-Maschine. Wenn wir ein 2 TB großes Remote-Backup sofort mounten wollen, können wir es nicht herunterladen und in eine temporäre Datei entschlüsseln – das würde den Zero-Knowledge-Ansatz zunichtemachen und die Leistung zerstören.

Der Klartext (Plaintext) darf nur im RAM existieren, und zwar exakt in dem Moment, in dem das Betriebssystem einen bestimmten Sektor anfordert.

Um dies ohne benutzerdefinierte Treiber zu erreichen, wählten wir den härtesten, aber architektonisch reinsten Weg: Wir haben einen vollständig konformen iSCSI Target Server von Grund auf neu entwickelt, komplett in Rust geschrieben und direkt in den StateWarden-Agenten eingebettet.

Windows verfügt über einen nativen, integrierten iSCSI-Initiator. Indem wir seine Sprache über eine lokale Loopback-Schnittstelle sprachen, konnten wir Blöcke aus unseren eigenen Rechenzentren streamen, sie im RAM on-the-fly entschlüsseln und sie nativ dem Windows-Speicher-Stack bereitstellen.

Hier ist, was es braucht, um ein Block-Speicher-Target von Grund auf neu zu erstellen und den berüchtigt unerbittlichen Windows-Speicher-Stack zu bändigen.

Navigation durch die Strenge von Windows iSCSI

Das iSCSI-Protokoll (RFC 3720) kapselt komplexe SCSI-Befehle in Protocol Data Units (PDUs) über TCP. Der Windows iSCSI-Initiator leistet hervorragende Arbeit, ist aber unglaublich streng. Ein einziges falsch platziertes Byte oder eine leichte Abweichung von der State Machine führt zu einem stillen Fehler: Der Initiator trennt einfach die TCP-Verbindung (os error 10054) ohne jede Erklärung.

Während unserer anfänglichen Implementierung schloss der Windows-Initiator den komplexen Login-Handshake erfolgreich ab und entdeckte unser virtuelles Target. Aber in dem Moment, in dem er versuchte, die Festplatte abzufragen, brach die Verbindung gewaltsam ab.

Die Paketanalyse enthüllte den genauen Moment des Fehlers: Windows sendete einen REPORT LUNS (0xA0) Befehl. Unser Rust-Server verarbeitete ihn perfekt und fügte die Payload-Daten direkt in die SCSI Response PDU (0x21) ein.

Laut RFC darf eine SCSI Response PDU nur Statuscodes (wie SUCCESS oder CHECK CONDITION) enthalten. Sie darf keine Lesedaten übertragen. Alle tatsächlichen Daten müssen über eine dedizierte SCSI Data-In PDU (0x25) gesendet werden. Der Windows-Initiator sah Payload-Bytes, die an einen Status-Frame angehängt waren, stufte dies als fatale Protokollbeschädigung ein und löste sofort ein TCP RST (Reset) aus.

Das Refactoring unseres Packet-Builders, um den Datenstrom zu trennen und die Flags F (Final) und S (Status present) im Data-In-Frame korrekt zu setzen, stabilisierte die Verbindung.

Umgang mit PDU-Fragmentierung

Selbst mit einem konformen Protokoll verursachten tiefe Dateisystem-Scans zeitweilige Verbindungsabbrüche. Der Durchbruch kam bei der Analyse der iSCSI-Login-Parameter.

Während des Handshakes verhandelt Windows eine MaxRecvDataSegmentLength (typischerweise 256 KB). Beim Lesen großer Master File Table (MFT)-Strukturen gibt Windows jedoch SCSI-Lesevorgänge für 512 KB oder mehr aus. Unsere erste Implementierung versuchte, die gesamte 512-KB-Payload in einer einzigen Data-In PDU zu senden. Windows sah das übergroße Paket, erkannte, dass es die verhandelten Limits überschritt, und baute den Socket sofort ab.

Wir mussten unsere Data-In-Streaming-Logik umschreiben, um massive SCSI-Leseanforderungen automatisch in eine Sequenz kleinerer, konformer PDUs zu fragmentieren, exakt gestückelt auf die verhandelten Limits des Initiators, wobei die Entschlüsselung und das Deduplizierungs-Mapping on-the-fly über mehrere Pakete hinweg durchgeführt wurden.

Vortäuschen der NTFS-Geometrie im Speicher

Mit dem soliden Netzwerkprotokoll verband sich der Windows-Initiator endlich reibungslos. In der Windows-Datenträgerverwaltung erschien ein neues Laufwerk. Aber der Windows-Explorer weigerte sich, es zu öffnen und bezeichnete das Dateisystem als "RAW".

Unser Target lieferte die exakt entschlüsselten Bytes der gesicherten NTFS-Partition. Warum konnte Windows sie nicht lesen?

Das Problem lag in der physikalischen Geometrie des Original-Backups. Wenn der StateWarden-Agent ein Live-Windows-Laufwerk sichert, fragt er die FSCTL_GET_NTFS_VOLUME_DATA API ab, um die genaue Größe des Dateisystems zu bestimmen.

Diese Windows-API meldet jedoch die Volume-Größe ohne den letzten Sektor. Dieser letzte Sektor enthält den Backup Volume Boot Record (VBR). Ein laufendes Windows-System stört diese Kürzung nicht, aber der ntfs.sys-Treiber, der ein neu gemountetes Laufwerk validiert, verlangt zwingend, dass der Main VBR (bei LBA 0) und der Backup VBR (am Ende der Festplatte) perfekt übereinstimmen. Da unserem Backup-Stream dieser letzte Sektor fehlte, wies Windows das gesamte Dateisystem als beschädigt zurück.

Wir haben einen Echtzeit-Fix in unserem Streaming-Backend entwickelt. Unser MbrWrapperBackend speichert nun den Main VBR on-the-fly zwischen, berechnet die wahren physikalischen Grenzen der Partition und injiziert dynamisch einen synthetischen Backup VBR exakt am Ende des Streams im Speicher. Wir polstern die Geometrie effektiv perfekt auf, bevor wir sie dem iSCSI-Initiator präsentieren.

Die architektonische Auszahlung

Mit der wiederhergestellten exakten NTFS-Geometrie und den perfekt fragmentierten Netzwerk-Payloads wird das virtuelle Laufwerk sofort gemountet. Der "RAW"-Fehler ist verschwunden, und Gigabytes an stark verschlüsselten, deduplizierten Daten aus unseren Rechenzentren können sofort im Windows-Explorer durchsucht werden.

Jedes Mal, wenn Sie auf eine Datei doppelklicken, ruft der StateWarden-Agent die exakten deduplizierten Blöcke vom Remote-Storage-Knoten ab, entschlüsselt sie im RAM mit den lokal gespeicherten Schlüsseln und leitet sie über die iSCSI-Loopback-Verbindung an das Betriebssystem weiter.

Ein Block-Speicher-Target von Grund auf neu zu entwickeln ist schmerzhaft, aber die architektonische Auszahlung ist massiv. Wir liefern native "Instant Mount"-Bare-Metal-Funktionen auf Enterprise-Niveau, mit absoluter Zero-Knowledge-Sicherheit und ohne den Kernel des Benutzers mit Treibern von Drittanbietern zu verschmutzen. Wir machen keine Abkürzungen, wenn es um die Integrität des Host-Systems geht.

Wir erwarten voll und ganz, dass Legacy-Anbieter nach dem Lesen dieses Artikels versuchen werden, diese treiberlose Architektur zurückzuentwickeln und zu replizieren. Sie sind herzlich eingeladen, es zu versuchen. Aber eine native iSCSI-Implementierung ist nur eine einzige Komponente der StateWarden-Engine. Sie ist nur eine von Dutzenden proprietärer architektonischer Entscheidungen – von unserer PrimeKEM-Zwiebelkryptografie bis hin zu unseren aktiven Vigil-Verteidigungsheuristiken –, die das aktuelle Marktangebot grundlegend deklassieren. Wir bauen nicht nur ein Backup-Tool; wir konstruieren den neuen Standard für Datenresilienz.